Rogue Legacy Design Note #4
This was the design note written out for how the procedural map generator would work.
ery light on text, just keywords to refresh my memory. From my experience, having long-winded explanations don’t really help. This is true for a number of reasons:
It’s time consuming for the designer.
It won’t be read by anybody BUT the designer.
It’s restrictive to the creative design process by adding inflexibility.
It doesn’t take into consideration the input of the programmers, artists, etc. I’m not an expert in those fields, so writing details as if I knew how it’d work is stupid.
When things are written on paper, it also adds this imaginary weight to the idea. Like, just because it’s been recorded it is now official and more important and valuable than the conversations spoken. I know that sounds silly, but it’s true. Or at least I think it’s true. True enough for me.
Also, things will never go according to what’s written. It’s impossible to predict how difficult an idea is to implement, or how costly, or how time-consuming. And if you have a design doc, it just adds an extra step to the game development process.
When you’re designing something, especially something that’s complex, it’s best to keep it detail-light. That way when the input from the other team members are heard, changes can be made on the fly. Also, people will always strive to be lazy, not dumb. They’ll try to remember an idea that was mentioned, and if they forget, they’ll ask. Nobody wants to scrounge through a 60-page, massively detailed design doc to find that one sentence which possibly answer their question.
**** Once again I’d like to reiterate that this is how we make games. And it probably won’t work for any teams larger than like… 5.
Rogue Legacy Design Note #5
This note detailed the old Class and Traits system. Originally, genetic traits did not exist in the game and instead, traits were more like “talents”. A character could have major talents which give massive bonuses to mana, and minor talents which gave small bonuses to other areas. It got tweaked a bit, but this original talent system actually got into the game before we scrapped it entirely and built the new trait system (the one that applied genetic effects). It’s one of the few features that got removed from the game wholesale, as opposed to tweaking it to preserve as much of the work as possible.
The game also had the ability to upgrade classes multiple times. The example below was the “Miner/Spelunker”. No example was made for more obvious classes such as Knight or Mage, because they’re easier to do. We had to make sure the system worked for the more obscure classes first. In these notes, the Spelunker was given general bonuses to potions.
That was a pretty lame bonus.
Rogue Legacy Design Note #6
This page is just a clean-up page. While doing the macro design for a game, you’ll visualize in your head a bunch of different aspects, and your notes will be all over the place. This page acted as sort of a mental clean-up, like a “Cliff Notes” that summarized my ideas to make sure nothing was missing.
Doing a summary of your ideas is also a great way to tighten things up, because when you force yourself to really think through the game in a step-by-step process, you’ll start to see redundancies. Doing an overview of the whole thing allows you to combine or remove components from the game that may not need to be separate ideas, or have become obsolete.
Below that note, there is a very light diorama explaining combat, and below that was the beginning of the Architect!
We knew we wanted a way to “lock down” parts of the game but still provide a new experience with each playthrough. The first concept was to lock down specific castle zones after defeating a boss. It was tossed out early due to the fact that:
It was overly complicated to implement.
It was very hard to explain to the player.
It was a stupid idea.
Rogue Legacy Design Note #7
At the top of this attached note page you can see additional examples of the talents (i.e old traits).
Below the note on talents was our “New Loss System”. As mentioned earlier, Rogue Legacy originally had XP and gold. Gold was used to upgrade the totems (which became the manor). This gold stayed with you with each life. The XP was reset, and unless you leveled, all your XP would go back to 0 on death.
Every time you leveled up your base stats raised, and there would be an algorithm to make sure the player could go up an infinite amount of levels. This system was overly complicated, and the things we wanted XP to do in our game from a flow perspective weren’t working.
It was a hard decision, but we decided the best route was to remove one of the forms of “currency” entirely. So we chucked XP, turned gold into the sole way to upgrade, and had gold take on the transient nature of XP along with it.
This change paved way to one of our most iconic ideas. The old XP system provided that rogue-like idea of consequence, because every time you died you lost all your XP. We could not do that for gold because it was tied to your upgrades, so we had to come up with something else. And that ultimately led to the creation of Charon. Rather than remove your gold on death, we forced you to spend it before re-entering the castle.
As a final note, I hated the fact that we cut the XP system. Not because I liked it, but because we added it, and I should of had the foresight to see that it wouldn’t mesh well. I didn’t think it through long enough, and that led to a bunch of wasted development time that could have been avoided.
XP was another system (like talents) that got cut out entirely. No work that went into the XP system was ever retrofitted into other portions of the game. Consequences like that are solely the blame of the designer, so to all you aspiring game creators, make sure you take every idea you pitch very seriously.
Rogue Legacy Design Note #8
This is a short one.
Just notes on general balance problems. I knew starting out we wanted a game which encouraged:
Skill >>>>> Grind.
But we still wanted people who weren’t very good at the game to complete it, so grinding had to be a feasible option. This paper just has general concepts on how to set scaling of player damage, health etc. to make it not feel critical in the short run, but have it play a big impact in the long.
Rogue Legacy Design Note #9
The concept of Fairy Chests were written here. Along with it came the concept of the rune system.
The rune system was to allow people to bind the same type of rune onto a person, and let it scale infinitely.
The original idea for runes was a bit more ambitious in terms of what they could do. For example, one rune would give spike immunity, and adding additional runes would give alternate forms of immunity. Of course that cannot scale infinitely, so we thought about binding runes to a max of 5. That still kept the immunity idea really complicated, not only to code, but to display to the user. So we cut all of the rune ideas which could not naturally scale to infinity, in order to make a cleaner system.
The spike immunity eventually went on to become a special item (Hermes boots).
Hermes boots is legacy from when the game’s story had a much stronger Roman theme to it. As we iterated on the plot, we decided to reduce the amount of specific cultural references to allow us to have a bit more creative freedom.
That’s it. Hope you enjoyed reading all this boring stuff!