PREAMBLE
These aren’t your standard design notes. Not only are they barely legible, but these are much, much lamer. This is also NOT how standard games are made. We’re two brothers who worked with one another at home, and we used Skype to communicate with the artist and musicians. Once you expand to a larger development team, things might fall apart. We also wing a lot of things… A LOT.
Rogue Legacy required about 2 month of time to develop a basic engine and level editor to support the game we wanted to make. It was during this time when the majority of the core for Rogue Legacy was designed. So for this game, the concept was literally being made in conjunction with the tools that would be required to build it. Sort of a chicken or the egg scenario.
***A lot of these notes were for the preliminary design. Additional notes were made as development of Rogue Legacy progressed, but they were more specific to individual issues that arose during production. Also these notes aren’t in chronological order. We don’t know what the correct order is.
Teddy Lee
Creative Designer
Rogue Legacy Design Note #1
Originally, the game was called Rogue Castle. We changed it to Rogue Legacy later on to better represent what the game actually was. I still like the name Rogue Castle though.
This was an earlier concept of the game which had different stats. The two stats that were removed from the player were Stamina and Move Speed. Stamina used to be a tax on the player’s swing, to prevent swing spamming, and move speed was moved onto runes. Players also used to gain XP from killing enemies. XP was used to upgrade your skill tree (rather than gold), and these skills were called traits, because you were using XP to increase the strength of your genetic lineage back then. It was really confusing. The nomenclature for the game kept changing during the early phases of development which caused a lot of headache.
So instead of gold for skills and runes, we had gold for runes, XP for traits, and the traits in their current form did not exist (things like Colour Blindness and Muscle Weakness).
While we were changing the names, our conversations with one another got really confusing. And the longer we used them, the harder it became to change. So if you’re making a game, and you have mechanisms which work similarly but are still different, it’s important to get the terminology down right at the start.
Believe it or not, Rogue Legacy was not the first time we created a castle that grows as you spend money on upgrades. Rather, we first implemented it in a reverse tower defense game we made called Villainous. It was so effective that we knew we wanted to do something similar for RL. It’s a TON of work though, so rather than a complex castle, we decided to go with a much simpler tree design (also a reference to family trees). We ended up going full Villainous in the end though, with a complete growing manor, because it was an integral part of the game, and short-sticking it so early on would have been a mistake.
The original growing castle
The system for death => Upgrade screen was already set at this point.
Also, when you died, the family lineage concept was called a leader board, but it more or less did what it does now. We just called it a leader board back then to make it easier to visualize.
Rogue Legacy Design Note #2
This note talks more about our old skill tree design.
Rogue Legacy’s skill tree design was originally planned to be closer to Kingdom Rush, and we called the skills “Totems”. As you placed skills in the lower parts of the totems, the higher up skills unlocked, thus the name.
This system seems weird now, but back then the format for the game’s main progression wasn’t designed. We wanted to make defeating bosses extremely rewarding, so they originally unlocked additional totems for the player to “skill up”.
Below that is a list of bonuses these “totem skills” would reward the player with. It’s not an exhaustive list because details like that in the early design phase aren’t necessary. Instead, what’s important is to show exactly how FAR REACHING an effect you wanted the skill tree to have on the game. Macro focus over micro.
The original design for the growing skill tree. It was literally a tree.
You can see from the notes that we were aiming for mostly passive skills. But even though they were passive, each listed skill had its own unique set of implementation rules that (in my mind) were important enough to look out for because they may have been tricky to code (I’m not a programmer).
IE.
- Point 14: Less damage from pits means we’d need to make environmental hazard damage unique from all other forms of damage.
- Point 19: Better Item drops means we’d have to create an algorithm which would accommodate a way to modify drop rarity and rate (which we scrapped).
- Point 20: Damage resistance might imply global damage resistance, or damage resistance specific to certain attacks (does point 20 stack with point 14?)
etc.
Points 2,3,4 I don’t remember what the heck these are. Looks stupid.
Rogue Legacy Design Note #3
More notes regarding the skill tree and additional stuff. You can see in the top right I wrote a note regarding gameplay progression.
Play -> Fun + Change -> Death -> RPG
That was the cycle we wanted early from the get-go. Segregate all of the mechanics of the game into their own separate sequences in order to fix the ugly mushiness that you get in some other games with RPG mechanics. It’s a tiny note, but it was a really important one, which is why it got jotted down.
There’s also a general write down of how the trait system would look. They look like totems…
Manor vs. Totem
We also have the creation of the character classes here. So you can see that the original concept had knights which could block damage, and the Hokages which could Phase Shift. We had another class who could do charge attacks, but that was killed off early on. The dash move, on the other hand, got re-fitted into the Rune system that was later designed.
You can also see the original control layout for the game. The B button used to be the Class-specific ability, and Y was potion (we originally wanted the player to be able to use consumable potions).
A lot of the stuff here got cleaned up in the final version of the game and simplified. As explained above, Dash became a Rune, the Y button became the Class-specific ability, and the skills were turned into single-press actions instead of direction-and-press (for some). And potions became instant consumables.
All of these original design concepts never actually got into production. We always re-examine our game while in development and often cut ideas before we waste time prototyping them. That’s a another reason why we don’t really care for design documents. They cut down on our ability to stay agile.
A lot of people say it’s important to prototype (which it is), but it’s also important to have directed prototyping. If you’re working on something that has a 10% chance of getting in the game, then it’s a waste of time. So making cuts like these are massive time and money savers.
Rogue Legacy Design Note #4
This was the design note written out for how the procedural map generator would work.
It’s v
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.
The End
That’s it. Hope you enjoyed reading all this boring stuff!