JavaScript: The Good Parts by Douglas Crockford is a short, dense, humorless outline of a safe subset of JavaScript, targeted at programmers who already hang a few languages on their toolbelt and who find themselves curious about this newfangled “web programming” thing. This book is packed – packed – with key details on the many quirks and foibles of this less-than-perfect language, but ultimately misses its goal of being a strong first stop for new JavaScript developers.
The beginning of Day 9 marked a change in our goal planning. Up until the end of Day 8, our development was still targeting the path laid out in our original design doc on Day 0. While we knew after about Day 5 that we weren’t going to meet all our goals, it wasn’t really until Day 9 that we stopped and talked about our revised target. Considering what we had (and more importantly, what we didn’t have), we changed the core of our game to better suit our development timeframe. Instead of “evolving a powerful dungeon-crawling character”, our game was going to be about “destroying as many enemies as possible before dying”.
With that key change in mind, we set out our goals for Day 9:
Get the in-game targeting system running for targeted spells
Create some textures for the player, enemies, and items
Develop a particle system to show spell effects
Complete as many cool spells and abilities as possible
Make some effort to balance the game (currently too easy)
We’ve wrapped up our penultimate day on this project. However, there isn’t much time for reflection – in order to have something fun and playable for the final day, we need to push hard on Day 9. The goals for Day 8:
Finally finish up the in game menu system
Create the options and home screens
Add the ability to target locations for spells
Add some new spells to show off targetting
Add some different dungeon features, like doors (time permitting)
I’ve been feeling the effects of my early design decisions over the past few days. With this being the most involved game engine I’ve written, I’ve definitely suffered from the lack of experience, meaning most of Day 6 and 7 needed to be spent correcting those problems. This means that on the 3D side, a bunch of the requirement that we’ve needed to implement are far overdue, and are hurting our chances of meeting the Sunday deadline. The goals for Day 7 were:
Finish the code cleanup in the 3D engine
Finish building the menu system for inventory and character management
Role-playing Games (RPGs) are all about the numbers. Quantifying attributes, calculating armor values, computing damage after mitigation; It’s a thing of beauty for data geeks. Up until Day 6, we had enough on our plate to worry about just getting the world to work without thinking about the calculations and equations that are integral to it. But, finally, it’s time to bust out the Excel spreadsheets, power up the calculators and do some math. The goals:
Select a stat system and implement it
Build a scheduler to handle attack speed (i.e. calculate who attacks first)
Develop an API to help optimize our world’s rendering
Create an OpenGL menu system for inventory management
Day 5 marks the midpoint of our development cycle, coincidentally falling on a Wednesday. I think we’ve come a long way in just the first half of the project – the trick will be continuing that pace of development over the second half. Day 5′s goals were a bit more modest compared to previous days. On the OpenGL side, I’m getting to a point where most of the development I’m doing is the kind of work I’ve never done before with this tech, so progress feels like it’s slowing down.
Write an AI routine to make the dungeon enemies seek out and attack the player
Create a text console in OpenGL for game feedback
Develop the in-game character sheet and inventory windows (time dependant)
After 3 days of solid development time, Day 4 called for a bit of clean up in the 3D engine code. It was work that needed to be done, but unfortunately not the kind of material that makes for a good blog post. The goals for the day were more nebulous, and performance a bit harder to measure.
Rewrite the way the engine generates maps to improve performance
Refactor the lighting code to make it easier to add random lights in the dungeon
Fix the camera motion so it tracks the player better
Change calls that pass and store 3 separate float values to use our Vector3f object
Clean up redundant #includes
Comment, comment, comment
Break out engine and input-specific code from the main() method to their own objects
Clean up any other code that would be worthy of submission to The Daily WTF
Develop an inventory management system
Finish off the 2D menu system in the ASCII environment
Day 3 continued the trend of setting goals that were just slightly out of reach. They say you’re not supposed to set unreachable goals, but it feels like, given the time crunch we’re in, making these tight schedules keeps us working as hard as possible. The goals for Day 3:
Set up the camera to follow the player around the world
Add texture mapping support to the engine
Add support for lighting to the engine (if there’s time)
Add support for items in the dungeon, and the ability to pick them up
Day 2 began around noon at Kwartzlab, on the second day of the Global Synchronous Hackathon. We were feeling ambitious, and laid out another 3 goals for the day:
Get the random levels rendering in 3D (for reelz this time)
Day 1 started off bright and early at Kwartzlab, coinciding with the first day of February’s Global Synchronous Hackathon. We had four development goals for the day:
Develop a random level generator (Ryan)
Write a 3D engine capable of displaying the random level (Alex)
Subscribe to RSS Feed
Follow us on Twitter
Our Mailing Lists
Visit Kwartzlab TV