I tried to shorten this one by cutting much of it.
Carcere Vicis: Developer Retrospective
Intro
<tmc> I've always found that game contests are the only thing I can really focus on completely
Because the 2014 Random Collab Contest ran for two weeks (Feb 15th to March 1st), this was my most ambitious contest game yet. Ridiculously overambitious; I'm still amazed that I managed to produce something somewhat playable (until you hit the bugs), and I had to put a crazy number of hours to get that far and release only several days late. I know I have this horrible tendency to write code instead of actually creating a game, while overpromising, and it sure happened here.
Honestly I didn't know it was that buggy; I really did think I'd fixed the major bugs. Unsurprisingly given the actually highly buggy and unpolished state of the game, reviewers pessimistically treated it as an attempt to win a contest by showing off another tech demo, rather than a serious attempt at a game with its own merits. In fact, Master K and I always wanted to ensure it would be worth playing (and worth continuing after the contest) by working in unique features that would set it apart from other roguelikes; that appeared to be the ambitious part at the time. That was also part of our downfall: the phase shifting and soul collecting mechanics were done in a far too complicated way that was difficult to balance, created a lot of work and worry, and was difficult to convey to the player.
<tmc> so
<tmc> do you have any ideas for a game?
<tmc> I'm getting rather sick of always entering tech demos for contests
<tmc> might be nice to do something more traditional... bnut I would still want it to be unique in some way
<tmc> I think that if we try to avoid RPG cliches whenever we notice them, we would naturally end up with something rather unique
How it happened
I didn't have to be this way. I started off without a plan, and offered to draw graphics -- I enjoyed making most of the graphics for Ortega Colonies.
<tmc> maybe a roguelike?
<MasK> Oh!
<MasK> A roguelike, yes
<MasK> I love roguelikes
Oh. I'd wanted to blame this one on K. Well, he started telling me about an idea for a RL he already had. Over the the contest he designed up with the dungeons, enemies, items, and npcs and I mostly left him to it.
<MasK> Dungeons could follow a sort of theme
<tmc> that could be nice, if deciding which dungeon to go into is an interesting strategic decision
For a while I was against even having a hub town, to save on work:
<MasK> Are we gonna include, say, overworld areas?
<tmc> sounds like it could be unnecessary
<MasK> At least a hub town
<tmc> though even that can be replaced with a shop menu!
The first hint of the elemental plane stuff was due to Master K, who suggested shrines in the dungeons (an idea that had to be cut; they might still be nice, but depends on whether we make other changes to the elemental system):
<MasK> I got the image in my head
<MasK> Of say
<MasK> Stealing an enemies soul/life force
<MasK> Sacrificing it to something
<MasK> And recieving something based off that
<MasK> Like an uncommon drop from an enemy
But I still wasn't happy; I was quite serious about creating a unique game.
<tmc> sure it might not have been done on the OHR before, but it's sounding like a fairly standard RL without much differentiation so far
<tmc> really, I would love to create an RL that feels like it's a living world; I'm not so much interested in hack and slash
Faced with this self imposed requirement, I twisted Master K's soul-collecting idea into elemental "charge" which directly increase the player's power, allowing getting rid of a normal level-up system.
<tmc> I came up with a quite detailed idea for moving between elemental planes/dimensions
<tmc> I know shifting between different planes has been done by several RPGs (one of the zeldas?), but I haven't played any of them
<tmc> seems to be relatively unexplored in RLs anyway
<tmc> I asked in #rgrd and a couple people said they'd seen a couple experimental RLs that have a light and a dark dimension
<tmc> (one of them set in a pysch ward)
<tmc> if it literally acts like charge you could charge up your sword with "ghost" charge by hitting lots of ghost-type enemies
<MasK> Oh, now that's cool
<tmc> (on that note, i don't think xp and a levelling system is needed at all if there are other methods of building up stats/abilities)
How to design a game
Planning a collab game is a game where one person suggests something and the other doesn't say no!
<MasK> Different classes of characters for the player to chose from?
<tmc> sure
<tmc> well
<tmc> the alternative is to build your character during the course of the game
<MasK> I had the picture of aiding an injured hero out of a dungeon
<MasK> Random events would be awesome
<tmc> yes, only problem is that they might be a lot of work to design
<tmc> prehaps not much work to actually implement though
(Didn't happen except for quest items.)
<MasK> How about dark dungeons?
<tmc> my shadow casting script is for line of sight only; a lighting system could also be added
(Master K was keen on lighting but it turned out to be technically difficult.)
<MasK> Will players be able to upgrade weapons?
<tmc> sure, could be fun
(There are enchantment scrolls)
<tmc> I will definitely script custom menus
<tmc> hmm I hadn't given much thought to random map generation, but I think it won't be too big a part of the project, if I don't go overbouard
(hahaha)
<tmc> multitile enemies may actually not be very hard to implement
(you know what... maybe he's right!)
<tmc> we could list the equipped weapon too
<tmc> and maybe print the names of any visible enemies
<MasK> That would be neat
<MasK> I could easily write up small bios for enemies
<tmc> that would be nice
(The bios are actually in the game but with no way to access them)
<tmc> I think the graphical inventory is one thing to ditch
(Who needs a graphical inventory when you can just drop everything on the ground and look at it there?)
The decline
Master K quickly drew most of tiles in the first few days, while I worked on a bunch of general scripting without I think that this time I spent much less time working on OHR features/bugs and my script preprocessor than I did when making Ortega Colonies with Hawk. I focused early on items and the inventory system, and I think that's the only thing that was actually working in the first week. Turn-based movement, enemies, and melee combat weren't working until late in the contest. and the map generator was put off until even later, so there wasn't even a game to play until the last few days (possibly already AFTER the deadline).
I didn't even commit to using random map generation for quite a while, knowing it would be a huge time sink (it was) but tried to figure out the easiest way to do it. In the end generating rooms and corridors wasn't too bad, while placing furniture and special rooms, decals, items, enemies and stairs added up to lots of complexity, and I wasn't happy with it.
Feb 23 <tmc> so, needless to say, we're kind of in trouble
Feb 23 <tmc> I'll try to get the thing somewhat playable today though
Feb 23 <tmc> maybe if we scrapped MP, and made all spells single use scrolls...
Comparing the feature list that we wrote up for the game and what was delivered, most features that didn't get scrapped early were actually implemented. Ranged weapons and most of the planned spells were removed, as did attack animations, which was definitely a problem because simply bumping into enemies gets old and limits tactical choice. Other big scrapped features were shops and sacrificing elemental charge. Yet a number of stupid "bonus" features made it into the game, like being able to pick items up from an adjacent table.
Design flaws
Unfortunately the main thing that didn't make it into the game was playtesting. Whenever I tested the game I would immediately encounter bugs, so I'd be debugging rather than playtesting, and Master K couldn't play the game either. The attempts that I did make to balance it were sabotaged by incomprehensibly complicated calculations for damage, hit chance, equipment damage, and even item drops.
Given a quantity to decide (e.g. melee damage) I would think of things that should affect it and then proceed to give each of them an additive or multiplicative bonus, and then stupidly made them stack in complicated nonlinear ways; for example the bonus for of your virtus stat might be doubled if you were doing melee combat in the virtus plane. This kind of nuance is pointless if the player doesn't know how it works so can't take advantage of it. I think I actually had the idea that the player should have to work out the elemental plane-specific effects themselves. Well, I suppose that's OK if they're obvious enough, but terms in equations don't fall under that. (Really, it should only be used for game aspects that fall under 'exploration', like the behaviour of the ghost realm; I'd like to move more in that direction.) Since most of the inputs to these functions were already unbalanced (how much virtus should living statues drop?) the net result was just nonsense. The biggest problem might have been that there wasn't a proper stat (or ability as in DnD) system to abstract away what a character's strengths were, instead the elemental charges replaced stats and inputs had direct effects on outputs, rather than indirect effects via stat/ability bonuses. Additionally charges just keep going up and up over the game, meaning you can't use them directly. Levelup systems in RPGs solve this problem by enforcing diminishing returns, but we'd also ditched levels. This is definitely one thing I will rewrite, by adding a set of visible ability/stat scores with bonuses broken down. (Another lame reason we didn't have stats because there was no room for them on the screen.) The ability of equipment to be damaged in combat was another disaster, causing many bugs and usually resulting in your weapon falling to pieces in no time flat.
Charbile complained about catching himself in a fireball. Sort of intentional...
<tmc> sophisticated magic effects like polymorph and area effects are intersting because they have strategic values and tradeoffs (like the risk of catching yourself in a fire)
Well, aside from the fact that you couldn't aim the fireball (it targets the nearest enemy).
There are all kinds of other, obvious flaws (like too much spam in the message log)
which I'm not going to discuss because they're apparent to everyone,
and caused by the contest deadline.
Tech stuff (may as well...)
JSH wrote "[outside a contest] there's no reason to make a game like this in the OHR". I agree other people should think twice, but there's an obvious reason that I push the boundaries of the engine. It's to encourage me to remove them. Unfortunately, most of the scripting in this game was accomplished by the help of a script "preprocessor" utility (which I'd already used for several other things) to make HamsterSpeak less painful by adding shorthand notations. This is married to an awfully complicated system for storing "objects" in global variables or slices and allocating and deleting objects and strings. I always regret doing this sort of thing. Time spent working around engine limitations is usually better spent on fixing the limitations. It also turned into a horrible mess in places because it wasn't thought out, so after the contest I told myself I didn't want to do that anymore, and should add those features directly to HamsterSpeak before continuing with this game. (A couple days later I was back working on it anyway.)
I did however implement several small features (and many bugfixes) during the contest, most significantly being saving slices in savegames. This was the first OHR game to use a resolution other than 320x200, but that wasn't a feature added for this game. It sure got a lot of debugging though. There were several new script commands including "string sprintf", which was absolutely needed to keep me sane when doing all the string manipulation. SDHawk actually also used this command in his entry, Dungeon Cards.
<tmc> to be honest I'm probably a little too keen to use higher resolutions just as a help in debugging the engine
For fun I ported some Python code I'd written for sentence generation for another game. Here are some examples. (
$"text" is expanded by the preprocessor to
$ns="text where "ns" is a script that returns an unused string id. Looking at screenshots of error messages, you might notice that this system broke down when it ran out of unused ids.)
Code:
say($"the", attacker, $"knocks you over!")
you($"snapped up", tostring(count), plural($"item", count))
# (In original Python: you("snapped up", count, "item") )
say($"arcs of electricity shock you as", $"the", attacker, $"strikes you with", $"a", attackerweapon, $"!")
say($"the", weapon_owner, $"'s", weapon, verb, $"as", PRONOUN, weapon_owner, $"parries!")
When "a" or "the" occurs separately they get turned into "a"/"the" or nothing depending on whether the following item is uniquely identifiable or not ("the royal guard", "the Invidia", "a greatsword") or has a proper name ("Somniatus"). 'attacker' and 'attackerweapon' aren't string ids, but actually global variable ids pointing to object descriptors. The final example shows even more complicated rewriting rules: PRONOUN, weapon_owner can get translated into "he", "she" or "it".
I also ported Eben's (squidlib's) recursive shadowcasting field of view code from Java to HamsterSpeak (I should put that on the wiki), whch was relatively a breeze.
Future
I consider the contest version a prototype of the elemental charge and elemental phane features we dreamt up. However it's still hard to tell whether these will work because the game is too unbalanced and unpolished. So the current plan is to put in the work (a couple of major releases?) to try to make the game as envisioned during the contest as playable and fun as possible, e.g. by adding a status screen to explain elemental and phase-shift effects on your stats, and making differences between phases simpler, more obvious, and more interesting. I anticipate that'll show that a lot of the stuff really doesn't work well together, so the next step will be scrap major parts of the mechanics and remake the game. Honestly, I WANT to scrap parts of the game even if they do seem to work, just so I can try something different: if I'm going to create a game, I want it to try something new.
My regrets would be, firstly, not prioritising things differently so that basic combat could have recieved real playtesting. It would also have given Master K more to do; I was the bottleneck at all times (he works fast!), which is certainly regrettable. However he did contribute in many ways: design, graphics, music selection, the story (including text and dungeon designs), npcs, and most of the item and enemy designs. Trying to give him more to do I asked him to draw various tiles and animations that I never had time to use. Finally, I definitely regret not releasing a significant update to the game which was nearly ready a couple weeks after the contest, and which fixed not just bugs and (some of the) balancing but other complaints as well. After the contest there were complaints that allowing large bug-fix updates to the games would be unfair, which I agreed with. However even after voting was over I stubbornly didn't release it because it still wasn't entirely bugfree, and anyway once you release a demo motivation can plummet. Also, I didn't really want to encourage people to play what is still very broken version of this game.
Register
