[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.

Conclusion

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!

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: http://www.ludumdare.com/compo/ludumdare/.
  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.

(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.

(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.

(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”.

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”…

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.

TL;DR:

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

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:

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.