Gaming Your Way

May contain nuts.

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)


It's Sunday again, although for a change it's not 23:45h while I'm writing my weekly blog post.

I guess I mentioned last week that the lazy days are over and I have to get back into the joyful pace of client work. Last week I started to setup a new client site and the racing game came back to haunt me (and it needs finishing too, if possible before the end of the year).

Website layout.

The sceengrab above is what we got as sitemap for the client website. We spent a few minutes wondering about how to turn that into a website and then settled on the idea that we just use that. To our surprise it pleased the client extraordinarily - which in turn pleased us. It even pleased me, until I started to imagine how to build this and not use an image / image map (which, let's be honest, would be a moment I should quit my job).

So I set it up as a combination of css3, canvas and javascript to make it as dynamic as possible. There's all the latest shebang hover effects (like highlighting connected circles and lines), transitions (when circles turn into popups) and some parallax effect when scrolling down to the other parts of the website).

It doesn't happen often that I can say "I'm quite pleased with the outcome".


After that I went back to MTR.

I'm still in 3D mode so instead of starting with code I started building the 3rd car.

The 3rd car, at least one more needed.

This one is quite easy, no fancy corners and this is the outcome of about 4 hours work. It's missing some details like the bumpers and lights, but that's for tomorrow morning. I even look forward to UVW map it (well, who wouldn't, as it's essentially a box with wheels).

I think the rendered version looks a bit shit right now.

I'm not quite sure what the 4th car will look like (although I have an idea) and with that I can finish of the dreaded AI. I then have to do a client version of it - which even might become the initial public release (so I have it out of the door for a while). The client version will feature single player mode and six fixed tracks only, maybe a few (very few) car upgrades.

We announce the next important post after the break ... or next week.

If you haven't done so already give Lost Outpost your greenlight love:

Catch you next week,
-- Oliver (nGFX) 

... and so it goes,

and so it goes
and so it goes,

but where it's going no one knows ...

(Nick Lowe, 1976)


That said, this "one post per week" is already going on my balls. Anyway, it's 23:31h on Sunday and I'm hammering out this week's post, well knowing that there isn't much to write about.

The week started with going back to "real life" and finishing off a client website, which is using a lot of the oh-so-new (as far as marking people know) web toys (css3 transforms, canvas) - oh boy did I have fun.
[Add a rant about the shortcomings of css, js and html here (or look me up on g+)]

... and as client projects go, some of the copy is still missing, and some last call changes delayed the whole project quite a bit - always a good thing if you want to get it live asap.

Let's get on with a more productive post about the Hellstrom Project. I haven't been coding much for the last 3 weeks, but I managed to export the last 3d model of the first block and import it into Unity. A quick "walk through" showed that the map is a bit - shall we say - crowded and things were a good deal to close together.

Sketch of the original layout.

... and so I decided to scale things up a bit. The first thing that got bigger was the waterfall, while the "old" one was about 4m high, the new one should be about twice as high (and wide), after I made that bigger the whole layout of the map had to be changed (which was the plan anyway), but I didn't want to just scale things up by 2.

Now that's what I'm talking about ...

In the end I thought: "Oh for fuck's sake" and sat down for a quick sketch of the new waterfall area of the map. Lot's of rocks to model, but funnily enough I'm looking forward to it.

Hopefully I'll have that modelled by next week (and I have something to post).

-- Oliver (nGFX)

Lorem ipsum ...

This week's post isn't one. I'm on holiday, I could tell you what I have not done this week: working. I didn't write a single line of code, pushed a vertex or drew a pixel - and honestly it felt great - well for the first 2 days or so.

What I did however, was drawing a few maps and sketching out some more game details on *paper*.

And reading ... and playing (Bioshock Infinity, XBox 360) ... and moving books from the floor to their new home, our new *big* bookshelf - too bad we only managed to move about 2/3 of them, the rest will have to wait until the additional shelves arrive (there's an image on g+).

Anyway to beef up this meagre post I'll add a page filler text ... and catch you all next week (still on holiday then).

-- Oliver (nGFX)

... dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sit amet.

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.

New rules ...

It seems that I'm now a proud member of the Iron Blogger Community, in my personal case it's The idea is to write at least one post per week or you have to pay a fee (which is used to buy beer when we meet once a while).

Announcing that I'm now a member of an Iron Blogger "chapter" counts as a post for that week, but that would be a bit lame.

I'd like to post some progress on the MTR racing game and as a surprise ... I even have to report some progress - sort of.

I'm not sure if I mentioned how the AI in MTR works, but I guess I might repeat myself to get to the point.
When I posted the last time the AI was using waypoints to move along the track and not, say, a fixed spline (which would be oh-so-much easier). I use waypoints, because there is a track editor build in and players can build their own tracks, if fact I do some blending between waypoints so it's nearly a spline.

Anyway, the trick is to actually hit the waypoints when moving along the track, because sometimes you're coming a bit to fast down a ramp and the "hit waypoint" radius is just the few digits to small and so you missed your target waypoint. Detecting that is quite easy - if the allowed angle between driving direction and car/waypoint is too big, we simple jump on to the next waypoint in list and continue driving. The problem is: what do we do if for some odd reason the car turns a bit too much before it hit the waypoint (crashed into some other car maybe) - in this case it all can go berzerk faster as you can mumble "fuck". 
And then there are the other cars, having 4 cars chasing the same waypoint always ends up in a crash and then in missed waypoints ... the obvious solution is to prevent crashes, but that doesn't always work out like planed, too.

The first change I made, was to add 2 more waypoints and so having "lanes" on which the cars drive - this worked better. I created waypoints on the left, right and center of the road and give the cars a "lane" (ie: 0,1,2) on which the want to stay. As far as you want that all is good, but once you want to change lanes things get complicated again.

The current version uses a "floating" waypoint, it goes from the left side of the road to the right side and the AI cars use a float (0-1.0f) to see where they want to hit the wayoint (this also allows to use a "desiredLane" value and blend the current lane with the desired one over time). Now the AI cars cannot miss the waypoint any more, they just can miss their desired lane).

Phew, a lot of words, time for an image.

This is what I've been working on for the last couple of weeks (and prevented me to do any real work on MTR): animating and rendering a lot of small animations showing smoke and fire (sorry no further explanation just yet).

And with this, see you all next week.