Gaming Your Way

May contain nuts.

And then they said that burning the secret documents ...

... only made things worse.

See, all the good intentions are gone by now - that is having the weekly post done before Sunday, well at least it's not 23:52h.

Although I have a good reason as I haven't worked at all for two days straight, trying to get my laptop back to work. In theory it would have been a case of just restoring the last weekly backup, but alas ...

I'm using a Dell, you know, running win 8.1 pro (64bit) with Intel Rapid Storage (magically using a SSD and a HDD mixed up for speed), Intel onboard gfx and an additional ATI Radeon card for 3d / games. I mention this because this combination is the the reason for the two wasted days (although, it's partly my fault).

The whole mess starts with me noticing that the Catalyst Control Center wasn't running (so no choice which card to use), as I had that earlier (when running still running win 8) so I knew that I just needed to install the latest ATI drivers again. That done and a reboot later the only thing I got was a black screen and a flickering cursor. What followed was a lot of cursing, because after I used a "recover to last working version" I ended up with a clean win 8 install and just a few of my settings and none of my programs left.

Ha! No problem, I have a backup that is just one day old.

To cut this short, in order to get the OS partition restored I needed the following: change boot mode to legacy (UEFI by default, to run the linux based frontend of the backup software), turn off the Rapid Storage/RAID settings in BIOS in order to access the HDD and write back the partition. With this in the recovery only took about 30 minutes, great that there's nothing to be found about this on the interwebs ... and you only come to this after 2 days of "can't this", "error that".

Oh and I had to install the ATI drivers provided by Dell in order to make things work with win 8.1 ...

... now lets's start with this week's post.

Yes, I used that image before.

I mentioned that the HUD in MTR is far from ideal or even "pretty", too much information, too small and not helpful. One of the tasks on my list therefore read "redesign HUD" and this post will go through some of the iterations that the HUD went through.

The information I wanted to show was: car, position ( the badge icon), lap time/total time and boost (the battery). Once the race is running, having 4 pairs of changing numbers is quite a bit much distraction from the track.

Iterations of the new HUD.

As you can see the icons changed quite a bit and all of the icons that were used as labels are gone now, too. 

The final HUD comes in two flavours: horizontal (for smaller screens) and vertical (for larger screens):

Default view for larger screens ...

... and for smaller ones.

The latest version adds a hint of color to the backgrounds of the badges (using the car's main color). The position is now shown by the order of the badges, the local player is marked by the orange line (color may change). It also brings back the battery icon, well sometimes, but that's for another post ...

More next week,

-- Oliver / nGFX

Minor changes to the UI and a serious rewrite of the AI.

Oh. I didn't mean to add a really helpful title, but I couldn't think of something stupid, so this has to do it.

It's time to pour some (erm ...) time into MTR development. First thing today is getting rid of the HUD, which is neither pretty nor particular useful at the moment.

The UI in all its present glory.

As you can see at a first glance it is way too cluttered, there are too many numbers running and the icons aren't very helpful.

I thought it might be a good idea to show infos for all four cars (as you should be able to run a four player game), but I think I should be able to condense it a bit anyway.

  1. no need for two times per car (first being lap time and second total race time)
  2. number of laps could be shown for the car on position 1
  3. showing the position of the car with an extra icon (the badge) could be reduced to just the number next to the car's icon
  4. car icons should show the actual car
  5. get rid of the black bars

I also need to reduce the number of draw calls, so I started to modify the prefabs of the tiles and separated colliders and meshes and gave them correct names. The routine that plots the track now can split these up once added to the scene, grab the meshes and bake them into a single mesh.

If time permits I'll also start on rewriting the AI (mentioned earlier it uses waypoints as rough guidelines). With four cars on the track chances are way to high to miss a waypoint, which I currently check using a simple distance check.

The new method ... but hey I need something for the next post.

And with this, catch you next time (when I hopefully have fixed the AI).


-- Oliver (nGFX)

Meet the gang ...

What, it's Saturday again?

I'm so glad I have something to post about.

As I mentioned last week there is work to do on that little racing game. Time between various other projects has been spent doing the last car I needed.

I'm number four.

So with the first four cars in place I can finally do some racing with different cars and although the AI needs a lot of tweaking until it runs like I want it, it feels a lot closer to a game than before. Still there's a good deal of stuff left before I call for some beta testing.
First thing on the list is the player car selection, although I'm still not sure if the cars will have different stats at all.
Second thing will be the track selection, no idea how that will look like (doing little spinning 3d tracks or simple 2d icon style ones (like the menus). 

And last but not least there is need for some more tiles, namely elevated corners and steep curves (I'm actually looking forward to see these in the game).

To end this meagre post here's a picture of all cars, right from the game running (looking at it, the first one is from the game running, too).

Not sure if you noticed, but the red car is now a blue one ...
  and it's going to become white in the end.

So catch you next week and if you haven't already done so ... just two words: Outpost and Greenlight ...

Oliver (nGFX)

I want to be a social media strategist ...

... because if I were, I could "Create a deliciously irresistible blog post title". 

Oh and no, we won't let you do a guest post on the GYW blog that could "benefit" us both.

The real title of this week's post should have been "Deciding how textures should look like". Client work took over again this week so I just did small thing during the daily 30 minutes of development time. One thing was to setup the machine puzzle in Unity and importing "Danielle" (one of the Characters you'll be able to play) from the old version of the Hellstrom Project. I juts need to make the animations work with the new controls (although I need to rebuilt the character anyway in order to animate the walk cycle using the standard 7 keys one I found in an old animation book - from the early days of animated films).

The rest of the time I spent evaluating how I want my textures to look like, as this also defines how I do the rest of the environment.

current unmapped version

When I started modelling I wanted to use no textures at all and just create lightmaps and solid coloured objects not unlike the unmapped version above. As much as I like the look, it also makes things a bit more complicated. Objects like rocks and cave walls need to be modelled to make up for the missing textures and honestly the flat walls look a bit dull.

using image based textures

I admit the example for image based mapping doesn't show my point as well as I thought when I made it, but as you can see there's a lot of detail behind the machine. You also may notice that it kinda looks flat, so it could do with normal mapping and/or more geometry. Even though I could build the stonewall with detailed geometry and then render the normals maps, adding details with extra geometry if needed, this will add a lot more work to the initial alpha version. No to mention that it doesn't look like I imagined it.

Painted textures and a few extra polys for details
(the 3 "blocks" right of the arches)

"Painted" isn't quite right (yet) but it shows the direction I want to head for the textures. The few extra polygons needed for details won't hurt (and I guess I can still optimize a few unseen ones away later)

And with this I'll end this post and try to come up with something to post next week.


Oliver (nGFX)

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.

The world in words and pictures

My calendar icon tells me it's Monday  - and July already. This means I've not only missed the start of the summer, but also don't know what happened during the last six month.

All I know is that I started to work on a small scale semi top-down racing game that should be finished in "not more than 3 weeks solid work".


Anyway, the blog needs writing and images.

I've added a new car (see image), coded parts of the backend (for storing tracks "in the cloud" - just to use a buzzword) and a lot less bugs than on my last post. All tiles have been redone, as I needed to split the floor (road) and side (rails) colliders and even a few deco tiles have been added to the editor.

"Right away Michael."

"Look, it's a tree"

What I don't have is solid physics and a working AI. The first is a matter of bending the rules to my favour - which slightly collide with the rules the physics engine believes in. The latter results in parts on the first problem and my stupid idea to control the AI cars using the same principles as the player car, read instead of telling the car to "drive at speed Y" or "turn left X°" I simulate the controller as if a human would be playing. Of course I have a stupid (but perfectly valid) reason for that - playing back things.
Right now I'm brewing a nice mix of waypoint driving, raycasts and player data and it nearly works the way it should, well it works the way it should, but at times it fucks up due to "unforseen" events. 

I'd love to write some more, but just as the weather became fine, there are deadlines to meet ...



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.