Since 8 hours really isn’t a lot of time to build a game, I did a bit of prep work the night before by building a set of blank playing cards to use as templates. The design is based on the layout of cards from Dominion, with a card name across the top, a short description across the bottom, and the rest of the space divided evenly between a picture and long description.

I printed the templates on white 199 g/m^2 card stock from the local office supply store and cut out 216 blank cards by hand. Real playing cards seem to be a bit heavier (around 320 g/m^2), but the card stock seemed to work well enough for prototyping purposes. I also used a set of card protectors usually used by Magic players to make it easier to handle and shuffle my home made cards. It also prevented players from seeing what their opponent was holding, since the thin cards are slightly transparent.

Before creating any cards, I wrote a bit of python code that would let me simulate my card game, so that I could try and make sure the game was fair. The contents of the card game are defined in a separate JSON file, which I was hoping would let me reuse the python code for future card game design work, but I ended up writing so much game-specific code into the python that it’s not really feasable to reuse it.

If you’re interested in building your own version of Monster Mages, you can get a deck list and rules from the project’s github page.

Winter-een-mas is a holiday for gamers, spanning from January 25th through the 31st, and celebrated by spending time playing games with friends and family. We hope you’ll join us for this free event – featuring twelve hours of gaming goodness – playing classics from Settlers of Catan to Halo.

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)

Much of the targeting system was fairly straight forward. Thanks to the code cleanup I had done over the past few days, taking control of the camera independant of the player was pretty quick, and Ryan’s code for managing input was easy to tie into.

Textures were a bit more challenging. I created a texture for a stone wall using The GIMP, but once I got it into the game, I noticed that it looked muddy when we weren’t up close. I’m not an artist, so it is unfortunately probably the best we can hope for. When it came time to do textures for the player and enemies, we were getting close to midnight. Instead of creating them myself, I found a Creative Commons licensed texture set on Deviantart, and did a little bit of tweaking. I only created one texture for the enemies, but we got some colour variation in them by assigning them a randomly coloured material in OpenGL to tint them.

I also created a mesh for stairs – in the game, a set of stairs takes to up to a fresh batch of more skilled enemies. I defined the verticies of the mesh by hand since that was faster than creating them in a 3D modeling program and writing an importer for a file format like OBJ (though on reflection, I could have used the STL loading code from my 3dc project).

Ryan was able to get a handful of new skills implemented, such as drain life, eagle eye, cripple, and haste.

After finishing up those skills, Ryan moved on to some basic game balance. He started by decreasing the amount of health the player starts with – we originally had inflated it to help with testing. He also decreased the chance that a health potion will drop from 100% to around 10%, since they were far too easy to aquire. Around this time, he also implemented an leveling and experience system. For every enemy that the player kills, they get a small amount of experience points. When they get enough points, they gain a new level, which increases their basic attributes and refreshes their health and mana.

Day 9 is over, and so is our little experiment. It’s been a great nine days, and I learned a lot. I’d even consider doing it again, though I don’t think I would do it from scratch. It’s a great way to learn, but if the goal is to build something awesome, I think it’s better to start with at least a simple 3D engine. But these discussions are best saved for our wrap-up blog post – stay tuned for that!

Finally, here are links to the Linux binaries and the GitHub repository.

• 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 am happy to say I finally got around to doing that in-game menu system for item management. That’s been on the to-do list for so long it’s embarassing; but it’s done now, and I can move on to other things. We decided to cancel work on the options and home screens. We’re in a huge time crunch for Day 9, and we’ve decided to switch gears and get back to focusing on building really cool, educational stuff. Windows and screens need not apply!

Ryan had great success in developing new skills and the targeting system on the ASCII side of things. Complementing the spin attack, we now have: precise strike, giant swing, flaming hands, and heal. He also threw together this demo video of the new skills:

I also revised our design doc a bit, to account for the amount of remaining time. I cut out a lot of features that we won’t have time to add. I also added in a bunch of new text to describe in more detail some of the features we have already added. Better late than never, I guess?

Design Doc, Day 8

• Finish the code cleanup in the 3D engine
• Finish building the menu system for inventory and character management
• Begin work on the options screen
• Finish the action scheduler
• Write the functions to handle combat

Thankfully, I managed to complete all the code cleanup that needed to be done in the 3D engine. The problem was that so much game logic was in there that we would have needed to start writing a whole bunch of APIs inside the engine for controlling the game, which means the engine would be much less portable. With these changes, I feel pretty good that we could pull out the engine and use it to save us 4 or 5 days of work on a future game!

Unfortunately, I got hung up implementing menus due to my imperfect knowledge of C++, the language we’re developing in. I haven’t seen enough of the Design Patterns to know them by heart, so much of the day ended up being spent consulting StackOverflow and Effective C++, two resources that I can’t recommend highly enough.

Ryan made slightly better progress than I did, finishing off the action scheduler and continuing to work on the combat systems. He also implemented our first special ability, the spin attack, that hits all nearby enemies.

• 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
• Begin work on the options screen

The stat system we ended up selecting was one I designed a few months ago to allow for heavy character customization. Each character has eight attributes: strength, constitution, magic, wisdom, dexterity, discipline, intelligence, and speed.

Credit where credit is due: Ryan came up with the mechanic of having strength and magic increase the damage taken by their respective damage type, which seems like a cool mechanic.

With this system, it’s easy to create many of the classic RPG classes. For example, the mage/wizard in our system would pick up magic, wisdom to counter the increased damage from magic, discipline, and intelligence for critical hits. A mage from the Fire Emblem series could be represented by taking more speed than intelligence to increase dodge chances.

But this system also allows for some character styles that are harder to model with a classic D&D system, like the Templar from Dragon Age, who in our system would have strength, constitution and dexterity, like a warrior, with extra wisdom to defend against magic users. Or consider the spellsword, a prestige class from D&D. In our system, the hero would want high strength, magic, and dexterity, modelling a character who fights at melee range with a mixture of swordplay and wizardry.

Ryan began work on a scheduler to handle attack timing. The scheduling system takes inspiration from the way an operating system scheduler works, with processes (or in this case, characters) delaying themselves based on an ‘action cost’, before transitioning to a ready queue and executing the ability. All actions in the game world, from moving to resurrecting dark gods, get scheduled by this system. The result is that our game isn’t exactly turn-based like a traditional roguelike. Instead, action unfolds more like it does in Final Fantasy, and very fast characters could potentially get multiple actions in a row, especially if those actions have a very low action cost.

The screenshot above shows some of the new UI elements I created on Day 6: a health meter (top left) and list of available abilities (bottom right). Overall, the 3D system is progressing slowly. While attempting to implement menus, I realized that some of the design decisions I had made earlier in the project were going to hurt the development of our UI. Early on, I was rushing development by throwing a lot of game logic into the 3d game engine itself. This came to be a problem when designing the menuing system because menus have a foot in both worlds – they’re rendered by the engine, but the only sane way to try and control them is to have a handle to them outside the engine.

The upshot is that I spent a lot of time refactoring code yesterday to fix those design errors. The downside is that the time spent fixing those problems is time that could have been better spent creating art assets, learning how to use OpenGL’s stencil buffer, or writing a particle engine. Day 7 will be busy!

• 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)

Ryan had a head start on developing the AI system from Day 4, meaning it was mostly tuning and bug-fixes that needed attention. The enemies use an A* search algorithm to find a path around the dungeon. Enemies that can “see” the player will move towards and attack him. Enemies that can’t see the player instead move around the map and explore (internally, the enemies can only “see” as much of the terrain as a human player can). The AIs also occasionally attack each other, but that’s a bug, not a feature!

On the OpenGL side, I managed to get a text console showing up. This was a bit more involved than I had anticipated; I needed to learn how to load and interpret a font from a bitmap, then I needed to figure out how to display a static, flat UI element over top of the 3D parts. Lesson 17 of the NeHe Tutorials proved to be invaluable for that. Jumping off of the work for the text console, I did some initial work towards creating the character sheet and inventory windows, but there’s nothing demoable yet.

Ryan put together a demo video of our progress at the end of Day 5. Check out how the AIs chase the player around the map. The text console that is now visible in the lower left corner of the screen was added today. This is also the first movie we’ve posted that shows the enhanced lighting system developed on Day 4.

While we’re on the downhill slope towards the end, it doesn’t feel like that to me. There’s a lot of work ahead of us in order to meet our deadline, and the 12 to 14 hour days are exhausting. I feel like Day 6 will be a good day to take a break and remind ourselves why we’re doing this, but I’m not sure how to do that… We’re a block away from the EA Games office in Kitchener – anyone know if they give tours?

• 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

Ryan pushed ahead and finished off his menu system in the 2D environment, and was able to tie that in with the inventory management system. He even made a video:

[Ed: WordPress is having trouble embedding this video. My apologies, loyal reader, if it doesn't show up for you.]

The refactoring of the 3D code, however, is much less glamourous. I was able to meet a few of the objectives, like the lighting refactoring and fixing the camera code. I quite like the way the new lighting system lights up the environment around the player, and reminds me a lot of the way fog of war works in real time strategy games like Starcraft.

I think that if I had laid out a bullet point list like the one above, I may have made better progress by moving from one point to the other, without needing to think about what to work on next. I’ll try this with tomorrow’s development.

There’s still a lot of code to clean up, but we’re out of time. I’ll have to settle for continuous refactoring as we push ahead with new features over the next 5 days.

• 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
• Add an inventory management system

The only goal that we didn’t meet on Day 3 was the inventory management system. Ryan had to leave early, but I think we could have done it if we had been able to work all day.

Though the other goals were technically accomplished, I’m not particularly happy with the progress on the engine features. For example, in our demo video you can see that the camera doesn’t perfectly track the motion of the player.

The lighting system is also quite primitive. In order to add things like random torches scattered around the room, there will need to be some work done towards cleaning up the engine code. However, this refactoring and cleanup needs to happen anyway, so perhaps we can kill two birds with one stone on Day 4.

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)
• Add texture support to the engine
• Add combat and inventory systems

In all, we were only able to meet about half of our goals for the day. We did finally get the world showing up in 3D (one of yesterday’s goals), and Ryan added a skeletal combat system.

We did end up trading off some of our development time to add in the “blood splatter” effect seen in the videos. (Can ASCII graphics be rated PG?) Ryan also did some more experimenting with the libtcod libraries we’re using and came up with an interesting multiple camera system for the ASCII environment.

The goals of texture support and inventory systems, unfortunately, are getting pushed to day 3.