The Kindergarten of Game Design

An alternative title for this blog post would be "Simple Game Making software and how to add basic game design knowledge to a child's brain". But this one would be too long.

As some people have already seen on my other post about studying game design in my country, as of now I'm living the "academic game design life". I'm still learning about game development and its intricate fields of study. I like to compare the stages of learning, and I usually compare the basic game design knowledge most of us get as kids as the Kindergarten of Game Design. I'll share with you guys my personal experience (which is not that extraordinary) and talk about what made me love what I love today.

When I was a little kid, I loved to read magazines about games. Here in Brazil we have a magazine called Nintendo World, and as the name implies, had everything Nintendo. I think it's like what Nintendo Power was on the United States, but less fancy. My brother had a collection so I didn't need to go and buy them. Soon I became more interested in my computer at the time and less interested on consoles and portables. I started to buy my own magazines, specially one called CD Expert, which was amazing because it usually came with games - good games - for a low cost (back then it ranged from R$ 10 to R$ 20 - probably U$5 to U$10, respectively) and It was great, because video games and video game accessories were ALWAYS overpriced in Brazil. Cutting to the chase, it didn't take long for me to get my hands on my first video-game related magazine about game making. I don't quite remember what game making software I knew about and could get first, but I know three or four that I really liked back then.
The first one was called Klik & Play, made by Clickteam.

Klik&Play Interface

The Games Factory's own Event sheet!

Sorry for the low quality! This software seem to have been extinct from the internet.

The image above shows the simple-yet-really-efficient-for-a-kid event sheet. It's basically a big list of Ifs - On the left column we had the conditions. Then we could make a column for each object on the scene. And we could assign what would happen if the condition on the left column was met.
For example, the condition could be something like "If the (object) bullet" - "Collides with" - "(object) Player character". Then we could make a column for the object Player character and the score, and assign to the respective cells something like "Destroy the (Object) Player caracter" and "Subtract 10 from the score".
This, ladies and gentlemen, is the basic logic used in video game programming!
And yes, as many of you may be thinking right now: this is just like the way the engine Construct 2 works. And that's why I have a lot of sympathy for that engine - It's basically a better The Games Factory that makes HTML5 games.

Apart from basic object-oriented logic, I could learn some other things on this engine, too. For instance:
Sprite animation - It had a simple sprite editor where you could draw your own sprites or import image files and animate them. I learned about how framerate works, and some things about animation looping.

Hitboxes - And there were also those annoying hitboxes that occupied the whole square space of the sprite. It was not a good thing, but a very special thing about learning primitive tools is that usually things don't work quite well and you have to find a way for them to do so. It stimulates your creativity, helps you solve the problem by thinking outside the box.

Level Design - Where to place the obstacles? Are the platforms too apart from each other? Is the ladder too high up for the player to reach it? Remember that I was a kid back then, no guides or teachers or even youtube videos by my side to help me. I had to test things, and test them a lot, had to learn by making lots of mistakes and bad decisions. I can say that I learned about level design before I knew the term "level design" even existed.

Some time later I got that famous software a lot of people use. While some people mock it, I bow before its greatness. Yes, it is an indeed simple engine (if I can call it an engine), and yes, 90% of the games made in it are all the same, but the lessons I've learned with it are invaluable.
Yes. I'm talking about RPG Maker.

I'm not talking about any specific version - I've used RPG Maker 2000, 2003, XP, VX... The essence is the same on all of them.

By using this program as a kid i've learned the hard way one of the most valuable lesson of all:

Games must be fun. 

...or challenging, interesting... You get the idea. There's no fun in making a shortcut to the next village with no purpose at all. There's no fun in randomly finding a chest with 999999 gold inside. And definitely there's no fun in dealing 9189529889 damage to a boss with your +1 Styrofoam sword of wisdom at the beginning of the game.

As a kid, it was great to be the one who made the game, and not the one who solely played it. It was fun to change and add to the values and rules of the game. I admit that I sometimes messed around and made the player really, really strong or rich and things like that, but I usually got tired of that pretty quickly, because it made the game boring.
There was nothing challenging in killing every enemy with one hit, or buying all the items at the store without even working hard for them!

Story time:

Back when I used RPG Maker a lot, two younger cousins of mine came for a sleepover at my house, and I told them about the RPG I was making. They were amazed, because just like when I was their age, they didn't even know you could make games that easily. I let them play my RPG. It was far from being finished - I barely finished the introductory part of the game. There was some places done like the plains, a small, typical first village, a forest and as cliché as it may sound, there was a tower (the first dungeon) in the middle of said forest. I'd managed to create the first skills of the character, the first set of items and that kind of stuff.

We had three turns: First the older one of my two cousins played the game, on his own save. Then, the younger one played on his save, as well. And then on my turn I would continue development, based on their sincere feedback.
It was perfect, and actually it gave me just a small taste of how does it feel to release an alpha/beta to your public and continue developing based on their reports.

It was a simple, yet awesome GAMEMACHINE.

It was great to make the game like that. And it was funny sometimes: I had some random assets (like for example, an enemy monster in the game's library) duplicated dozens of times, and the funny thing is that whenever my cousins started fighting or did something I didn't like, I'd tell them to stop or else I'd delete some important game assets. If they didn't obey me, I'd explicitly delete the duplicated monsters. They were clueless, of course, and stopped whenever I started deleting them.

I can say for sure that throughout my childhood I've made lots of unfinished RPGs on RPG Maker. All of them lost by formatting my computer and forgeting to back up my files. I've once made a short one that was 90% finished, but It got lost, too. Of all the RPGs I've made, this one in particular taught me a lot about player progression.
It had a simple, cliché plot: The game started with the hero getting into the main villain's lair. You had to battle him and it was impossible to win. The villain would invevitably defeat you and send you to the other side of the continent, into a small village. Weak, poor and without your gear, you had to battle your way up to the villain, again.
The village you started in had everything you would ever need in the game, like shops with all the items. There was a pub and on the basement you could find some kind of training place, an arena to be more precise.
By paying the owner of the arena, you could battle some monsters to get experience points. You had plenty of options, from a cockatrice to a dragon: if you had enough money, you could battle them.

The path from the village to the villain's lair was linear, along the way you had places where you needed to defeat a certain enemy to continue your trip. So if you reached a monster you couldn't defeat, you had to go back to the arena to train more and get better gear.
The game was simply like that, linear, with a shitty plot. But it was really fun to play and playtest it. I had to fine-tune important elements like weapon strength in comparison to its previous/next tier of that kind of weapon and its price, the amount of gold enemies dropped, the difficulty to defeat each enemy... In each playtest I would try to see if things were too easy or too hard. My goal was to ensure that the player could face challenges at his skill level at all times, because I knew that if his skill was greater than the challenge that he was exposed to, he'd be bored, and if the opposite occured, he'd be anxious or frustrated.
This is simply the Flow Theory.

I was learning the Flow Theory by myself, many years before I was formaly taught it at college. I just didn't know it had a name. How cool is that?!

The last RPG  I remember I did was called "The Kingdom of Epperia" or something like that, and I made it using RPG Maker Xp.

It was a really complex RPG. The idea was to make an open world RPG with multiple possibilities... It was fancy as hell, compared to my previous projects. I even used a script I got from the internet that allowed the game to have real time combat, instead of turn based. I messed around with the script some times, and even got some basic things to work!  I'm pretty sure that if I was to mess with the script these days I'd be able to fully comprehend it. But then again, I was just a kid... I'd be proud of myself even if I managed to print a "Hello world" using any kind of code.

The Epperia RPG also had a cliché plot: Two Kingdoms, one ruled by monsters and beasts and the other ruled by humans. You could choose your kingdom and character class. The objective was simply to go to the opposing kingdom's castle and defeat the leader of that kingdom. The leader of the humans was a human king, and the leader of the monsters was a huge demon lord.

You started at your faction's castle, and you had to travel a long way to reach the opposing kindgom. If you were a human, you would find some monsters along the way while you were on your kingdom's land, and the game would get really hard when you got to the monster's land. The opposite applies: as a monster, you would find some human knights and warriors fighting on your land, but the real deal was in their kingdom.

You see, it was a really complex game for me to make. I didn't finish it of course, but I've made enough progress to keep a good experience and knowledge about it.
I've managed to make the two starting castles, and the towns surrounding them, I guess. It was really nice - On each castle there was a room full of gold that you could gain access only by killing the really strong guard it had. Of course you had to be of the opposing faction to kill him. It was kind of a bonus for getting to the enemy castle. What's nice is that I think this one is the only game I've ever managed to make a backup copy of it. It's on a CD somewhere...

Another important thing I've kind of learned using RPG Maker was level design. Oh yeah. I still remember my struggle to make a decent-designed dungeon. To be honest, I don't recall any interesting dungeon made by me at all!

I had a to-do list on every dungeon, that varied some times, but most of them had:

They were based on typical The Legend of Zelda dungeons, as it was a game I played a lot back then.
Those were the hardest to implement good level design. As a kid with no knowledge gathered from books, classes or even the internet, I was clueless on how to make the level interesting to traverse or beat.
But with that I've learned how not to design levels! The best part of not doing something right is that you learn what not to do, so you'll avoid the mistake the next time you do it. In Jake the Dog's words, "suckin’ at something is the first step to being sorta good at something".

Anyway... I could spend all day talking about my simple game projects that I did as a kid, but these are the most notable examples. 

I've messed around with other engines on my childhood, like Game Maker and Mugen. The latter being one that came with one of the magazines I talked about on the beginning of this post, and even though it had a tutorial on how to use it, until this day I wonder how one could use that. Maybe it's because I was never into fighting games. 

Nowadays there's a huge amount of software aimed towards learning a lot of game development related stuff.. Kids these days are probably learning about basic logic by building redstone mechanisms on Minecraft. And they probably don't even know they're learning!

The Conclusion

People tend to mock and bad-mouth softwares like the ones I've mentioned in this blog post, specially in places like the Game Design courses I did. But just because they are less powerful than the engines that exist today, it doesn't mean that they're useless.

But as I said, those are powerful softwares to learn basic but important concepts of Game Design, Level Design, and other areas related to game development in general. You'll take more advantage of this knowledge as a kid, with nothing to force you to make games, no teachers, no publishers, no bosses, only your sole, innocent desire to make your own game.

One day maybe the Unity engine or Construct 2 will be really primitve compared to the future game engines that will come. And if I have kids then I'll surely teach them how to use those engines, or even the engines that I've used when I was younger, and let them go through what I went through: the great thing that is to make games freely at the time of your life when your mind has excess imagination and lacks worries.