Official development blog

Beyond the Design Doc: Unplanned Cogmind Features

Building a solid game calls for a good design doc. Laying out at least the core vision, along with preferably additional details about how features and their implementation work together as a coherent whole, is a much safer way to develop rather than repeatedly wandering down the wrong path and having to backtrack.

Even back in 2012 the Cogmind 7DRL had a design doc, honestly even more important in that case because you need some real direction and focus to ensure completion of a game like that in a week! Not the best example, being my first ever attempt despite years of prior dev experience (during which I never finished a game, go figure!), but it served its purpose, and I’ve since written many more for other potential roguelikes.

The most relevant among those would be Cogmind’s own, which when the project was resurrected the next year (2013) grew from 1,119 to 18,000 words. That doc was updated and expanded throughout two years of pre-alpha development, natural during such a phase while the world and systems are still being molded into a concrete shape, and had grown to 30,000 words by the time Cogmind’s first version was released in May 2015. At that point the core of the game was complete, and the rest of the features necessary for the full experience had been mapped out, thus the plan was to more or less stick to the doc while finishing up the game.

But… things didn’t quite go down that way :P

With decent support for the alpha release, I immediately started instead looking at all the untapped potential that could be unleashed by filling gaps in the design, adding to the density of the experience rather than emphasizing its breadth. (The design doc was honestly more interested in the latter.) So I ended up setting aside the doc and working on other features--in fact, I didn’t even get back to working on stuff from the design doc proper until six months after the first release! (in December 2015 with Alpha 5)

So today I wanted to show what this means for a post-Alpha Cogmind. Essentially, how much of what has been implemented throughout two years of alpha development wasn’t actually planned to be part of the game to begin with? Sure the original game as described by the doc would’ve been good, but the extended “early access” development period has been a great success in terms of improving it further.

Each section below will also come with a mention of what else might be in store, because, well, we could be in Beta for a while as I continue adding stuff :D


Larger systems that hook into multiple aspects of the game are my favorite thing to add, where possible, since they allow strategic options to grow exponentially, forming the backbone of what players generally consider to be “depth” when it comes to gameplay.

Post-release Alpha development started out with a number of unplanned systems, features that made a lot of sense to add before expanding the breadth of the world (the layout of which was otherwise fairly linear when Cogmind was first released). Naturally the design behind new maps would be better off if they could take into account all the same systems at inception, rather than having to retroactively adjust all those maps later!


Traps are common enough in roguelikes, but honestly I’d never really considered them. Even the 7DRL design doc made no mention. The spark was a random comment on r/gamedev‘s Screenshot Saturday, one that apparently happened to come at just the right time. (Score another point for sharing info about your game with as many people as possible, as early as possible, and engaging them in conversation!)


Intentionally triggering an explosive trap to damage nearby bots (since they’re much weaker than Cogmind!).

Inclusion of traps in roguelikes is often controversial these days, though it’s easy to see where the faults lie and within Cogmind’s design it wasn’t too hard to circumvent those issues. The main reason it suddenly felt right to add traps at the time was that one of the more common requests from early Alpha players was that they wanted more environmental interactions. I didn’t want to go as far as full area-based environmental features like water, lava, smoke and whatnot because Cogmind’s design focus is on robots, plus such features would need to be built in from the ground up as a central consideration of many mechanics, the AI, overall map design, and more. (You either go all the way with it or don’t include it at all, otherwise it’ll feel out of place.)

But traps were a relatively simple way to provide more environmental interactions in the form of isolated objects. I’ve written a lot more about the subject here, and after that traps even became extractable so they could be carried around and relocated.


Luring a Sentry outside a garrison after placing EMPs.



Art for some of the trap items.

Fully implementing a new system also tends to suggest multiple related features, thus with traps came a new type of map area: Waste. Unlike shaft or chasm behavior found in other roguelikes, Chute Traps taking the player to a lower/earlier floor in Cogmind wouldn’t work very well. Instead, it brings them to a special “map between maps” that eventually leads them to another part of the same general floor they were on (after surviving whatever happens to be down there :D). Waste maps ended up having other implications for both lore and strategy as well.


The earliest versions of Cogmind had no garrisons or Garrison Access points. This presented a couple design problems, most importantly that it was a lot easier to find exits by simply searching in the direction from which newly dispatched pursuers were approaching. It also meant that since you might be quite far from any exits, enemy responses to your activity could seem fairly sluggish.

Adding Garrison Access, or a new type of “special entrance” for combat bots, both increased enemy response times and made escaping less trivial. The system also links into many other aspects of the world, such as affecting localized difficulty by dispatching reinforcements to fights in their vicinity (dangerous!) and offering a new avenue for hacking interactions (the access point itself). Because it wouldn’t do to have these robots coming from some unreachable place, it’s possible to enter the garrison itself, adding yet another type of “map between maps.” Opting to enter could be for the good combat loot, to take out relays and improve robot hacking potential, weaken enemy resistance capabilities in nearby maps, possibly tunnel to another map, or maybe just a last ditch effort to escape other problems?


Unlocking a Garrison Access point.



Sample garrison interior layout (labeled).

More detailed info about Garrisons was written back when they were first introduced.

Unauthorized Hacks

Also in early Alpha, with players of course still calling for more ways to interact with the environment, I decided that machine hacking could provide more variety there while remaining within the confines of Cogmind’s general design principles. Sure there were already a lot of regular commands/targets for players to hack, but what about all the possibilities that become available if we start allowing Cogmind to use interactive machines in ways that weren’t intended by their creators? :)


Nuclear Reactors previously infected with a Trojan that detonates them if an enemy passes by.

The system was first described in this post, covering the beginnings of both Trojans and brute force hacks that add strategic and/or tactical elements, depending on the hack. It’s great because with such a system already in place, there’s plenty of room to expand it, so I’ve been doing that bit by bit over the years with new hacks, and will continue to do so. (As of now there are 22 different unauthorized hacks, double the number introduced with Alpha 4.)


Beyond early Alpha there was a long lull in non-design-doc systems being added to the game, mainly because as mentioned earlier it becomes harder to insert them as the world grows (plus there was still a lot of meat to get on to anyway!). But as development reached into the end-game, enough time had passed to get a feel for the strategic value of mid-game areas, some of which were still clearly lacking. I want every area of the world to have its own reasonably useful purpose that not only fits into the lore, but also makes it a worthwhile visit for at least some play styles.

So during a second pass over some of those areas, a new form of (sort of) hacking was born. It’s rather spoilery so I won’t go into the details here, but it significantly impacts how a run plays out once Cogmind gains this ability. The idea was to give anyone, not just those with a good hackware setup, access to limited capabilities along the same lines that hackers have. This feature spans a wide range of benefits including information warfare, build assistance, combat support, and more, essentially tying it into the mechanics on multiple levels. With its minor drawbacks I’ll admit it’s somewhat OP in its current state, but I plan to address that later. For now it’s a nice crutch for those who want to take advantage of it :D

Derelict Logs

Data logs found lying around in various outlying cave areas were added for Alpha 7, which was the first release to finally include caves at all. Caves were planned from the beginning, but like many map designs bringing them to life and giving them strategic value required adding new mechanics and unique content. I didn’t always know what form that would take beforehand, but with caves it made a lot of sense to have them contain data collected by Derelicts, the area’s primary inhabitants, many of whom are also interested in keeping tabs on activity in the main complex.

These logs are essentially free information that improves the player’s chances of survival at a later point in the game, providing an extra benefit for going into the caves, which are otherwise somewhat dangerous and not always worth a trip (especially for those players who turn back before reaching the best rewards at the end).


Derelict Log item.

This turned into a fairly big system on its own, as it was integrated into the terminal hacking and dialogue systems as well (meaning talking to certain NPCs could provide similar benefits), and the amounts and types of information logs reveal can vary greatly. Logs can locate stockpiles, traps, exits, hidden doors, sentry positions, key locations on the world map, and more.


I’m the least certain about future possibilities for this particular feature category, since expansive new systems can be hard to edge in without without having too large a destabilizing effect on the rest of the experience, requiring a wave of rebalancing and in turn yet more unexpected ripple effects. Not to mention the later in development, the more work required to fully integrate each new system.

One of the larger Alpha changes back in mid-2016 was a revised Fabrication system, though that was more of a simplification than a complete rework so the subsequent negative impact was limited.

Robot hacking, on the other hand, is definitely slated to be replaced by a new system. I wrote about its first implementation before release, and made adjustments later in Alpha, but it was always an incomplete placeholder system that has repeatedly shown its weaknesses. (It was hard to settle on a good design in the abstract pre-release days during which there was extremely little full-run testing, so the plan was to wait and see. Actually machine hacking was handled similarly, but ended up easier to improve via incremental patching.) It’s taken a while to come up with an alternative robot hacking system, and building it will be quite a project, but will be worth it for the range of new play style possibilities.

World and Lore

As Alpha came to a close Cogmind had 31 map types, 5 of which were not mentioned in the design doc. Waste and Garrisons I covered earlier as part of their relevant systems--those were added more for mechanical reasons, but several other maps were created primarily to flesh out the story.


World map interface with a sample route.

Although fairly easy to ignore for those players not interested, the story and its background are meant to be epic. But with that “epic story” only about three-quarters composed at the start of development, along the way I had to keep an eye out for the best opportunities to fill gaps as naturally as possible. (This approach worked out rather well, leaving a little bit of flexibility at the fringes.) That’s how we got the Deep Caves and Lab, and is also the reason Alpha 13 expanded Zion beyond its original scope. In fact, the major NPC now found there was not even part of the story to begin with!

Technically most maps grew beyond their initial scope as described in the design doc, as each needed enough content to make it a special experience of its own rather than just more of the same in a different flavor. This meant that adding a single new map could require up to two weeks: I ended up writing “mini design docs” for every single map, each of which became an avenue to introduce new items, robots, and even entire mechanics. The biggest deviation from the world plan involved one of the final maps. This most secret map of all was originally going to be not all that secret, nor all that hidden, but its nature changed significantly when it came time to actually create it, initially for lore purposes but then also to provide an even more difficult challenge.

With the world growing over time, and plot with it, the intended 3-4 different endings also weren’t quite enough. By the time development reached the end of all plot lines, it seemed that 7 endings was a more appropriate number :). Although many of the circumstances leading to each ending were achievable in earlier versions, proper endings weren’t added until Beta 1. Adding them intermittently, one at a time, would have been much less efficient, whereas implementing them all at once kept the quality consistent and made it possible to build a comprehensive system capable of satisfying the different needs of every ending at once.


Tracking who what where why now?

(There are still other elements that fall into this category, but it’s hard to talk about them without posting too many spoilers. Examples include the map shortcuts and “DM conduit,” where the latter is a result of a pretty strong driving force throughout development: repeatedly asking the question “what should happen if the player decides to do… this?”)


While it’s not a good idea to reveal absolutely every detail about the story (leaving just enough room for speculation and imagination helps draw players deeper into the world!), there is definitely more space to explore along the edges, even if only tangential to everything else that’s going on. In that vein I’ve been considering several more maps and even a couple new subfactions which might one day be added. And of course each map will in turn need more unique features to flesh it out…


As a roguelike grows along with its community, and the theory behind much of the design doc becomes the reality of watching players interact with systems and content, it’s inevitable there will be plenty of balance changes. While these changes don’t normally spawn entirely new systems (balance is more often about tweaking what’s already there), as part of efforts to cut down on experts using cheesy tactics to farm points I did introduce a “high security” mechanic. It’s a pretty heavy-handed reaction from the world that essentially tells players to “get out now while you still can” :P

Scrap was another unplanned feature added for balance purposes, piles of junk containing potentially useful parts. They can be a lifesaver in the caves where spare parts are otherwise scarce, and like traps they offer a new point of interaction with the environment (here the equivalent of treasure chests). Of course, that scarcity was created by another unplanned mechanic, self-destructing parts, which made it harder to salvage bots there in the first place! (And that bit was added to balance the caves in the larger picture.)


Scrap item info.

Overall, though, Cogmind has reached a fairly balanced state. There are still a small number of exploits to address, strategies that have emerged organically from the mix of so many mechanics and systems, though by not dealing with them right away, directly, final solutions can be integrated into other features yet to come, holding the design together more tightly. For example it’s likely that a new type of clock will emerge as part of another non-design-doc feature that I’d like to add at some point, and that can be built in such a way that it closes off some exploits as well.

Quality of Life

“QoL” would have to be the largest single category of unplanned features, getting significant new additions with every Alpha release. While Cogmind has always been relatively accessible among traditional roguelikes, there are so many different ways players might want to approach the game’s information and UI, and not all of these will be apparent until lots of different players are actually playing!

Honestly there was almost no playtesting during pre-Alpha (the public 7DRL before had already proven the core mechanic was fun, and that was enough for me at the time!), but once everyone (including myself :P) started tackling full runs there were very obvious areas with room to streamline the experience. The first release was fun, but it would be annoying at best for the UI of today to go back to that state after getting so many extra features. Some of the bigger ones, for example…


Smart inventory management (Alpha 5c). Cogmind is full of inventory management decisions, but a number of them are no-brainers so why not have the game just take care of those automatically!



Automated part sorting (Alpha 9). Long parts lists are harder to parse when they’re not organized, and repeatedly doing it manually is probably a waste of time when the game can just group like parts for the player. (Note: The visual design process for this particular feature I’ve written about before.)



Evasion breakdown (Alpha 10). There was originally no way to easily check just how effective your evasive capabilities were at any given point, since it’s the sum of many factors, but now there’s a single number and summary available right on the HUD.



Manual hacking code recall menu (Alpha 10). Before this feature it was generally necessary to write down the 4-character codes you discovered and might want to use later, but they’re only valid during that run, and you may not even get a chance to use them anyway, so it was a pretty wasteful requirement.



Slot-based part swapping (Alpha 11). For a while those players using a large inventory as part of their strategy might have to spend too much time searching for the right item. Inventory sorting has always been a thing, which helped somewhat, but why not make it possible to quickly pull up a list of valid items to choose from? :D



Manual hack autocompletion (Alpha 12). While a command buffer was added early on to simplify the process of repeating manual hacks, there are also somewhat lesser used hacks that would end up far back in the buffer, not to mention the continually growing number of hacking possibilities (91 as of today…).



Additional data visualization modes--only four were planned, but we now have eight, as well as accompanying number values. This feature was initially designed for bar graphs only, since the point was to show relative values, but it turns out that having specific numbers is useful as well.

Difficulty Modes

At first I was reluctant to add separate difficulty modes (discussed in detail here), but they do make a lot of sense for accessibility. So far they seem to be serving their purpose, but the true results won’t be in until available on Steam, where Cogmind will be exposed to a greater ratio of players not already familiar with the genre.


Setting Cogmind’s difficulty in the options menu.

I did later adjust them such that some areas are inaccessible to easier modes, partially because those areas are quite difficult by their nature (regardless of mode), and also to give players who can consistently reach them in easier modes some impetus to up the challenge. (It’s still possible to win in any mode--these are just outlying special/lore areas.)


With any sufficiently expansive game there is nearly endless potential for QoL improvements, much less a roguelike that continues to get new content updates over a long period. Most of the existing features are taken care of pretty well, but I’m sure this category is incomplete even now--it will grow in response to playtesting and feedback on new features (and to a lesser extent as a result of new types of players joining).


There are many ways to add value to a game beyond the core experience, though naturally these kinds of things should wait until later in development so there’s actually something to build off (also so it’s more apparent where the greatest value for effort can be found). While I’ve always had some “meta” ideas floating around, none of those considered early on have been implemented. Instead, as alpha development neared completion I worked in newer ideas that seemed best at the time.

Lore Collection

The world of Cogmind contains quite a bit of useful (or just interesting) information among its lore. The way that lore is acquired, however, across many runs and from numerous different sources, doesn’t really lend itself to forming a coherent picture of what’s going on. This would be less of an issue if there were a single plot line, but the story is more a web of factions and NPCs with their own agendas and take on things. That and the lore includes quite a few tips regarding how the world works. So it eventually became obvious that we needed a central repository for all this lore, some way to conveniently reference it all.


Testing the lore collection UI (Alpha 10).

Of course meta features are often also suitable for application outside a game (e.g. integration with external programs). For example players with a growing lore collection would like to be able to read it when not in game, or even in interact with it in some other format…


Sample HTML lore export, including links (Beta 2). (Also supports exporting to TXT and CSV.)

(More on the lore and story-related features here.)

Challenge Modes

As the world approached completion in late Alpha and a handful of players had seen much of what it had to offer at the time, special modes that add new rules or enforce certain restrictions on play seemed like a fun and easy way to increase replayability. There are currently eight such modes (ideas are sourced from the relevant forum thread), with many more to come. They’ll also need their own options menu UI, as opposed to the current method of control purely via the config file.

As with difficulty settings, early in development I’d never really thought about a need for extra challenges, aiming to create a world in which certain optional areas and approaches would naturally be more challenging. The ease of tacking on new challenges makes it really tempting at this point, though, considering there’s such a high reward-to-effort ratio!

Gallery Item Stats

Players had been asking for a while if they could have access to item information via their art gallery, essentially turning it into a makeshift stat compendium. During the Alpha design process I realized this is not the ideal way to present such information, and came up with an alternative, but that alternative would also require a rather long time to implement… In any case, enough players had been asking long enough that it was time to do something :)


Item art gallery with stat access (Beta 2.1).

Sure enough, after adding this feature there were a few comments about how they’d now like it to be able to do XYZ. At least I can say that if it ever comes to be, the alternative could do that and more. That’s the thing about adding features as per player request--fulfilled requests often become the new launching ground for more requests xD


Other meta features are generally of secondary concern, so it’s hard to say much about the future of this category other than that it’s far from exhausted. I’ve always wanted to redo the score sheet, though, a project waiting on the sidelines since it’s best done as late in development as possible where all the different needs it has to accommodate can be taken into account. (The only thing worse than redoing a feature is redoing it multiple times! Really though a first “redo” of the score sheet is warranted since it hasn’t been redesigned at all since the 2012 7DRL, just expanded again and again :P)


The broadest category of unplanned features is composed of numerous smaller bits used to fill cracks in the design, either for balance or sometimes just for fun.

One of the more frequent goals here has been to make combat more viable and varied, since the environment and overall mechanics otherwise tend to give the strategic advantage to those who prefer (and are capable of) avoiding confrontation. While that tendency will never be fully reversed, combat became a lot more interesting, and reliably winnable, as Alpha progressed.

Some examples involving differentiation of combat styles:


“Gunslinging” was only added in Beta 1, allowing a single volley composed purely of guns to be redirected across multiple consecutive targets. Before this it was easy to waste shots on a target that was already destroyed. I originally considered that part of the tactical considerations necessary for turn-based volley combat--fire many weapons and risk overkill, or fire fewer and risk the target surviving to continue the fight? But the volley timing adjustments later in Alpha made that consideration less and less of a factor anyway because firing extra weapons required almost negligible additional time, just additional resources.

Cannons also got their day in the sun, with an overflow mechanic allowing surplus damage after destroying a single part to transfer to another part. This had the greatest effect on powerful late-game cannons that might otherwise blast a weak part but then have no other effect, making them randomly ineffective and unreliable. (There is still some room here to further differentiate cannons and guns, for which I have some ideas.)

Melee combat wasn’t part of the 7DRL version, and while I added it to the commercial version because it’s cool (and players would expect it!), it was meant to be relatively niche, had to be balanced against ranged combat, and ended up being underutilized for a while. By late Alpha the core combat styles were pretty clearly defined, so it was time to revisit melee and do something to make it more desirable. Many somethings were done :P

Actuators and other utilities were added to help builds with a melee focus (Alpha 11), sneak attacks provided another tactical edge (Alpha 12), multiple targets could be hit with a single swing (Alpha 14), and most importantly, melee-specific multiwielding became a thing.


Attaching multiple melee weapons at once (Alpha 14). Players designate a primary weapon, and other weapons might contribute to attacks.

Additional damage types were also created (secret, so I won’t mention them here), and some of the existing types were given new effects:

Thermal weapons were given a dedicated heat transfer stat, rather than being a simple side effect of damage (Alpha 12). By decoupling the two, heat transfer could become a goal of its own, either to cause meltdowns or for its other negative modifiers. Before that the thermal weapon design space was quite limited because heat transfer always had to play a secondary role to damage, and a weapon with better damage would also be better at transferring heat, so it could only make good weapons even better rather than serving as a point of differentiation.


Overheating a robot with lasers.

Electromagnetic weapons were given a “spectrum” (Alpha 4). Their attacks sometimes causing chain reactions in robot power sources made the EM tactics game somewhat more interesting, especially earlier in a run where it happens more often (due to the types of weapons).


Triggering a chain reaction in Grunt’s power source via EM Shotguns’ spectrum.

Impact weapons were always something to be avoided, in both senses :P. Essentially they were quite dangerous in enemy hands since they could smash your processors and weaker parts, but useless to the player who would rather outright destroy targets than cripple them. Once given the ability to inflict significant system corruption by smashing parts (Alpha 14) they became pretty decent.


Corrupting bots with a Shock Maul.

Once the main game was completed earlier this year, it became easier to explore extra features that might work out, rather than focusing mostly on what absolutely had to be done at each phase of progress.

One result of this experimentation was “visible sound effects.” For a while I’d been thinking of closed-captioning sound effects for accessibility reasons, but simply showing color-coded sound effects would already be a big step in that direction, and far easier to implement. Plus it’s a tactically interesting new way for everyone to view the map, rather than just those who might benefit from captioning. It’s worked out pretty well!


Visible sound effects for combat occurring nearby but out of view (Beta 1).

I also came up with an optional way for players who really want every single combat detail to get that rundown on the map rather than squished into a small secondary log not really made for that much info.


On-map detailed combat log (shown here closer to the action than it really is) (Beta 1.2).

But the miscellaneous features I’m most interested in exploring, beyond the design doc, beyond even strict balance considerations, are unique parts with either excellent stats or sometimes completely new mechanics. Content like this won’t have to take into account balance in the same way as previous developments, because these parts are not at all guaranteed (unlike pretty much everything else in the world--an intentional design decision enabling players to somewhat plan their build/strategy ahead of time). I’ve relied on this principle in a few places in the world already, but prior to Beta it was more important to keep the core game balanced for proper testing. So there’s still a lot more that can be done here, and it should make Cogmind even more fun--after all, there’s nothing wrong with getting to feel OP for a while if it’s not something you can do every time!


Now, obviously a massive collection of features were planned from the beginning, but not nearly everything we have now! Technically none of the features discussed above would’ve happened had I strictly gone by the docs and worked straight through Alpha to 1.0. Imagine how different Cogmind would be without garrisons, trojans, imprinting, automated UI features… and all that other stuff!

The point is, design docs are really important, especially in clarifying the vision for the experience and setting down basic principles to build a world based on that vision, but in the best of cases it can also be treated as a flexible framework on which the development process can expand. Pre-Alpha and Alpha finished the design doc over four years and even let a lot of other features leak in at the same time, while with Beta it’s clear sailing with more ideas to explore on the horizon :D

This entry was posted in Design and tagged , , , , . Bookmark the permalink. Trackbacks are closed, but you can post a comment.


  1. kripto
    Posted July 25, 2017 at 5:34 pm | Permalink

    The real design document was the friends we made along the way.

    It’s certainly odd to imagine Cogmind without so many of the features that set it apart in the genre. I guess it also goes to show that many of the truly great games out there are the result of taking as much time as necessary to iterate, explore and expand on what the original outline was, rather than finishing what was laid out at the start and working on getting it out the door as quickly as possible.

    • Kyzrati
      Posted July 25, 2017 at 6:48 pm | Permalink

      Time is key, for sure, and really that’s how all the best roguelikes are created, iterating over a very long period. I’m very glad this was possible!

      Though I’d see these individual features less as what sets Cogmind apart and more as just elements that built on or enhanced what was already there. One word I neglected to use in the article, but which really applies to much of this stage of development, is polish. The true innovations were implemented before all the polish, in pre-Alpha, like drag-drop terminal UI, on-map labels for everything, heavily-animated ASCII UI, extensive use of sound effects, location-sourced ambient sounds… a bunch of things that surprisingly no one’s been doing over the years in traditional roguelikes. (I made a page to showcase these a while back, though not on the blog.)

      “The real design document was the friends we made along the way.”

      Haha, it’s great to see some of the same names that have been around since the years when I first got into the genre and was working on X@COM :D

  2. Quadko
    Posted July 26, 2017 at 5:23 am | Permalink

    my first ever attempt despite years of prior dev experience (during which I never finished a game, go figure!)
    Ain’t that the truth. Professional developer, been trying to finish a game since I was a teen -- like 30 years now. Last 10 years keep starting successively “smaller” projects trying to get at the heart of something I could complete! But same mistake every time.

    This summer I finally put some advice together (including encouragement of your e2e release, thanks!) and have been sprinting on a minimum viable CRPG trying to get to an E2E alpha release ASA(r)P. I’m amazingly close, can’t hardly believe it!

    Advice read a few times but never before followed was that if you have an end-to-end game: start screen, win & lose & highscores as appropriate, and minimal gameplay connection between them for your game design, then you can spend whatever time you want later “broadening” the workable skeleton with features and “release at any time” as necessary. If you start with broad features like I always did then it’s impossibly hard to “lengthen” that complexity to an end, especially if there is a time or resource constraint. As true of professional projects as as personal.

    I’m guessing the design doc serves a similar purpose, as well as the benefits of planning and other pre-thought. Your post also reminded of the Eisenhower quote “Plans are useless, but planning is indispensable”. I’m glad you subverted the plan for good features, but glad you planned so you had a path to improve. As always, thanks for sharing the gory details on the ground, it’s a big help and encouragement, and lots of fun to read!

    • Kyzrati
      Posted July 26, 2017 at 8:59 am | Permalink

      I’m very grateful for the whole 7DRL process, which was exactly that, a forced end-to-end project that turned out to be an excellent framework on which to build and build and build… Just last night after finishing this article I was thinking back to years ago and wondered where I’d be today if I’d never done the 7DRL :) (likely a very different place :P)

      Love the Eisenhower quote! Past the core game implementation that’s certainly how I operate, with lots of plans constantly being devised and tweaked in the background down on the todo list, where they float around and trickle upwards through various levels of priority as they mature. (I don’t use the design doc itself anymore--in fact I can’t even open the [terrible] program I used to write it, though I do still have an HTML version in case I want to check it out.)

      Good luck on your ASA(r)P possible release--starting small is the most important but perhaps most difficult way to guarantee success, “most difficult” only because you have to reign in those grandiose plans and distill the experience to its fundamentals :D

      • Quadko
        Posted July 26, 2017 at 10:18 pm | Permalink

        I hadn’t even thought of the 7DRL in that light, makes perfect sense! Thanks for the kind wishes. I’m also hoping to imitate you and the rest of the dev bloggers I follow once I have something to download, it certainly increases engagement and is greatly encouraging to read.

Post a Comment

Your email is never published nor shared. Only the anti-spam entry is required. See here for the privacy policy.

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>