Gaming Your Way

May contain nuts.

Gears are polygon bitches.

After last weeks post I started working on the real version of the "cave" showcased in the last week. Basically it is the "puzzle" part of the first block for the game. The idea is to compose a set of independent blocks that are connected by doors, portals or "glitches" (I'll give an explanation for that in a later post).

Let's talk about controls first (be patient, I'll come to the gears soon enough).

My main method of control for this game will be twin-stick gamepad (with a WASD/mouse fall back - maybe). I played with a few types and settled whit what I call "locked view" 3rd person controls. My first idea was to go the classic twin stick route and have one stick for movement and one to set the aim direction. I admit I don't like that very much, so I started looking for another method. The method I use now uses one stick for moving AND aiming (read you aim into the direction you move) and the second stick is used for moving the camera (classic 3rd person I would say). I added one addition to it, though.
In fights you can "lock" the view aim direction with a button press (and release it with a second press) this way you can move towards a group of enemies (thus aiming at them), lock the aim and retreat backwards still aiming at the enemies. When moving the camera you keep aiming relative to the camera, so you'll be able to shoot enemies nearby without having to heavily move around.

Puh. That's a lot of text, let's get to the gears.

This machine is a part of the first puzzle.

You'll notice the gears in this image, and the eat up polygons. Although I cheated and removed all invisible faces of the gears in the background, they still make up a good part of the polygon count for this block (10k so far, but there's room for optimisation), but then I liked the mechanic look of them. Seeing them in motion when solving the puzzle was reward enough to keep them the way they are now. The game isn't purely about killing enemies, so I wanted to add puzzles to the blocks that unlock new locations (rooms, blocks, mazes). This isn't a great puzzle, but it's a start and as the game grows and I'll add more blocks with more puzzles adding a hint of adventure to the game.

This bridge leads to a different part of the block.

I doubt this area will stay like it is right now, as I had the idea of adding a BIG spiral staircase down to a big room with lots of ... things.

The "cave", not quite looking like the one I showed last post.

This area is still not finished, I'm going to add at least one bigger wooden structure to the right "island" (which you can't reach without solving the puzzle) and a portal.

Oh someone told me that the images are a tad small, so I'll have a g+ post with bigger versions ready if you follow this link: bigger version images.

And with this ... see you all next week. 

Grid killed vision ...

I think I mentioned last week that I'm going to spend a few days doing a dummy level for The Hellstrom Project. I started by doing a few basic tiles I wanted to use, which didn't look that bad (in a cheap kind of way):

The finished set of dummy pieces.

Basically some floor tiles, walls, a simple door and 2 traps (the red things). This took about an hour to do and afterwards I imported them into unity, eager to start "messing around with a nice level" - well in theory anyway.

The first thing is that unity isn't very good at this kind of level building (or it's just me) but the lack of usable grids and quick edit possibilities (you can do it with some 3rd party extensions) quickly showed the limits for this kind of editing.

So I fired up my 3D Software and thought: "Well just use the tiles and export the whole level in one go then" - well in theory anyway.

I ended up with something that looked ok'ish, but at the same time showed the destinctive grid structure you get when you start using (and limiting yourself to) a limited set of items. You might argue that this works with LEGO, but the keyword is "limited" here.

I smell grids.

It does make for a distinctive art style, but not quite what I wanted. In the end I started from scratch and ended here:

Not even remotely the current state or finished (and not optimized at all).

Which I find a lot more appealing, even without textures.

And with this, I think I close this week's post and see you all next week.

Enter title here

Another week passed already? Damn.

I'm not sure if I mentioned it, but I'm having two weeks off. No coding except what I want to, I even could have a complete lazy day. During the last week I've been digging out an old game that went to oblivion - because paid work took over all the free time and there was a distinctive lack of "vision".

Both problems have been solved for the time being. MTR, the racing game is partly client work so I decided to let it rest for two weeks.

Is back from the dead.

On Monday my first action was to zip away all the old files (except the 3d models already made) and start a new project. I did this because one of the main features of the game is gone: randomly created dungeons (not entirely, but not as sole method of creating the environment).

A rather ... unspectacular first screenshot.

As the game will be gamepad controlled (but I'm also working on a wasd/mouse version) I spent some time making the controls feel right. Next things to work on are traps, doors (keys), terminals and connectors (which will be used to connect pre-built blocks) - all as dummy objects to see if it works like planed.

There are still some decisions to make, mainly player progression and inventory, but I need something to post next week.

Colliders are mean shits in Unity, let me tell you.

Lots of problems have been revealed since I started to roll my own set of car physics *without* car physics. At first it all seems so easy and logical, get rid of wheels, torque, motor and what not else to get a better control over the car's handling and setup.


(first setup, notice the shitload of settings ...)


I wanted to be able to take the car and set a top-speed from 1 to 10, as well as acceleration, a value I called "handling" and maybe "boost" or something like that.
Normal wheel based setups are a bugger to tune and I've spent a fair time trying to get the values right but still it felt ... wrong.
Anyway, the idea was simple enough: make a rigidbody box (so I can have "easy" collisions) and move it along the track, but you cannot simply move rigidbodies (or it isn't a particulary good idea as physics calculations depend on force). 


(simple box collider setup)


OK, just apply force to the box in the direction I want the car to move, which works (in a way) but then failed after I altered the track's physics material to behave more like a road.
Now the friction killed any movement and the easy solution was to just let the box float (representing the car's body only) and that seemed to work well until I recalled that I have sloped tiles. "Oh no problem", I thought and was wrong again.

[we fast forward here a good deal and stop at a point where I have a semi floating box that is always aligned to the ground, does slopes, accelerates, breaks and what not else]


(new setup, less settings, looks odd, but the
capsule colliders have their purpose...)


Looking at the image you might ask where the difference is, the most obvious are the 4 capsule colliders at the car's corners and you might have noticed that the wheel colliders are back.
There is a simple reason for this setup: it works. Using wheel colliders with no friction is heavy cheating, but it keeps the car's body afloat and always aligned to the ground (esp. on slopes). Reading out their contact points also allows the put the tires on the ground and using the suspension.
The rest of the setup consists of a box collider for the car's body and four capsule colliders (not really needed, but they simplify the handling of some of the collisions).


On to colliders ...

Reading out collisions is easy and Unity offers three events to track these:
- OnCollisionEnter
- OnCollisionStay
- OnCollisionExit

"Oh cool, just listen to OnCollisionEnter and detect when the car crashes into something."

In theory, yes.

In reality it isn't reliably reporting when you collide, and OnCollisionStay is reporting all the time as the wheels nearly always touch the ground (as they are part of the rigidbody setup).

But this is the story for the next post ... 



And with this I killed a perfectly working game.

This post seems to be somewhat out of context, I fear - but if you follow my posts on google+ you know that I've been working on a racing game.

The problem is that this blog needs writing and updates, but it always seems to be an overkill to post the minor updates (mostly just a few lines)... sometimes these become longer post that would well fit in here - this is one of them and to make it more appealing using an rss reader I start with an image...


Where am I?

My last post on MTR dealt with the fact that I tinkered with the tiles, mainly allowing tiles that are larger than 1x1, which resulted in a shitload of new possibilities and problems.

Map formats: [,]

As always there's more than one way to fuck things up and I think it starts with the way you handle our map data. Lets start with the basic things a single tile needs to know: the tile to use and in this case the way it is facing (3d and all that).

The most obvious choice would be the 2d array [x,y], it is easy, clean and simple. Placing a tile is a nobrainer.

So we can use aMap[x,y] = Tile;

Any basic tilebased tutorial teaches you that. We need to store a direction in there to and as we're lazy right now the 2d array becomes a 3d array, using the 3rd dimension to store tile and direction.

aMap[x,y, 0] = Tile;
aMap[x,y, 1] = Dir.

Still easy enough. I'll skip the part where you use an object to store the data of a tile.

Now we're adding 2x2 tiles to this map and voila: instant fuckup.
You could just store the pivot of the tile and leave the other map slots empty (not good if you need to test if the place you want to store a new tile in is already used or not).
Or you could store a reference to the pivot - either as id (but then you have too look up where the pivot is) or as coords pointing at the pivot (but then you need to find a way to store the coords).

Map format [] and [,]

Another way to store the map is to just store the tiles as sequence and use a simple int[,] as index. The size of the tile doesn't matter that much this way (but it offers it's own range of trouble, again, I'll skip that part unless someone wants to know).

We'll use a simple struct for storing the data (tile, direction and some meta stuff):
aTiles[index] = new Tile(Tile, Dir [, coords]);

and store the index in the 2d map array:
aMap[x, y] = index;

Getting back the tile needs some more code, but it's still readable:
Tile = aTiles[aMap[x, y]];

The neat thing is, for a 2x2 tile I can now add a single tile to the aTiles array and do whatever pleases me to keep the map in sync. I settled with -(id + 1000), as -1 marks an empty space on the map. So a larger tile will be stored like this:

aTiles[10] = new Tile(1, 0, 10, 5); // meta shows a 2x2 tile ..., also storing coords in here
aMap[10, 5] = 10; // pivot
aMap[11, 5] = -1010; // this place is used, but it's not the pivot
aMap[10, 6] = -1010; // this place is used, but it's not the pivot
aMap[11, 6] = -1010; // this place is used, but it's not the pivot 

This way storing the map is also a bit easier as we just have to spit out aTiles as "[Tile, x, y]" (instead of dumping the whole map).

Of course ...

... the drawback of changing the map format is that the whole game stops working unless you have all the methods back in place and working again - and that's what I'll be doing after this commercial break.

And hopefully I'll rember to post the next dev log here .... otherwise you know where to find updates.


Beware! Information ahead!

Nothing game related this time from me (you don't want to hear about the ups and downs of [re-]writing an e-learning platform, do you?)

So what we have here today is something Lego related. I think I mentioned once or twice my fascination for Lego and for architecture (on g+ at least) and in between coding session I started to build my own version of Case Study House #22 (or CSH#22 for short, also know as House Stahl). I'm not entirely sure what I like more, the house itself or the picture of it (done by Julius Shulman).

I began tinkering with it sometime last year (the early part) and I guess a first model was ready by mid 2011, ordering it through Lego's Design ByMe wasn't quite an option as the model came in at about €180 (some 930 parts after all), so I filed it away as a nice thing done.

Came December and I felt the need of buying something useless so I had another look at the CSH#22 model and started to redo it, reducing parts and adding a base to the model and ended up with 841 parts and a model I was pretty pleased with. Still €149 is something to think about (esp. in December) - no order for me.

Finally on Jan. 18th I decided I *want* that model. NOW! Too bad Lego discontinued the service on the 16th. What a let down I can tell you. To cut that part short - I ordered all the parts through Pick-A-Brick (€50 less, btw) and now it waits to be assembled.

Erm - what was I about to write about again?

Oh, yes. The model went on (go, sign up there ... and vote for it) - although I think 10k backers might be a bit ambitious ...
Anyway, from there I was contacted by a nice fellow who asked if he could do renderings of the model (as the screengrabs from DigitalDesigner are not really making anyone "wow").

So here they are:


A shot not unlike Shulman's foto (click image for larger version)

Front shot (click image for larger version)

Overview (click image ... you know)

Images rendered by Phillipe P. (see his other renderings on Flicker or at

I'll post an image of the finished "real" model ... when it's done ...