Posts Tagged ‘game design’

Fear Me! – Post-mortem (pun not intended)

Posted by (twitter: @JustSomeNikola)
Friday, August 28th, 2015 1:58 pm

In Fear Me! you play as a happy-go-lucky ghost who has recently breached the veil of the damned in pursuit of his favorite leaisure activity – scaring children. A sort of action-puzzle blend, check it out if you dig that sort of stuff.

One of the more action oriented levels.

One of the more action oriented levels.

Short disclaimer: I’ll be writing like I know everything about everything, but in fact I just have approximate knowledge of many things.

How it went:

After being rudely awoken somewhere in the early afternoon by a combination of my dogs yelping and my neighbours drill-and-hammer work, I came to the realisation that Ludum Dare was going strong for about 11 hours. After a couple of sobering slaps, cups of java and some sandwiches I was ready for some gamedev on PC action. It was time for…

Brainstorming! (1-2 hours)

I put some depressing music on – Steve von Till – and pulled out my notebook and pen. A list of wild ideas came torrenting from the weird places of my brain.
It includes a Through the eyes of a dictator – Painting Simulator where you’re a painter. But you’re also Hitler.

Pictured: Game design document.

Pictured: Game design document.


Ex-Sword-Stential Crisis — Day One Development

Posted by
Thursday, April 23rd, 2015 12:23 am

So by the time Saturday afternoon rolled around, we were all patiently waiting for Daniel to finish up his work on “Rocket Fist” so he could submit it to the contest and we could finally start putting together our game for Ludum Dare. In the meantime, I had already passed the concept art on to Rachel, who started on the base goat model. I’d already started on Rusty and was already thinking about how I was going to put together clumps of grass to be effectively cut.

rusty_swordModeling Rusty was honestly the easiest part of the whole process. 😀

Admittedly, grass is not one of my favorite things to do in 3D. I knew it was going to take me a couple of tries to get the grass exactly how I wanted it. Having grass in a game that has volume and substance to it is not only really rare to see in large quantities (as putting a lot of polygons on grass is super-hella-wasteful in terms of resources), it’s also something that’s generally reserved for large plants, because that’s how the grass generally ends up looking when done in this style.

The overall challenge for creating the grass was to:

  1. Make the clumps of grass visually appealing for the player.
  2. Make the grass look like grass, and not large-leaved plants or bushes.
  3. Have it take up as few polygons as possible. but still have volume.
  4. Create more than one “variation”, including cut versions of the grass.
grass_stuffHere are my 3 finished grasses (cut/whole), the finished bases for the grass (far left) and the scraggly rejects in the front.

It took me a few attempts. I moved up from bunching together separate strands of grass, to forming a clump of thin grass and attempting to deform it, and then moving up to creating a large-leaf plant on purpose, where I then positioned and sized down the leaves to create sensible blades of grass.  I used the soft-selection tool to shape the grass into different forms. I then removed the tops half of the grass to give it a trimmed look.

Daniel then implemented an awesome physics explosion/animation for the cut grass pieces so they’d burst and fall and splay all around when you destroyed a grass clump. It was a fantastic touch, as the sight of all the cut grass on the ground really gives a sense of accomplishment and adds some texture to the otherwise flat-colored ground once the grass stalks disappear.

At this point, Rachel had finished the base goat mesh and passed it off to me to get it ready for rigging. To prevent unwarranted deformations in a mesh when being animated, you absolutely must model your meshes to facilitate movement. You can do this by creating cuts around joints, giving more polygons to places that squash and stretch (knees, shoulders, elbows), and giving fewer polygons to the inside bend of those joints.

goatFinished goat model. You can see where the cuts were made to facilitate squash/stretch around certain joints.

Since we wanted to have two types of creatures instead of just one (to give some visual variety to the environment), a sheep model would also have to be constructed. As I planned to make a new sheep model out of the goat model, we went right to work as Daniel (begrudgingly) started rigging and animating the goat. I deleted some of the body, sized up the existing mesh to form a bulky wool coat, and Rachel reformed the horns to be twisty and twirly.

goat and sheepSheep and goat models side-by-side.

This, by far, is the most effective way to create diversity in your models — like the three R’s: Reduce, Re-use, Recycle. The more you can cut back, stylize and re-purpose already existing assets, the easier time you’re going to have completing something a bit more complex. Since Daniel had already rigged the goat (which has the exact same major joint groups in the same spots as the sheep), all he had to do was copy the weights from one model to another and — tada! Two rigged and animated animals, ready for slaught  — er, I mean, observing! :)

And the goat was promptly imported into Unity and given ragdoll physics! The. End.

In my next post, I will talk about making simple textures that look great, creating the overall level/environment and the most interesting job in game development, ever: the chaotic task of placing foliage.

Save Zoe: Post-Mortem, Pre-Mortem and inbetweens

Posted by
Wednesday, December 18th, 2013 7:11 pm

Save Zoe

DISCLAIMER: I strongly suggest you to play the game before reading this. This is going to get spoiler-heavy at some point and also I heard the game is pretty cool and you should play it?
yeeeeeah. Here it is.

DISCLAIMER II: When I go rambling about ideas and design, it’s all my mind pre-implementation and it talks about what I wanted and what I thought at the moment, not directly correlated to what actually ended up being the game. Aspiring thoughts of a young artist?

TL;DR: Here’s an earlier blog about the game.

Come forth fellow developers and players! Come closer to the light, and let me tell you the tale of when I joined this joyful crusade named Ludum Dare!

This right here is going to be a long and detailed post about many a things.

For one, you’ll read about my thought process regarding getting the idea and the whole game design.

You’ll also read about its implementation and what went right and wrong during that time.

And, at the end, you’ll get the resume of things I will we working on for now.

This all you’ll read, unless you prefer to skip certain parts, which no prideful adventure is said to do.


  1. “Where It All Begun” or “Getting The Idea”
  2. “That’s The Theory, Anyways” or “Designing The Game”
  3. “Down The Rabbit’s Hole” or “Developing The Game”
  4. “Side Effects” or “And Then What Happened?”
  5. “What Now?” or “A Blink To The Future”


1. “Where It All Began” or “Getting The Idea”

It was one hour before the theme  got  chosen.  At the time, I thought I wasn’t going to participate. A few weeks earlier, I had a team with which we were going to Jam, but for one reason or the other, they couldn’t take part this time around. Mind you, it was going to be our first time joining a Ludum Dare and  their first time attempting  to make a game.

So when the theme was revealed, I decided that If  I couldn’t think of a good  idea before midnight (the theme was revealed at 11pm my time), I’d go to sleep and forget about it.

“You Only Get One.”

Okay! Let’s see… You Only Get One Life? Hm… A roguelike of sorts? A hardcore game?

You Only Get One Bullet!  Hm… or perhaps, You Only Get One Dollar!
No, no. All those are really obvious, everybody is going to do that.
(point proven, I played at least 7 games where you only had one bullet/cannonball/arrow/rocket. Not that there’s anything bad with that, in fact, one of the best games I’ve played so far this LD was based around that concept: Titan Souls)


I quickly Google’d for a random noun generator and went ham on it.

You Only Get One Profit.

You Only Get One Bucket.

You Only Get One Partner.

You Only Get One Venezuela.

You Only Get One Potato.

Dang it!

“Alright, let’s try a different approach”, I said as I started to try to analyze what  this LD ‘s Theme really meant.
“So, when someone tells you that you will only get one of X, what does that person usually mean or imply with that?”
“Well, I guess it means that whatever they’re giving to you it’s important. Or, at the very least, that you should take care of it, because there’s not going to be any more of it.“
“So like, when your mother bought you a new toy, that’s what she usually said.”

Alright, I had a clear idea of what I wanted to do:

I wanted to give the player something they need to protect. Because once it’s gone, it’s gone: You Only Get One.

Right, but how do I do that? And more importantly, What do I do for the player to not want to lose it. I know! if you don’t protect it, game over!
No. That’s boring and meaningless.
I want the player to realize they failed to protect something. I want them to continue playing without having that X when they lose it and see how it changes the game.

2. “That’s The Theory, Anyways” or “Designing The Game”

Yes! I really like the idea! Okay, but what do I give the player to protect?
Some kind of item? Like an amulet of sorts? No, How would that affect the game, anyways?
A weapon perhaps? Yeah, that’d be cool, if you lose your weapon, now you can’t defend yourself. That’s a mechanic change that’d show you that you Only Really Had One and You Lost It.

I like it, but it’s lacking something.

And so, I looked back at the noun generator:

You Only Get One Profit.

You Only Get One Bucket.

You Only Get One  Partner.

You Only Get One Venezuela.

You Only Get One Potato.


It all clicked in my mind: You get a AI partner that you must protect. It can do something you can’t. If you lose it, it’s like losing an ability. But you don’t simply become weaker you lose “someone” and not “something”.
I believe it’s easier for a player to feel when something is gone if that something was a representation of a human rather than a object.

 Going good so far!

Although it presented a clear challenged. The AI would have to be good. Or at the very least, not suck. If it sucks, the player would feel thankful when it’s gone and it’d ruin the whole point.

I only have two days, though.

 Okay, let’s try to make it not suck.

I came back to the idea of the gun and thought: What if you can’t shoot? Your partner can, though. And when it’s gone, you only really get to avoid enemies, making the game harder.

At this point I had been discussing all of this with my friend. He had told me about making a platformer many times before, and I was always reluctant: I don’t really like platformers (Because I suck at them, but don’t tell anyone).
One thing I like, though, is procedural generation. I believe it adds replayability and since I’m really lazy and don’t believe in my ability to design proper levels yet, that’s kinda helpful.
So to this point, we were debating how the game should play. I thought programming a random level generator for a platformer would be fun and I really liked the idea.

But then I realized, programming a good AI that would be able to go through this randomly generated level was going to be hard.

“Maybe it shouldn’t be a platformer.”

That was a close one. Good thing I figured out another solution!

I don’t know what I was doing that remind me of a game I played long ago: One of the enemies was a tank that you could blow up the upper part of. Doing this removed the cannon and disallowed it to shoot. It could still run you down, though!


You control the legs and the AI does the shooting. Since it’s a platformer, and a randomly generated one, just being able to run and jump should be enough “fun” for this genre, I thought.

Okay, but how do I separate this? I can make you a human where you can lose your arms? That’d be a bit weird …and strangely funny.

What if…
You’re carrying the AI.
Yeah that makes sense: You can’t shoot because you’re using your hands to carry the AI, so it must shoot for you instead.
The movie Monsters Inc. came to mind, and I took inspiration from there to design the two characters: A big fluffy teddy-bear carrying a little girl. (Sullivan and Boo, anyone?)

Right, the shooting. Forgot about the shooting.

The only logical way to do the shooting was to give the girl a slingshot, right? Yes. Okay. Cool.

But what’s the shooting for?

Well of course there’s going to be monsters in here! I quickly drew a little dark-purple ghost with red eyes. Perfect!

…Wait, what do they do?

They shoot, of course. They shoot you things. Big, slow and cool-looking Things.
(As you can see, the thought process of the enemy design was pretty vague)

Alright, so, how do you protect the girl?
Well, you protect her from the enemy projectiles. Since she can’t move, you’re responsible for her not getting hurt. Of course she will try to protect you too by throwing rocks at the ghosts and eventually hitting one of their projectiles in the way.

And since the girl is on top of you, you can have different hitboxes.
Oh, and since you’re big dude you have more hitpoints than her. Yeah that makes sense.

Oh, oh! and since you get more hitpoints than her, that opens the chance for you to intentionally take hits in order to protect her! That is, hits that you couldn’t avoid and were going to hit her otherwise.


I can give the girl Only One hitpoint for good measure, too!

Okay, now there’s something I really value quite high in everything I make, play, read or watch and that is the ending. I’m from the belief that the ending to something is paramount and can make or break any story.

“But urs is just a gaem what story r u talken bout????”

Oh, my friend! Well, there’s something else I do love and that is something only games can do: To tell a story without explicitly telling it to you.

So I thought about an ending and come with what I deemed a really good idea (maybe it wasn’t, you tell me!)
And it was… HOLD ON A SECOND. Now this is one heavy spoiler. Okay, you’ve been warned now. Ready? Let’s continue:

The girl was in a coma the whole time and the game was actually a dreamy fantasy of hers. And if you reach the end with her, she wakes up from the coma. Consequently, If you reach it without her, she really just dies.

Holy mother of cliques!

And so, that’s why the end of the level is passing through some rays of light. You know, light at the end of the tunnel and that sort of things.
Agh, this is getting pretty corny!

Okay, we’re pretty much done with the design:

You’re a bear carrying a girl through a randomly generated platformer to wake the girl from the coma because…

Oh, dang it. I forgot: There’s no purpose! Not for the player unaware of the actual ending, at least. Why is there a bear? Why is he carrying the girl? Why are they running from those little monster than can be killed on collision anyways! Why! This make no sense!

These questions would haunt me until the last couple of hours of the second day, when I added that Intro cutscene where everything sort of makes sense. Sort of.

Oh also, before we’re done with this part, let me clear something up: I intentionally left every bit of the story as vague as I could. At first, it was because I like it when people have to find out the story themselves, I don’t want to read them the whole deal upfront. Movies and books and even comics are better at that than games, in my honest opinion.
However, a wonderful byproduct of how vague it all was done, was something I didn’t realize until people started voting and leaving me the most awesome comments ever: They were finding their own meanings to my story, they were telling their own tales with it and identifying themselves and their loved ones in my vague story and crafting their own with it.
Dayum. I can’t stress how happy that made me, and it was a complete accident!

3. “Down The Rabbit’s Hole” or “Developing The Game”

Friday night I went to sleep a couple of hours after the theme was revealed, with most of the game ideas having been thinked through, a awfully vague design document written down, the stencyl project started and the git repository setted up.

Oh, here’s a list of the tools I used and why:

  • Stencyl – I made the game with this. I’ve been tinkering around with it for a couple of weeks from beforehand and It allowed to make games really fast. I’m actually a programmer, that’s my daily job too, but I quickly realize that making something Really well, with C++ and OpenGL is nice and all for a finished product, but it just wasn’t going to cut it for a Ludum Dare. (Because I produce significantly slower with it and wasn’t going to be able to get a Web Build out)
  • GIMP – To make the art and animate. Because I can’t afford photoshop. And also, I’m on Linux for reasons that’d be too long to explain right now (And this is getting full of words pretty quickly)
  • Git – Mostly because it’s a good habit, but also because You Only Get two days, and time is extremely valuable. Git saves you time a whole bunch when you have to scrap things out, or if something terrible happens.
  • Dropbox – Used it to share the builds I was getting out to my awesome friend who lend me a hand testing them and to the genius that is the person who made the music.

Oh, right. Let’s talk about that for a moment.

I was going to go solo on this, initially. I talked about the friend who did the moral support before, but I want to properly introduce him. He’s on the Special Thanks section of the Readme file after all!

Aytuğ Ergün is a wonderful person that totally didn’t ask me to say this.
He was the second opinion for this game, I discussed everything with him and he helped me test the games. Eventually, he’d come with crazy good ideas that’d be impossible for me to add in time (Like some of the features you will see in the map generator for the polished version).

He also got me in contact with the amazing person that did the music for the game.

I personally can do many things, but music is my weakest “skill”. I usually do music by just trial and error and have no knowledge of music theory whatsoever. I knew music was going to be important for this game and I knew it was going to take most of my time.
Thankfully, a Saviour appeared. This new friend made the music for the game and he’s a goddamn genius.

Just having someone to do it for me was good enough, but he did that and more: The music is amazing! I cannot stress enough how thankful I am for his help.

Oh yeah, that was also the reason I had to submit to Jam instead of Compo. Sadly, I had to work on Monday, so I couldn’t really use those extra hours.

On Saturday I woke up, turned on the computer, got me a coffee and went right into it.
Thanks to Stencyl pre-made stuff I had a the basics for a platformer in no time.

In less than an hour I coded the map generation. Which actually has a bug: The idea was to code the distance between the platforms to consider platform height and distance in order to make all the platforms reachable, but somehow it doubled, and since I already had the double jump working, I left it in because it created more variety (And some cool leaps of faith style jumps) and all the platforms are still reachable if you time the second jump properly. I also had to do some modifications to the default Stencyl airjump behaviour that introduced a lot of bugs that’d haunt me until the last hours of the second day.

I Added a character that’d always set itself to your character’s position, and have it not collide with you, and I got the girl that way.

Added some default “Enemy Shoots at player” that stencyl provided and coded some quick movement AI, and those were the enemies.

The I stole and modified that behavior and gave it to the girl, every couple of seconds, she’d choose the closest target and shoot at it.
And I made a bunch of art and started receiving the music samples from the Anonymous Hero.

Added lifebars and a Timer that stopped when you reached the end of the level. Initially it was created to check how long the game was in terms of time, but I left it there because I thought people that like platformers might like it to test their runs? I don’t know about platformers and I suck at them but I thought that was a good idea, heh.

On Sunday, I made the lifebars good for something and made it that the bullets damage you. I also made it so anything that is not their bullets or the tiles banishes the little ghosts that I started to call shadelings. That way you can headbutt them to death and the girls’ rocks did something.

Then I made the hardest part of the game to code (which actually wasn’t that hard): The world-changing mechanics when the girl died.

And after that I started polishing everything up. Added the two endings, added an intro screen and got the idea for the comic strip at the beginning that would give a little “fake” meaning to the game at first. I also got the ambient sounds for the “dark” world from the Masterful Music Person and also that ripples sound when the transition occurs.

And then, I submitted it. It took me four hours to submit it because I didn’t know I had to do so many things! (readme, screenshots, testing, last minute bugfixing, hosting, etc)

4. “Side Effects” or “And Then What Happened?”

And then I went to sleep because I was dead tired.

And after that, I started rating other people’s games because that’s what Mr. Ludum Dare told me to do.

And a couple of hours after that I started receiving comments.

The most beautiful comments I’ve read in my life so far.

Mostly because it was people I didn’t know, acknowledging all my hard work and telling me about their experiences with it.
And holy hell it was rewarding. The entire event was worth it alone because of what some people said to me in those comments.

I’m so happy of having being a part of this. This is the cherry at the top of my kinda lame cake of a year. I finally got to finish a game! And people liked it!

Okay, okay. Enough corniness for now. It wasn’t all fun and giggles. So let’s go with what went wrong:

  • I’m really fond of little details and I couldn’t fit all the things I wanted in, due to time restraints.
    The animations are really rough, the comic strips feel rushed and the main screen is ugly as my dog. (my dog is really ugly looking by the way)
  • Mechanically, the game didn’t have the impact I wanted.
    You don’t really notice Zoe that much. Probably because a lack of sound effects and hit pauses when she does things.
  • The map generator needs a ton of work. I have a lot of ideas to make it better gameplay and visuals-wise. And also the things my good friend suggested.
  • The difficulty is linear.
    I got the chance to watch a couple of different people play my game and learned a lot from it.
    I noticed how much can the skill of a player vary.
    It took my little sister around an hour to finally be able to beat the game once. She got the full experience for it, though.
    But it shouldn’t have been that hard for people with that skill level, not right away, at least. (luckily I stole the instant respawn idea from games like Hotline Miami, which made it really addicting for her, so she kept on going and going until she finally got to the ending).
    Then I got to see other people way more skilled than my sister and probably even more skilled than me. They got to ending after maybe two tries, but the thing was, Zoe never died in their playthroughs. That’s kind of a problem, all things considered. And that is probably also because of how short the game is.
  • But its shortness is okay for it’s content, that I know: I realize my game doesn’t have enough variety to just extend the level size and not add any new enemy type or feature or mechanic alongside it.
  • Level design: Let’s be honest, there’s none. I hate having to tell the players the controls the way I did: in the main screen. It feels really wrong. I’d have liked to have an intro level, specifically designed to teach the controls and the mechanics before you jump in the random generation.
  • The controls were iffy. Or were they? I really don’t know, you tell me!
    I spent so much time playing it, that I can’t tell how difficult it is or isn’t, neither can I tell whether the controls are bad or good, I’m just too used to them. That was also the reason why the difficulty is weird.
  • Oh yeah, remember when I mentioned level design to teach mechanics? Well, there’s a kneel mechanic in the game, that is intended for you to use it to cover the girl with your body and you lose the ability to move while doing so.
    I put that in because I thought of the possibility of at some point (due to the randomness of everything) you won’t have a chance but to get the girl defeated.
    This wasn’t right, you are supposed to be able to protect her.
    I like my games hard but not impossible!
    This mechanic wasn’t clear at all, most people either forget about it or don’t understand what is it for. Or think is just a crouch move that is never used because the level doesn’t generate any small corridor you need to duck through.
    Because it’s not a duck at all, your collision remains the same, what happens is that Zoe moves down and further away from you a little, and your animation changes.
  • I also suck at marketing my game. I feel like I’m annoying people whenever I try to tell them to play it.
    So I usually avoid doing it.
    Which is a problem, because going by some people’s comment, it’s an o.k. enough game to not be a complete waste of time.
    Or is it?

Maybe you should play it and tell me *wink* *wink* *nudge* *nudge*

5. “What Now?” or “A Blink To The Future”

Now I really want to polish this up. As you can see, there are many things that were left in a precarious state. And I don’t really like that, so I will work on that.
I will try to fix all the problems I listed and add even more polish to it.
And then, I will release it on Itch.Io, most likely.
It will be free!

I might add an option to donate to me and/or to the Marvelous Musician, you know, if you’re into that kinda stuff.


That’s pretty much it, I guess.

Oh yeah, I almost forgot.

Thank You.

Thank you for reading and if you played my game Thank you for that.
I try to thank each comment individually because they really mean a lot to me.
Hope you enjoyed the reading and/or the game.

See you in a couple of months/weeks when the polished version is released!



The rest of the game design notes

Posted by (twitter: @OmiyaGames)
Sunday, May 5th, 2013 8:26 pm

[Cross-posted from Omiya Games blog]

Here’s a dump of all the design decisions I’ve made on The Sentient Cube.


First, the debug level. Always gotta have one for Unity. It’s a great place to create prefabs, and tweak the numbers to apply to the rest of the levels. Also a great place to test stuff, like the water block (top-left), unattainable block (top), bouncy block (top-right, unused in game), ice block (not shown), and rocket boosters (red, left).


How to Play was a nasty one. The first curve is there to give a clear and empty view for the player to practice the controls. It also puts the Goal out of view, making it easier for me to teach the basic objective of the game: collect smaller objects. The first bend is where I scatter the smallest objects, and provide the instructions to roll into them. I’ve put a lot of objects there to show them lighting up as you get bigger.

Proceeding forward, I have this weird bend that stretched all the way to the left. The straight-way itself is intended to let the player practice collecting bigger objects, in a true breadcrumb fashion. It’s also here that I mention the arrow at the top of the screen, that it indicates where the goal is (straight ahead). It’s worth mentioning that I call this bend “weird” because it was also intended to hide a problem: Unity’s default GUI shader draws over all other objects. By placing it to the far-left, the player wouldn’t see the text at the beginning of the level. The shader that corrects this weird overlap is openly available online, but to respect Compo rules, I didn’t copy this shader; I merely hid it.


Level 1 was actually the second level I created, code-named “pyramid.”  This level simply acts like a practice level, where the goal was clearly above you, and the objective was simple get large enough to be able to climb up the steps.  The bouncing spheres was a small challenge I’ve added to make things a little more interesting, i.e. you have to time it correctly to obtain each sphere.  Past that, it’s a pretty generic Katamari level.


In Level 2, I wanted to establish that the Goal could be anywhere.  In this level’s case, directly below you!  This was actually the first level I created, and you can tell from the knocked over objects I really just zoomed through this.  It was the first place, though, where I got a good handle on the amphitheater formation.


In Level 3, I introduce the rockets!  I initially intended the rockets to help you fly upwards, but that was nearly impossible to do with the given control scheme.  Instead, I found it useful to traverse great distances due to its added speed, and decided to do a level designed to demonstrate just that.  To acknowledge that players may simply wants to play around with the rockets, I placed slopes around the Goal to make it easier for them to reach it.


In Level 4, I introduce the water block and the ice block rather haphazardly.  This was the last level I created, and I simply had very little time left, so I dumped every new assets I had into it.  The walls surrounding the ice is there to prevent both you and the objects you’re trying to stick from falling out, making it easier to collect things.  The objects are placed almost randomly, partly because of the chaotic nature of the ice-block.  The water blocks were intended for helping you adjust your controls, but in the end, they ended up being pretty useless.


And the Credits. This was actually hard to design, mainly due to tweaking the size of the breadcrumbs so you can definitely grab each text. Other than that, it’s intentionally a breadcrumb-to-breadcrumb level with no other purpose than, well, providing the credits.

Interested? Try The Sentient Cube here, and please rate the game!

[Cross-posted from Omiya Games blog]

Designing the levels for The Sentient Cube was a fascinating exercise, and one that provided a great insight in how Katamari Damacy was designed.  Both games have very lenient win conditions, and as such, have equally lenient level design that can be both creative and flexible.  Broadly speaking, there are two types of object placements used in The Sentient Cube: the breadcrumb and amphitheater formation.


Breadcrumb Formation

The breadcrumb formation is the easier one to understand, yet harder to setup.  In short, it’s a placement of increasingly larger objects placed into a trail for the player to follow.  It’s purpose is simple: to lead the player towards a specific point of interest.  This is most obvious in The Sentient Cube under the “How to Play”, “Level 3”, and “Credits” levels where they’re designed to introduce the player a new concept.  In “How To Play”, the breadcrumbs literally lead the player to the goal.  In “Level 3,” it leads the player to the rockets, which they can use to traverse through the large expanse very quickly.  Furthermore, the rest is intended to lead the player to the goal, much like “How To Play.”  Lastly, the “Credits” leads the player to each text in the game, making it more likely that they’ll spend the time to read it.

One interesting tidbits I learned from using the breadcrumb formation was that making a simple, straight trail was actually the worst way to implement this idea.  With the exception of the “How to Play” where the player needs to be guided to the goal, a straight trail feels too easy and boring.  Instead, it’s better to have the trail curve, and even place obstacles around those curves to emphasize it.  This is most evident in “Level 2” where I zig-zag the breadcrumbs; “Level 3” where it creates a small ‘C’ to lead you to the rockets; and “Level 4” where obstacles obstructs your view from seeing the next breadcrumb.


Amphitheater Formation

The amphitheater formation is a little less easier to understand, yet easier to implement.  In this formation, objects are placed in concentric circles with each layer consisting of similar sized objects.  As the layer gets farther away from the center, the objects gets bigger.  The formation is like that of the breadcrumbs, but in all direction.  Unlike the breadcrumb formation, amphitheater is flexible enough to allow quite a difference in size for each circle, which gives the level designer some flexibility.  This is seen in “Level 1”, “Level 2”, and “Level 4” where the objective is simply to grow big enough to roll over walls.

Similar to breadcrumb formation, variation in sizes within each layer is a lot more interesting to the player than the same size.  Additionally, each layer should increase in size exponentially rather than linearly.  Other than that, you can be pretty creative with it, making it square-shaped, putting objects at different elevations, putting gaps between cross sections, or even making them bounce.


Honestly, this game genre is surprisingly simple when it comes to level design.  With its loose restrictions, it’s easy to get creative on what kind of setting you’d like to create, let it be in Japan, USA, underwater, in space, etc.  Hopefully this will help and encourage others in exploring this great idea.

Interested? Try The Sentient Cube here, and please rate the game!

Some free ideas. What about Ludumception?

Posted by (twitter: @SplitPainter)
Saturday, August 25th, 2012 2:11 pm

I probably won’t do anything, so I’m giving free ideas away:

  • Ludumception: a game that mixes gameplay with the evolution of themes of past Ludum Dares
    Example: #1 the theme was “Guardian”, #2 “Construction” and #4 Infection. You have to kill the Guardian that is guarding a construction, and avoid the infection. And go on with all other themes. Could be a platformer mixing the themes.
  • FPS that goes from retro <-> modern look: some scenario is similar to DOOM, other with bump mapping, lightning, etc. Straightforward to do with Unity.
  • Graphical evolution Cube eater: a Pacman like where you have to eat an element that has the same graphical specs than your level (1-bit, 8-bit, vector, etc).
  • Expanding Blob: jumping forever, eats and gets bigger. You have to puke if you are too big in order to go through thin paths.

Space Drugs: Isn’t Deep Space “High” Enough Already?

Posted by (twitter: @louroboros)
Wednesday, May 2nd, 2012 8:05 pm

(This is a cross-post from my post-compo devlog.)

“High”, as in altitude. Again, no apologies.

If you’re old enough to have been a highschooler before the average cell phone had an app store, then this probably looks familiar:


That of course is a depiction of the ubiquitous TI-82/3+ game “Drug Wars”.

It was a simple and extremely … er … addictive game. Buy low, sell high, don’t get caught, and don’t get robbed on the way to the suburbs to drop your stash of cocaine.

Now, as it turns out, this was inspired by a DOS game from the early 80s. Of course, there have been many variations, but I’m willing to bet that the one for the TI-83 has been played by more highschoolers of my generation than any of the “modernized” versions (/me wrinkles his nose at ‘mafia wars’).

Frontier: Elite II, a game from 1993, introduced black market goods to the space-trading from the first game. Whether it was influenced by DOS Drugwars is a mystery to me, but I know it was at least as fun to be a dealer in space as it was to be when I should have been memorizing trig equations (okay, it was definitely more fun — lasers).

So, of course, I had to include black market goods in μniverse.

There is only one illegal good so far in the pre-alpha: generic narcotics. I may add other goods that have special properties, such as firearms, nuclear waste, non-compliant computer hardware, unidentified alien technology… it’s easy to come up with ideas. But for now, just droogs.

Currently, the only penalty for transporting illegal goods — as seen above — is for the goods to be “confiscated” by the ITG (Intergalactic Trade Guard).

I should note that so far, there are two kinds of space stations you can encounter: ITG stations (below, left) and what I’m calling “Pirate” stations (below, right), which are not “protected” by the ITG.

ITG StationPirate Station

(non-final artwork)

Every time you enter an ITG station, there’s a chance your ship will be searched. Pirate stations, however, are “safe”. Thus, it should go without saying that prices for illegal goods at ITG stations are significantly higher than they generally are at Pirate stations.

To make things more interesting, I intend to introduce a “Smuggler” crewmember, whose presence aboard your ship will reduce the likelyhood or rate of discovery of illegal goods and later, fugitive passengers — a topic I’ll be discussing in a future post.

HUD you guess?

Posted by (twitter: @louroboros)
Monday, April 30th, 2012 7:59 pm

(This is a cross-post from my post-compo devlog.)

Yes, there will be puns. I apologize for nothing.

The most recent addition to the game was the heads-up-display for your ship in flight mode. It’s a subtle addition but it’s the sort of thing that makes it feel like, yanno, a game. I’m happy to say that it doesn’t act as a big distraction or take away from any “immersiveness” that the game might (accidentally) already have.

Right now, the only info the player needs to see are their shield levels. The way I chose to display this was an unassuming, white vertical bar. When you take damage, the bar shrinks accordingly. The important bit is that it does so in an animated fashion — any time the bar is shrinking, the ‘S’ (label for ‘shields’) shakes proportional to the amount the bar is moving.

Once your shields are below a critical threshold, the bar turns red, and the ‘S’ continues to shake along with the bar until your shields are repaired. I usually hate UI-nags but I make an exception for imminent death.

What isn’t pictured is that the camera also shakes whenever you take damage. The reason for this is two-fold: 1) This helps indicate that you took damage, but it also 2) can disorient you, much like it would happen if you were at the controls and a burst of plasma breaches your hull.

Along the same line, I’m considering having your craft be propelled by the shots as well, but I’m afraid that might be too jarring for the average player. Maybe in a sort of “expert mode”. 😉

There’s more to EscApe than you think

Posted by (twitter: @JohanRasten)
Monday, August 29th, 2011 2:16 am

This is kind of a port-mortem of EscApe (there’s another game with same name, it’s not about that one :)) but I’m going to focus certain design choices I did in the 3 hours I created it.

Massive spoilers below, so if you intend to play my EscApe, go do it now!

“Your game is just a crummy monkey in a badly drawn cage”, you say? Perhaps, but there’s still more to it than meets they eye. Continue reading!

I’ve found two other games that are exactly the same as EscApe, except that they look and play quite differently. There’s The Power of Escape by BurnZeZ and BATHOS by johanp. I’ll use them to point out some differences in game design, which might sound like I’m trying to bash the other games, but that’s not my intention. Read it as constructive criticism.

The basic concept [of all 3] is of course to present the player with a room, which is impossible to escape using methods normally available in computer games. Not until the player starts thinking outside the box (or tries to quit the game, as we’ll see later), and takes what’s printed on her keyboard literally, she will escape the challenge. If executed correctly, this puzzle actually takes place in your room, rather on the computer screen.

Now, what did I try to do with this? My goal was to give as many hints as possible, without actually revealing the solution. I wanted the player after figuring it out to think “omg, why didn’t I think of that from the beginning?”.

Starting at the title, there’s a big green hint all over the screen. But I tried to draw your focus away from it, by making the game about an ape. You see, the title only says “escape” with “ape” highlighted.. or does it? :) To put even more emphasis on this I added the text “Can you help the ape escape?”. There’s actually one more thing, which I didn’t think of until later, that APE is written in a slightly stronger color than ESC, but I think the difference could have been even bigger.

Still at the title menu, at the bottom it just says ENTER (the compo version had more text, but I thought it was distracting so I changed it). This is also a hint, actually. You see, I don’t give any exact instructions on how to play the game – I will return to why shortly – you have to figure it out yourself. As I mentioned the solution is to read the Esc-key literally, and for this to work, all keys have to work in the same way. You enter the game by pressing the enter key. Simple enough.

Lack of instructions, yes? The reason is of course, that only thing worse than giving no instructions at all, would be to give partial or faulty instructions (without telling the player that they are faulty). So either you tell players what all keys do, which would spoil the puzzle, or you say nothing at all.

(BATHOS – not made by me)

As you can see BATHOS looks nothing like my game, it has much better graphics (and sound) and I thought it was incredibly funny as well. But the other Johan seems to have done the opposite in just about every choice I’ve described so far. In fact, it even seems like he knowingly tries to lead players in the wrong direction  :) By giving instructions, there’s nothing in the game – or deducted from experience of playing 100s of other computer games earlier – saying that there’s another unmentioned key that is crucial to winning. Further, if Z means “jump” and X means “pickup”, then Q might as well mean “escape”? IMHO it’s a little like playing Super Mario Bros and having to figure out that you have to press the reset button on your console to press to find the princess. Though BATHOS has a lot more comments and ratings than EscApe, so maybe this is what people wants :)

Back to our poor, caged simian. My idea here was to print out the key you pressed in clear text, so you would get the connection between its literal meaning and what goes on on screen. Initially I was going to make it more passive, so that pressing left would only make the monkey look left for example, but I ran out of time sooner than expected. People ought to figure out soon enough that moving around in the cage won’t help you, so I’m not sure it made any difference. Hopefully after coming to that conclusion, all the previously mentioned hints have trained the player enough to start pressing other keys to see if anything happens.

Due to this lack of time, there is a crucial part of the game missing; There should be more keys with functions in the game to lead the player from using the direction keys to thinking “aha! I need to press Esc to escape”. Not only would this help bridge the logical gap, but also add a little bit more fun to the game. These were some I thought of:

  • Space – Launches the cage into space or something. Maybe the monkey just thinks about space. However, it is a very important key, as it’s likely one of the first ones the player tries pressing (partially because of its size and location and partially because of its use in other games).
  • Shift – The ape shifts its weight around.
  • Home – Text: “You can’t go home”
  • Enter – Text: “You’re already inside”
  • Dash (well, it’s technically a minus sign, but they look similar enough) – Quick sprint in either direction.
  • End – Popup saying “Are you sure you want to end the game?” with possible quit.
  • Backspace – Printed as “Back (from) space” and returns to the jungle. Maybe too far fetched.

So why am I ranting about all this? Because gradually training the player to adapt to your game’s rules and mechanics is how you write modern games. No game designer ships their game with a printed manual these days, and if they do, nobody is going to read it :) Another central concept of modern game design is to make player feel like they’re doing exactly what they want to, while they’re doing exactly what you want them to. This makes the player feel incredibly awesome and is a lot more rewarding that simply following a heavily scripted story. Ok, so EscApe isn’t Half-Life 2 (Valve are good at this), but maybe it’s a little bit more to it than you initially thought? 😉

I wonder what would happen if the next LD theme was “space”…

Strategy Guide and Tech Talk

Posted by (twitter: @RustyBotGames)
Monday, August 22nd, 2011 12:55 pm

The compo is over, my game is finished and the rating starts. For anyone trying out my game (if you haven’t yet: HERE), I will explain some strategies to survive, just in case you have trouble with it. Additionally, as I tried to get some advice from my wife for setting up the level generator yesterday evening she wasn’t really enthusiastic, to say the least. So for anyone more interested in the tech behind I will explain, why the level generator currently doesn’t work that good for providing difficulty.

The game mechanic basically works with to values that decrease as long as you are digging tunnels (and even when passing existing ones). The first value is food/hunger. You can find three different kind of food which will give you 5 to 15 points back. Food, if there is any, is only revealed if you enter a cage. By that, it is often necessary to leave the direct path and search adjacent rooms if you are low on food. This strategy also has a second benefit related to the second value, hope.

Hope is generated by spotting new cages around you. So progressing the level is the key to prevent death by starvation.  The hope mechanics leads to another point. Often it is better to move to the center of the level because chances for revealing cages is better in free field than at the level borders. This seems contradictory to the aim of getting to the upmost row or the rightmost column which are the only places to escape the level later on. Remeber that you can see 2 spaces horizontally and vertically and one space diagonally (not if you are digging). So if you already are two rows below the top border and there is no cage above, you won’t find any if you dig that direction.

The cacti walls are revealed by digging, so sometimes a tunnel can give further information for planning your path. This only applies if you have enough food/hope left.

To summarize the strategies:

  • try to reach upmost row or rightmost column of the cages but pass the center of the level
  • don’t dig to places where there can be no cage (2 spaces between player and border)
  • don’t hesitate to search rooms for food
  • progress to keep your hope filled

Headed to the center and didn't took the direct path to replenish food and hope. Else I would have died short before exit (Difficulty: Hard).

With that you should be able to beat all difficulties after some tryouts. At this point the random generator sets in. The design I used is rather insecure in providing the difficulty level. Instead of spreading a fixed amount of cages for each difficulty, I implemented to check a percentage to set a cage for every field of the grid (e.g. 33:67 that there is a cage on a field in normal mode). Instead of filling one third of the level with cages, this leads to very unsteady number of cages. By that, an “insane” level could have more cages than an “easy” one. Same applies to walls. By that the difficulty selector is a rather vague adjuster. But nevertheless you will notice the difference if you give it some tries (one playthrough is quick; around 15 seconds). So go and play. Good luck.


Just a game design related teaser for the post mortem coming soon.

Begin the compo

Posted by
Saturday, August 29th, 2009 1:52 am

First of, this theme is awesome and I hope for justas awesome entries. 😀

Game Design

For my entry, I’m going for a (RT)Strategy game. Here is some concept art:game_concept

In the game you will control a subterranian civilization, which evolved eyes, that can only see a single color on the spectrum. You will have the basic RTS objects: towers to expand your teritory ( emmit the light you can see), units, which will emmit a dim light, when out of the towers range, building that will function only inside the range of the towers, some for traning troops, some for housing, some for gaining monochrome energy. Every object you see distincly in your color.

You will battle other civilization such as yourself, who are able to detect a different color. All of your enemies will appear black or very dim and will not be distingushable from one another. So if you are a yellow civilization, and have green and red opponents, you can tell them appart.

The basic goal will be to destoy your enemies/neighbours by destroing their main tower. I was also thinking of doing something with the entrance of the cavern, maybe a goal or bonus for the team that has control of it. One  idea was to have the you gain the color of the opponent you conquer, till you eventually see all the colors and can go outside in the light world.

The game seem to be carying some racial message with it or at least it has potential for it.

Technical stuff

platform: Linux for development, Windows build after the compo, this time maybe even OSX

programming language: c++

libraries: SDL for graphics, input and sound. Do i need anything else? O_o

drawing: GIMP

recording sounds: Audacity

sound and music: Hohner BBassV with Digitech BP50 multi affect and 60watt Vision AMP . I hope my music skills don’t let me down.

TODO list for first day:

So how much can I actually get done in the first day? I think this should be a realistic goal:

* resource manager: sound, graphics,…

* tile engine for the map

* create the cave

* implement ligh sources

*create the towers

* mouse input and HUD

*some background music

I think that would be about half. I hope I am not underestimating any part I left for day two (AI or troop control maybe?). If my goal are realistic, I think I can actually make a good game this time round. 😀

Well good luck to you all.

[cache: storing page]