Fix2... Fix3... and so on
by Kyzrati on 27.3.12 , under
There have been a couple new bugfixes uploaded over the past few days. Scores from any post-7DRL fix version are valid for the competition, since they don't include any content modifications, but you really should get the latest version to avoid potential crashes.
Most of the players are hanging out over in the Bay 12 thread, so announcements have been going there. There you'll also find strategy discussions, and some more insights into the game.
Some were finding the game a bit difficult, but the early levels shouldn't be too hard at all once you learn how to play. To show how easy it can be, I recorded a quick run of levels 1-3 (HD highly recommended):
I didn't even play very carefully in that run, but beyond level 3 is the Factory, where the game finally starts to get a little tough and you might have to start making some harder decisions... Level 8 and beyond is for the pros, but I have yet to see anyone make it quite that far.
Most of the players are hanging out over in the Bay 12 thread, so announcements have been going there. There you'll also find strategy discussions, and some more insights into the game.
Some were finding the game a bit difficult, but the early levels shouldn't be too hard at all once you learn how to play. To show how easy it can be, I recorded a quick run of levels 1-3 (HD highly recommended):
I didn't even play very carefully in that run, but beyond level 3 is the Factory, where the game finally starts to get a little tough and you might have to start making some harder decisions... Level 8 and beyond is for the pros, but I have yet to see anyone make it quite that far.
Bugfix? Score!
by Kyzrati on 25.3.12 , under Release
The Cogmind 7DRL bugfix is here!
Knowing the game had several serious interface bugs that could crash it and ruin an otherwise fun experience, I just couldn't take it any more, and had to fix 'em. I know there are still a couple rare logic bugs lurking in there somewhere, but I haven't been able to reproduce them, and they're sufficiently rare to ignore for now in order to get these more important fixes out to you. Get it on the files page.
Because I wanted to hold a high score competition, in addition to the fixes I also made several modifications regarding scoring. The complete list of changes (from changelog):
And now for the announcement you've been waiting for... Let the HIGH SCORE COMPETITION begin! See the rules page for details (also included with the game as competition.txt)--participation is easy.
The competition is ongoing, but the top ten records submitted by April 8th, 2012 (inclusive) will be immortalized in a blog post summarizing the competition to date. As part of the event, special titles and achievements will also be awarded to players based on a broad analysis of the records, so even if you're not #1 (or not in the top 10), you may earn other forms of recognition.
Only this bugfix version can be used for scoring purposes, so if you want to participate, download the latest version.
I've never done anything like this with a project before. If it works, I may eventually do something similar with X@COM.
Knowing the game had several serious interface bugs that could crash it and ruin an otherwise fun experience, I just couldn't take it any more, and had to fix 'em. I know there are still a couple rare logic bugs lurking in there somewhere, but I haven't been able to reproduce them, and they're sufficiently rare to ignore for now in order to get these more important fixes out to you. Get it on the files page.
Because I wanted to hold a high score competition, in addition to the fixes I also made several modifications regarding scoring. The complete list of changes (from changelog):
- FIX: If an inventory storage utility is destroyed, reducing your capacity, the last extra item was still shown in your inventory display even though it was already been dropped; trying to do some actions with this ghost item could cause a crash
- FIX: Game could crash if actions entered while status/data window closing (included inventory actions that automatically close the window)
- FIX: Game could crash if mouse moved on score window
- FIX: Item's current state properly shown in data window
- FIX: No longer allowed to target self (would crash game)
- FIX: Tunnelers in the scrapyard excavate the level properly (though its really just for fun, since you aren't supposed to hang around there, anyway...)
- FIX: Suicide shows mission results screen instead of skipping straight to new game
- MOD: Broken parts shown red in inventory list (as they are in attached parts list)
- MOD: Reduced score points for robot destruction
- MOD: Lots more information printed to score record
- MOD: Added score record integrity value
- MOD: Data parameters loaded from compressed file (can override it to use public data files, but doing so invalidates score for competition purposes)
- MOD: Known prototypes still glow on the map, slower than unknown prototypes
And now for the announcement you've been waiting for... Let the HIGH SCORE COMPETITION begin! See the rules page for details (also included with the game as competition.txt)--participation is easy.
The competition is ongoing, but the top ten records submitted by April 8th, 2012 (inclusive) will be immortalized in a blog post summarizing the competition to date. As part of the event, special titles and achievements will also be awarded to players based on a broad analysis of the records, so even if you're not #1 (or not in the top 10), you may earn other forms of recognition.
Only this bugfix version can be used for scoring purposes, so if you want to participate, download the latest version.
I've never done anything like this with a project before. If it works, I may eventually do something similar with X@COM.
'Mind the Fix
by Kyzrati on 22.3.12 , under
Quickly producing a fairly complex game is a recipe for bugginess. The game works (I and others have played through several times without issue), but is prone to sudden crashes since I couldn't give it the full amount of debug time it really needs.
As such, I'll be doing a bug fix release in the near future. The fix will not change any content or gameplay, it will just try to identify and remove causes for crashes. I'll keep the original download available as well, for the purists.
Anyone who hasn't downloaded yet should still feel free to play the current version, as there are no blaring gameplay-associated problems and it's definitely a lot of fun, but check back later for the fix.
Along with the fix I'll also be holding a high score competition, where you can email me your best game record and I'll post ordered results on a special page. I'll announce the event here, on Rogue Temple, and probably elsewhere. It'll be ongoing, so even after the initial competition period anyone is welcome to participate by sending in their scores.
EDIT:
Known bugs I've fixed for the upcoming release (watch out for these!):
* Entering an action command like wait or attach/detach while the status or data window is open can crash the game (don't do that!)
* Shooting yourself will crash the game (leftover code from X@COM, where shooting at your position is allowed since it will target the ground--can't do that in Cogmind because it's 2D)
* Moving the cursor on the score window can crash the game
* If an inventory storage utility is destroyed, reducing your capacity, the last extra item will still be shown in your inventory display even though it has already been dropped; trying to do some actions with this ghost item may cause a crash (do some other action that reloads the inventory window to avoid this error for now--dropping the first item would be a safe bet)
As such, I'll be doing a bug fix release in the near future. The fix will not change any content or gameplay, it will just try to identify and remove causes for crashes. I'll keep the original download available as well, for the purists.
Anyone who hasn't downloaded yet should still feel free to play the current version, as there are no blaring gameplay-associated problems and it's definitely a lot of fun, but check back later for the fix.
Along with the fix I'll also be holding a high score competition, where you can email me your best game record and I'll post ordered results on a special page. I'll announce the event here, on Rogue Temple, and probably elsewhere. It'll be ongoing, so even after the initial competition period anyone is welcome to participate by sending in their scores.
EDIT:
Known bugs I've fixed for the upcoming release (watch out for these!):
* Entering an action command like wait or attach/detach while the status or data window is open can crash the game (don't do that!)
* Shooting yourself will crash the game (leftover code from X@COM, where shooting at your position is allowed since it will target the ground--can't do that in Cogmind because it's 2D)
* Moving the cursor on the score window can crash the game
* If an inventory storage utility is destroyed, reducing your capacity, the last extra item will still be shown in your inventory display even though it has already been dropped; trying to do some actions with this ghost item may cause a crash (do some other action that reloads the inventory window to avoid this error for now--dropping the first item would be a safe bet)
7DRLC2012 Postmortem
by Kyzrati on 20.3.12 , under
Now that the hectic period of "Oh my god I'm awake, that means I must be working on my 7DRL!" period is behind me, there's more time to reflect on the process and give some insight into what went on behind the scenes.
As I mentioned before, a lot of planning went into the game, but too much planning is a bad thing if it's not focused in the right direction, and the later stages were all about slimming down the game into something doable. I should've thought more about creating a simpler game from the start, then the results might show a bit more polish.
Coding
The coding itself didn't actually take very long, since almost everything except the content and some of the mechanics came straight out of X@COM. The primary modification to the core code was inserting an event manager to handle an energy-based time system, but that turned out to be incredibly simple since all I used it for was entity turns and the game clock. (To prevent a coding and testing nightmare I left out duration effects--all effects are persistent. There's still plenty of fun and strategy with the 40 unique persistent effects available by attaching utility parts.) Beyond that the game only implements a handful actions, get/drop, attach/detach, activate/deactivate, and fire.
The rest of the work was mostly in putting together data objects and data files. All my projects are very data centric, and from the large number of data files the game draws from you can see that Cogmind is no exception. Once the actions were coded and I played around with a few test objects to make sure I had the right set of parameter ranges for the data-to-be, it was just a case of filling in those ranges with entity- and item-specific values followed by some quick spreadsheet data manipulation. Only entities and items were completely redone--the rest of the data files were almost entirely copied from X@COM.
I also quickly recolored some particle effects to add more variety for the wide selection of Cogmind items (way more than X@COM...). Too bad there wasn't more time, because I really wanted to throw in some neat new visual effects. As is, there are no new projectiles/explosions, and the UI is just cookie cutter templates from X@COM. Also too bad there wasn't more time since the X@COM codebase supports so many more features that I didn't get to work on, so I had to cut them. But the "if I only had more time" list is way too long to bother going into...
Design
From the beginning, there was a lot of debate (I brainstormed the game with my brother) over whether to do the typed slot system you see in Cogmind, or an even more open-ended system where you have X number of slots and can attach anything you want. Under that system, some parts would probably have to take up multiple slots to make it work right, but it might have seemed a bit chaotic (could've been a good thing, I guess) and would've been much harder to balance (not a good thing for a short project).
Eventually the typed slots won out, and after several iterations ended up with the names Power, Propulsion, Utilities, and Weapons. Later I realized that from a gameplay standpoint the latter three conveniently correspond to your basic RPG stat triumvirate: DEX, INT, and STR. (Completely unintentional, though perhaps inevitable.) Sure enough, what slots you focus on when evolving your Cogmind design can steer you towards play styles resembling stereotypical RPG characters. With evenly distributed slots you can be a well-rounded jack of all trades, or you can emphasize one of the three main slots and rely on strategies that capitalize on your advantages: you can be a super-fast flying robot dodging bullets and whizzing past everything in your way, you can attach a variety of utilities and have a trick up your sleeve for every occasion like any good mage, or you can deck yourself out with guns, cannons, missiles, and bombs and take on everything you meet. Power is the odd man out, and you generally have as little of that as you need to implement your design.
On top of that mechanic, several other core gameplay ideas were drawn from existing games: weapon heat and an energy/ballistic weapon dichotomy from Battletech, energy/mass as resources from Supreme Commander (mass was renamed to matter), and damage types from EVE online (I started with my own list, but it looked almost identical to EVE, so I went with that one since it was somewhat simpler).
Cogmind doesn't get hungry, but there are some alternate ways to push the player through the game. Core integrity is the obvious hitpoint equivalent, and the fact that it is only replenished (and increased) each evolution means you have a finite amount of time you can spend searching for a way out depending on how well you protect your core and stay out of harm's way. By the mid- to late-game though, you have so many parts that your core rarely takes serious damage (unless you are completely overwhelmed and lose lots of parts, in which case you're probably doomed anyway). At that point system corruption takes over as a source of danger. It completely bypasses armor, and increases the game's difficulty through its negative side-effects; you're also guaranteed to be tracked down by Programmers the longer you stay in an area. There really isn't much of a purpose to stay in a map area anyway, since there is no experience given from fighting (character advancement comes from reaching new areas). The whole point is to escape, after all, though finding an exit becomes harder and harder as you near the surface. Of course you can also become a virtual Programmer yourself by outfitting yourself with their electromagnetic weapons and shocking everything else; most enemy robots are far more susceptible to EM damage than Cogmind.
Limited inventory capacity is another thought-provoking mechanic which forces the player to make difficult choices, especially when leaving an area. Even leaving something on the ground for later may not work, since a Recycler could come by and move it. As with any other mechanic though, inventory space can be manipulated through utilities if you can accept the slot/mass/upkeep costs.
Utilities are one of the game's strong points, as they reach into every part of the gameplay. An entire day was spent coding 40 different effects which, when combined with a single item-specific variable to control the degree of the effect, led to about 170 utility parts. They provide a way to affect almost any aspect of the game you choose, enabling a wide array of unique builds. If you're familiar with all the parts and choose the most effective combinations, it's not impossible to come up with a nigh-invincible build, though it would be really tough to maintain it forever since you're likely to lose an integral part of your design at some point. Such is the life of Cogmind.
Regarding Cogmind's inferior siblings, the Overmind's mindless robotic thralls, I almost went with a strictly alphabetical representation; i.e., robot ASCII are A, B, C, and so on ordered by difficulty, all the way to the fearsome Z robot, and color would differentiate classes (types). This would have worked if not for the fact that there ended up being 11 classes, half of which are harmless, which have to fit into the system, and (more importantly) a robot's letter is definitely more readily identifiable than their color. In the end, I used a single letter for each class (lower/upper case reflects size), and color to instead represent relative threat (within a given class). Name codes also hint at difficulty, allowing some comparison of robots across classes; higher = harder. Let's just say you haven't seen tough until you meet a B-99. Don't forget your Null Cannons or Point Singularity Launcher :)
Part of the brainstorming process also touched on what happens after the game story. Just yesterday the name "Cogmind 2: The Surface" ran through my mind. If you beat the game, the conclusion gives a hint showing part of what to expect should that ever come to pass.
Now I'm going to go play some of the other cool 7DRLC entries out there...
As I mentioned before, a lot of planning went into the game, but too much planning is a bad thing if it's not focused in the right direction, and the later stages were all about slimming down the game into something doable. I should've thought more about creating a simpler game from the start, then the results might show a bit more polish.
Coding
The coding itself didn't actually take very long, since almost everything except the content and some of the mechanics came straight out of X@COM. The primary modification to the core code was inserting an event manager to handle an energy-based time system, but that turned out to be incredibly simple since all I used it for was entity turns and the game clock. (To prevent a coding and testing nightmare I left out duration effects--all effects are persistent. There's still plenty of fun and strategy with the 40 unique persistent effects available by attaching utility parts.) Beyond that the game only implements a handful actions, get/drop, attach/detach, activate/deactivate, and fire.
The rest of the work was mostly in putting together data objects and data files. All my projects are very data centric, and from the large number of data files the game draws from you can see that Cogmind is no exception. Once the actions were coded and I played around with a few test objects to make sure I had the right set of parameter ranges for the data-to-be, it was just a case of filling in those ranges with entity- and item-specific values followed by some quick spreadsheet data manipulation. Only entities and items were completely redone--the rest of the data files were almost entirely copied from X@COM.
I also quickly recolored some particle effects to add more variety for the wide selection of Cogmind items (way more than X@COM...). Too bad there wasn't more time, because I really wanted to throw in some neat new visual effects. As is, there are no new projectiles/explosions, and the UI is just cookie cutter templates from X@COM. Also too bad there wasn't more time since the X@COM codebase supports so many more features that I didn't get to work on, so I had to cut them. But the "if I only had more time" list is way too long to bother going into...
Design
From the beginning, there was a lot of debate (I brainstormed the game with my brother) over whether to do the typed slot system you see in Cogmind, or an even more open-ended system where you have X number of slots and can attach anything you want. Under that system, some parts would probably have to take up multiple slots to make it work right, but it might have seemed a bit chaotic (could've been a good thing, I guess) and would've been much harder to balance (not a good thing for a short project).
Eventually the typed slots won out, and after several iterations ended up with the names Power, Propulsion, Utilities, and Weapons. Later I realized that from a gameplay standpoint the latter three conveniently correspond to your basic RPG stat triumvirate: DEX, INT, and STR. (Completely unintentional, though perhaps inevitable.) Sure enough, what slots you focus on when evolving your Cogmind design can steer you towards play styles resembling stereotypical RPG characters. With evenly distributed slots you can be a well-rounded jack of all trades, or you can emphasize one of the three main slots and rely on strategies that capitalize on your advantages: you can be a super-fast flying robot dodging bullets and whizzing past everything in your way, you can attach a variety of utilities and have a trick up your sleeve for every occasion like any good mage, or you can deck yourself out with guns, cannons, missiles, and bombs and take on everything you meet. Power is the odd man out, and you generally have as little of that as you need to implement your design.
On top of that mechanic, several other core gameplay ideas were drawn from existing games: weapon heat and an energy/ballistic weapon dichotomy from Battletech, energy/mass as resources from Supreme Commander (mass was renamed to matter), and damage types from EVE online (I started with my own list, but it looked almost identical to EVE, so I went with that one since it was somewhat simpler).
Cogmind doesn't get hungry, but there are some alternate ways to push the player through the game. Core integrity is the obvious hitpoint equivalent, and the fact that it is only replenished (and increased) each evolution means you have a finite amount of time you can spend searching for a way out depending on how well you protect your core and stay out of harm's way. By the mid- to late-game though, you have so many parts that your core rarely takes serious damage (unless you are completely overwhelmed and lose lots of parts, in which case you're probably doomed anyway). At that point system corruption takes over as a source of danger. It completely bypasses armor, and increases the game's difficulty through its negative side-effects; you're also guaranteed to be tracked down by Programmers the longer you stay in an area. There really isn't much of a purpose to stay in a map area anyway, since there is no experience given from fighting (character advancement comes from reaching new areas). The whole point is to escape, after all, though finding an exit becomes harder and harder as you near the surface. Of course you can also become a virtual Programmer yourself by outfitting yourself with their electromagnetic weapons and shocking everything else; most enemy robots are far more susceptible to EM damage than Cogmind.
Limited inventory capacity is another thought-provoking mechanic which forces the player to make difficult choices, especially when leaving an area. Even leaving something on the ground for later may not work, since a Recycler could come by and move it. As with any other mechanic though, inventory space can be manipulated through utilities if you can accept the slot/mass/upkeep costs.
Utilities are one of the game's strong points, as they reach into every part of the gameplay. An entire day was spent coding 40 different effects which, when combined with a single item-specific variable to control the degree of the effect, led to about 170 utility parts. They provide a way to affect almost any aspect of the game you choose, enabling a wide array of unique builds. If you're familiar with all the parts and choose the most effective combinations, it's not impossible to come up with a nigh-invincible build, though it would be really tough to maintain it forever since you're likely to lose an integral part of your design at some point. Such is the life of Cogmind.
Regarding Cogmind's inferior siblings, the Overmind's mindless robotic thralls, I almost went with a strictly alphabetical representation; i.e., robot ASCII are A, B, C, and so on ordered by difficulty, all the way to the fearsome Z robot, and color would differentiate classes (types). This would have worked if not for the fact that there ended up being 11 classes, half of which are harmless, which have to fit into the system, and (more importantly) a robot's letter is definitely more readily identifiable than their color. In the end, I used a single letter for each class (lower/upper case reflects size), and color to instead represent relative threat (within a given class). Name codes also hint at difficulty, allowing some comparison of robots across classes; higher = harder. Let's just say you haven't seen tough until you meet a B-99. Don't forget your Null Cannons or Point Singularity Launcher :)
Part of the brainstorming process also touched on what happens after the game story. Just yesterday the name "Cogmind 2: The Surface" ran through my mind. If you beat the game, the conclusion gives a hint showing part of what to expect should that ever come to pass.
Now I'm going to go play some of the other cool 7DRLC entries out there...
You are the Cogmind
by Kyzrati on 18.3.12 , under Release
A new 7DRL is born!
It was an intense week of toiling away in front of my computer (frequently with "my computer in front of me" actually, as I brought my laptop everywhere and even coded on the subway!). Thursday night was the worst--down at 3 AM, up at 6 AM! The long hours of coding were mostly fun, except for that nasty crash which threatened to derail the entire project and turned out to be a well-hidden null pointer dereference that took several hours and three debuggers to track down.
This was my first 7DRL, and I can say that working on it required some behavior decidedly against my style. I like to carefully write fairly safe code (because bug-hunting and refactoring are both a pain--might as well try your best to do it right the first time), but with so little time speed becomes such a priority that hacks are not just an occasional temporary fix, they become absolutely necessary!
The most important lesson learned this week was that if you want to do a roguelike right in only seven days, it better be damn simple. I was three weeks without a computer while on vacation in January-February, so there was a dangerous imbalance of time to plan compared to time to put those plans into action. I spent so long brainstorming the game and coming up with more and more ideas to expand on that the scope of the game was just too vast to be a feasible short-term project. Fortunately I was able to cut down the features list and still keep some semblance of the original game idea, but Cogmind would be a lot different if it hadn't dropped a big chunk of the intended features. Parts of the game that didn't make the cut:
So what features are there? Here's a more exhaustive description of what the game includes:
Before Cogmind, I was planning on doing a Battletech RL for 7DRL 2012 (and you can definitely see some Battletech influences in there: sci-fi robot combat, a "parts as equipment" theme, heat control as an important combat mechanic...), but a strict implementation of the Battletech rules would require a hex grid (as with any faithful battletech game), and 7DRL is not about rewriting basic algorithms, which is what I would've spent all my time on since I have no hex-based game engine. So I instead worked with what I had on hand. Making Cogmind as a 7DRL would've been absolutely impossible without the benefit of a great starting point: the X@COM codebase.
Think of Cogmind as a total conversion mod (and then some) of X@COM. Before the competition, I stripped X@COM of most of its X-COM-specific gameplay to create a generic roguelike engine on top of REX (my SDL game engine) called 7SHELL, so named because it is a great starting point for 7DRL development. The vast majority of the Cogmind code is directly reused from X@COM--even the Cogmind data files still contain tons of reusable X@COM data. Just by looking at Cogmind you can see it's obviously derived from X@COM (in fact, some of the things it includes are from still unreleased future versions of X@COM); even so, there were some fundamental changes that make it quite a different game:
In the future I might fix up and expand Cogmind a little if the demand is there, but the hackish nature of the code will keep me from wanting to put too much more time into it. If it was going to be much bigger I'd probably restart from scratch. Also, now that the game is done, and looking back over the old design docs and list of cut features above, I have to say that Cogmind probably benefits from being a simpler game than originally planned. It already possesses a lot of dynamic gameplay under the current mechanics, and could easily become far too complicated with any more systems beyond the current build and rebuild theme where already you have to juggle resources, tactics, special abilities, and a huge number of parts.
The game seems to have turned out okay, although there wasn't enough time to spend on balancing the difficulty. It should be fairly easy to consistently beat the first several levels once you know how to play, but after that it can get difficult if you don't have enough gameplay experience. Now that I think of it, that's probably the way it should be... The game is winnable, but you've got to get good.
There will probably be some more postmortem posts about development soon.
It was an intense week of toiling away in front of my computer (frequently with "my computer in front of me" actually, as I brought my laptop everywhere and even coded on the subway!). Thursday night was the worst--down at 3 AM, up at 6 AM! The long hours of coding were mostly fun, except for that nasty crash which threatened to derail the entire project and turned out to be a well-hidden null pointer dereference that took several hours and three debuggers to track down.
This was my first 7DRL, and I can say that working on it required some behavior decidedly against my style. I like to carefully write fairly safe code (because bug-hunting and refactoring are both a pain--might as well try your best to do it right the first time), but with so little time speed becomes such a priority that hacks are not just an occasional temporary fix, they become absolutely necessary!
The most important lesson learned this week was that if you want to do a roguelike right in only seven days, it better be damn simple. I was three weeks without a computer while on vacation in January-February, so there was a dangerous imbalance of time to plan compared to time to put those plans into action. I spent so long brainstorming the game and coming up with more and more ideas to expand on that the scope of the game was just too vast to be a feasible short-term project. Fortunately I was able to cut down the features list and still keep some semblance of the original game idea, but Cogmind would be a lot different if it hadn't dropped a big chunk of the intended features. Parts of the game that didn't make the cut:
- Fire/smoke/clouds
- Proximity triggered effects
- Programs and viruses
- Interactive terminals/machines
- Keys and multiple types of barriers to progress
- Terrain types and variable movement costs
- Environment props
- Part-specific special actions
- Throwing
- More sensor types
- Cave-ins
- (lots more stuff in the docs)
So what features are there? Here's a more exhaustive description of what the game includes:
- Resource management
- Inventory and equipment system
- Item identification system
- Fog of war
- Several damage types each with unique properties/effects
- Simple yet dynamic combat system
- No XP (character development is automatic)
- Multiple AI behaviors
- Enemies with special abilities
- 12 classes of enemies
- 40 special abilities
- 400 items
- Permadeath
- Autosave/load on exit/startup
- Particle engine for animated ASCII effects (weapons/explosions etc.)
- Animated interface with sound effects
- Randomly generated maps
- Turn-based action
- Single player
- Message log
- Enemy units use the same ruleset as the player
- Score output to an external file
Before Cogmind, I was planning on doing a Battletech RL for 7DRL 2012 (and you can definitely see some Battletech influences in there: sci-fi robot combat, a "parts as equipment" theme, heat control as an important combat mechanic...), but a strict implementation of the Battletech rules would require a hex grid (as with any faithful battletech game), and 7DRL is not about rewriting basic algorithms, which is what I would've spent all my time on since I have no hex-based game engine. So I instead worked with what I had on hand. Making Cogmind as a 7DRL would've been absolutely impossible without the benefit of a great starting point: the X@COM codebase.
Think of Cogmind as a total conversion mod (and then some) of X@COM. Before the competition, I stripped X@COM of most of its X-COM-specific gameplay to create a generic roguelike engine on top of REX (my SDL game engine) called 7SHELL, so named because it is a great starting point for 7DRL development. The vast majority of the Cogmind code is directly reused from X@COM--even the Cogmind data files still contain tons of reusable X@COM data. Just by looking at Cogmind you can see it's obviously derived from X@COM (in fact, some of the things it includes are from still unreleased future versions of X@COM); even so, there were some fundamental changes that make it quite a different game:
- Team-based became single-player
- 3D became 2D
- Action point system became an "ADOM-esque" energy-based action mechanism
- (Then of course there's the completely different mechanics)
In the future I might fix up and expand Cogmind a little if the demand is there, but the hackish nature of the code will keep me from wanting to put too much more time into it. If it was going to be much bigger I'd probably restart from scratch. Also, now that the game is done, and looking back over the old design docs and list of cut features above, I have to say that Cogmind probably benefits from being a simpler game than originally planned. It already possesses a lot of dynamic gameplay under the current mechanics, and could easily become far too complicated with any more systems beyond the current build and rebuild theme where already you have to juggle resources, tactics, special abilities, and a huge number of parts.
The game seems to have turned out okay, although there wasn't enough time to spend on balancing the difficulty. It should be fairly easy to consistently beat the first several levels once you know how to play, but after that it can get difficult if you don't have enough gameplay experience. Now that I think of it, that's probably the way it should be... The game is winnable, but you've got to get good.
There will probably be some more postmortem posts about development soon.
Powered by Blogger.