It’s been a while since I last updated this devlog and in the meantime the assemblee competition has ended with 73 great entries including my own named The King, the Queen and the Jester. The voting took place between January 20th and February 3rd and the results can be found here. My entry managed to get the 9th place and I’m really happy with this achievement.
You can find the development thread for the game following the link:
A detailed review of the game was featured on Big Download and can be found at the following link:
The competition version of the game can be downloaded from the following link:
Now I’ll resume development on the game but it may take a while before I release a new version since I intend to rewrite the rendering engine first. Meanwhile, you can read the mini postmortem I wrote for the competition version of the game that can be found after the jump.
The King, the Queen and the Jester (henceforth KQJ) was inspired by classic dungeon crawler games like Eye of the Beholder and Lands of Lore and it shares some characteristics of these games like the first-person view, tile based movement and scripted puzzles involving the manipulation of dungeon features like doors, buttons and pressure plates. The main difference between KQJ and these classic dungeon crawlers lies on the battle system that follows a turn based approach in KQJ whereas Eye of the Beholder and Lands of Lore used real time battles. Other differences include the absence of a stats system and levelling for the player and weapons that can be used a finite number of times turning them into important resources that the player must manage to be successful in the game. Enemies are also different since their health points, attacks and weaknesses are all exposed to the player at all times allowing him to plan each action carefully in battle minimizing the damage taken and the amount of weapon resources used. All of these features are supposed to turn KQJ into a challenging dungeon crawling game suitable to players that like resource management and puzzle solving.
What went right
- Battle system – The turn based battle system and the possibility of knowing the next attacks and weaknesses of all monsters at all times allowed players to approach battles in different ways rewarding those who took their time to analyze all the available information about monsters and items. Players needed to be careful during all battles and they were rewarded in doing so by taking less damage and by minimizing the amount of item resources used. The ability to extend the player turn allowed players to face multiple enemies and the ability to stun an enemy cancelling its next attack allowed players to negate dangerous high damage attacks from stronger monsters. Monsters with ranged attacks and different attack patterns presented different kinds of challenge that could be combined to create interesting battle situations.
- Scripting system – The use of Lua and tolua++ to expose the class methods on the scripting system worked perfectly and allowed easy editing of the game levels. New dungeon features could be easily created as C++ classes and then exposed via tolua++ to allow its direct use on the scripting system. Puzzles could be designed using this setup and they could be tested without the need to recompile the game on every change. Also, new monsters and items could be created by just adding new script files describing the new monster or item since they were represented as collections of data (health points, weaknesses, attacks, durability, etc.).
- Graphical user interface – The minimalist graphical user interface provides all info the player needs to know without filling the screen with lots of windows and/or menus. A potion flask presents a quick visual approximation of the player health points that are represented by the amount of red liquid inside the flask. A stone that changes color indicates the change of turns when the player is in battle. Finally, the player inventory is always visible at the bottom of the screen and allows easy manipulation of items and basic actions like attacking monsters, unlocking doors and drinking potions. Detailed information is also available when the player hovers the mouse cursor over each of these interface elements.
What went wrong
- Rendering engine – Creating a 3D rendering engine from scratch for the first time for a game that had to be made during the period of 35 days was not a good idea. The rendering engine created was simple and the amount of objects to render was small but lots of people had problems running the game smoothly on low-end graphics boards. Games like Warcraft 3 run perfectly on an Intel GMA 950 but KQJ suffers from bad performance on the same graphics board and the level of graphics detail is way lower.
- Level editing – Using GIMP as a level editor didn’t work so well after having to convert maps from bitmaps to a custom data structure every time I needed to remove a tile or change its type. Initially it looked like it was a good idea since I could create maps using the tools provided by GIMP but when I started scripting the levels I couldn’t, for example, just select a tool and add a new enemy. I needed to check the coordinate of the tile where I needed to add an enemy, edit the level script to create a new object and then test the level to ensure the enemy was where it was supposed to be. A custom in-game level editor would have taken some time to code but it would be much easier to edit new levels and I’d probably be able to deliver more playable levels by the deadline.
- Playtesting and the absence of a save system – The competition version of the game was released with some game breaking bugs and level design issues that could have been solved if I had more time to playtest the game. I spent about 30 days coding the game engine and the last 4 days to script the 2 levels included on the competition version. Some level design issues like players getting stuck without any leads on how to proceed or players reaching areas earlier than they were supposed to could have been solved by having more people test the game before the release (I only played through the competition version levels two times and watched two playtesters complete the demo). The absence of a save system was also problematic since I had to restart the demo from the beginning every time I found something wrong and fixed it. For example, a locked door that couldn’t be unlocked because I forgot to add the key to unlock it forced me to exit the demo, fix the script and play the demo again until that point to be sure that door could be unlocked.
The competition version of The King, the Queen and the Jester was released on January 10th and it feels like a finished dungeon crawling game presenting a new kind of turn based battle system involving strategic planning of actions and resource management. The development process was very instructive and I’m satisfied with the resulting product. There were lots of problems during development but there were also lots of opportunities to learn new things I wouldn’t have learned if I hadn’t participated on the competition. For the future, I intend to solve some of the problems presented on this postmortem starting by learning more about OpenGL to rewrite the rendering engine to increase the game performance. Also, I intend to spend more time studying and designing levels for this genre of games in order to provide varying challenging and interesting situations and puzzles for the player throughout the game.
- Hardware: Asus G1S-A1 – Core 2 Duo T7500, 3GB RAM, GeForce 8600M GT 256MB
- Operational system used on development: Ubuntu 8.04
- Development time: 340 hours / 34 days (average 10 hours per day)
- Programming languages: C++ / Lua
- Libraries used: OpenGL, SDL, SDL_image, SDL_mixer, tolua++, Lua
- Lines of code: 15143 C++ (272 files) / 1469 Lua (38 files)
- Softwares used: CodeLite IDE, GIMP 2.6, Audacity