Posts Tagged ‘level’

Rough interface in the working, levels galore.

Posted by (twitter: @tselmek)
Sunday, August 28th, 2016 11:37 am

Got a rough base for a menu and a level selection screen as well as sketches of what the first tutorial levels could look like. Will leave them as is for now and improve them tomorrow, let’s make more levels now.

View post on

First hours and it starts to shape :V

Posted by
Saturday, April 16th, 2016 8:50 am

5 hours later, I’m starting to see some light. I’ve started late, mainly because the time zone (I’m from Spain). This is the second time I develop for the Ludum Dare, and the first time I do it solo (time will tell if I can arrive for the compo deadline or if I will give me some time and external resources for the jam).

Shapeshift was one of the themes I did not like from the beggining, too many work to do some early ideas I had when I saw the theme. Then, I’ve spent the first hour and a half brainstorming like hell to find ideas that will be easy enough for a programmer to implement, and more important, to draw… because programmer art, you know.

Finally I’ve decided to make something inspired by Hexagon and it’s dodge mechanic but technically simpler.

The initial idea for the game is simple. You are in a laberinth like level and you can move around. In the background you can see another level, and when a short countdown beats, the background map will switch to the front. If you are in a clear tile, you can continue, if not, you’re dead. The more time you stand, the faster levels will switch. Will you be able to move fast enough to adapt?

Next you can see a first sketch of how it will look like, black walls, transparent floor and in the background the next level. You are the red circle and the line shows a “correct movement”.


I had some technical difficulties because I use a custom engine from a friend of mine and teammate on the last LD and I’m not used to it, but now I have a level loaded and I can move around. Next stop, level switch mechanic.

Progress Update

Saturday, April 26th, 2014 9:10 pm


In my game are currently: Dirt, Grass, Stone, Iron, Ruby, Diamond, Emerald, Sapphire, Gold, Ladders, Levelgenerator, a cool mountain background, a simple inventory and and and…


Saturday, April 26th, 2014 12:33 pm


Currently included: Stone, Iron, Dirt, Gold, Ruby, Emerald, Sapphire and Diamonds.


Saturday, April 26th, 2014 10:28 am


We found gold! Now we have 3 floors.


Saturday, April 26th, 2014 6:06 am


Now included: Dirt, Grass, Stone and Iron.. :)

The game takes shape slowly.

Basic Level system

Saturday, April 26th, 2014 4:06 am


748 Lines of code ­čśÇ

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!

Level editor progress

Posted by (twitter: @7573656c657373)
Saturday, April 27th, 2013 3:13 pm

It’s still clunky. oh well.
At least it works!

I’m using it to create the levels in the game right now.

Petri – the aftermath

Posted by
Monday, April 30th, 2012 11:21 am


 The Aftermath

Not quite sure if I should call it a ‘post-mortem‘. There are hundreds of these already there.┬áIt’s not about what I think went right or wrong. It just … did. Generally I’m glad the way it turned out. However, since I want to keep working on this game I’ve decided to make a list of changes I want to apply to it. That’s why I called the post ‘The Aftermath‘.

The main purpose is to expand it and make the framework more flexible. Then I will extract it and use in future compos.

So, here it goes:

Level entities’ management. Every object in a level is derived from a CEntity class. The examples are mainly … blobs. The pointers to the entities’ instances are stored in a globally-accessible array, which can be accessed at any time. When an entity is no longer needed – it gets deleted and the array is rearranged, getting rid of an unnecessary pointer ( it’s a C++ vector container ).

What if we want to store the reference to the entity and use it on later occasion? For instance, a blob chasing another blob could save a reference to its target and update its position every tick based on that. Storing a raw pointer to the data in memory is risky – we are not able to check whether the entity has been already deleted and the memory’s been freed. Trying to use such a pointer would result in very pesky and hard to track down bugs.

That’s why I came out with the idea of … IDs. An entity’s ID is an index at which it can be accessed in the main entity array ( the STL vector mentioned earlier ). When an entity is about to get deleted, the memory is freed, but the pointer in the array is set to NULL. That way it never gets overwritten and we can check if the object is available, or not.┬áAn ID would be an unsigned integer, so it could range from 0┬áto over 4 000 000 000! The free IDs will never get depleted and the entities themselves will be getting deleted from memory at a constant rate.

The array itself could be though great in size after a while. Every frame each entity needs to receive a tick. Iterating the entire array will be getting more and more time-consuming with the number of the array members growing in size. So … what about a second array? It would contain the IDs of non-deleted entities – that way only the valid members will receive a tick every frame without iterating through the NULL-ed entries.

Although it looks complicated compared to the previous system, it seems that it’s worth a try.┬áDid anybody run into similar, or other worthy conclusions on that matter?

The level editor.┬áBecause of a lack of time, I had a really tough time designing the levels. A level editor and an external level file format could really get in handy in this case. Running a game, writing down coordinates and typing them in manually in a source code doesn’t sound appealing, especially when you’ve got dozens of objects which need to be somehow adjusted. I have really no idea how I’ve managed to put all of these blobs in place manually in 48 hours.

The scenes.┬áThe hardest thing to think through than the levels themselves. I’m talking here about an intro and ending scenes. Naturally, when you have an idea, you write it down as following: “It fades in within the first 2 seconds. Then it plays the sound X, waits another 2 seconds, shows a few lines of text slowly and gradually fading in …” etc. Not a tough job. It gets complicated, when you only have a level tick method called every frame to put these things in.

Let’s say you want an entity to play an animation after 2 seconds after the beginning of a scene. In the level you’d have to write an if statement which will be called each frame. It’d have to check, whether the time from the beginning of the scene was greater than 2 seconds and┬áif it hadn’t been already greater that 2 seconds the frame before ( starting playing a sound every frame wouldn’t sound pretty – it must be called once and left alone for it to play along ). If there’s many of such ‘timed events’, we need a lot of variables. And now, if not the static variables available in C++, I’d find myself in the dead end. Although the scenes work pretty well, the code itself is a┬ámassacre and I was really confused which if statement was responsible for what event.

The threading system could be excellent here. Unfortunately I did attempt this concept few months ago and failed tremendously. Maybe because I used very unfriendly Windows API, who knows? But what other alternatives do I have?

And that’s when I thought of … Lua. I never had the opportunity to work with Lua and so I don’t know its specifications. Hopefully it allows for such maneuvers. I’ll have to dig into it. Is it possible to use threading in Lua?

That’d be it I suppose. There’s a lot of other points in my list but these are regarding either entities’ classes in particular or their implementations. Anyways, after polishing out the game itself, I will add more enemies and more levels, scenes. Hopefully it will come with a great ease. Greater than previously, that’s for sure. Eventually I will publish it.

If you have any suggestions, I’d appreciate if you shared them! I don’t want to implement a total bummer and base the upcoming code on that ­čśë

Cheers! Thomas

#ld22 – alone with myself – screenshot 1

Posted by
Saturday, December 17th, 2011 4:00 am

level editor is working ­čśŤ

map[0] = ' 111 ';
map[1] = ' 111 ';
map[2] = ' 111 ';
map[3] = ' ';
map[4] = ' 1111 ';
map[5] = ' 111 ';
map[6] = ' ';
map[7] = ' 111 ';
map[8] = ' 111';
map[9] = ' 111 ';
map[10] = ' 111';
map[11] = ' ';
map[12] = ' 111 ';
map[13] = ' c 111 ';
map[14] = '11111111111';

Looking better now, half-way through level design

Posted by (twitter: @blayzeing)
Monday, August 22nd, 2011 7:34 am

Although… I have realised that I’m probably putting too much detail into this

A couple of levels for your enjoyment

Posted by of Polygon Toys (twitter: @pekuja)
Sunday, October 5th, 2008 10:38 am

General laziness prevented me from making an actual game, but here are a couple of levels I made, inspired by some games I’ve been playing lately. See if you can guess which ones:

Ludum Man\'s stageConstruction Yard

my 48 hours is gone

Posted by (twitter: @S0phieH)
Sunday, September 7th, 2008 5:48 am

gotta be honest here, I started two days ago so I’ll submit what I have so far.

I’ll finish it off some other time and upload it here <3

so far so good…

Posted by (twitter: @S0phieH)
Saturday, September 6th, 2008 12:30 pm

really not used to making editors for stuff, but I think I’m blundering through pretty well:

(heres a link to a web version so you can play with what I have so far)

use the arrow keys to move the cursor, and click the tile types to alter the current tile.

didnt quite think the tile thing through, so I’ll have to have a way of having more than one plane per tile. after that I’ll be getting on to textures :)

Here goes…

Posted by (twitter: @S0phieH)
Saturday, September 6th, 2008 3:35 am

so I’m going to be making a tile-based level editor… a 3D one… kind of. I guess really its 2.5D but whatever, heres a mockup of the interface:

fugly mockup

to tell the truth I’m still working on the bits of it that build the level, but I guess that grows up with the editor, so hopefully it will all fall into place and if not, I’ll learn something :)


so its started coming together:

yay, 3d flash tiles

[cache: storing page]