Gaming Your Way

May contain nuts.

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)

Using Scout to optimise Lost Outpost

This is going to be a bit of a techy post, so if that's not your thing please feel free to move along. Oh, one sec, before you do, here's some Lost Outpost coverage we've had: ( Interview with Lux plus play through )

Right, let's talk optimisations.

I finally figured out ScoutCC, I looked at it ages ago and was just overwhelmed and not overly interested ( Unless you really need it for a live project it's hard to care ). It's awesome, just so good.

It helped me spot something major with my new sexy ultra quick particle routines. Yes they were sexy, but they weren't ultra quick, the opposite in fact. What I'd done is create look up tables for all the things like movement, alpha speed, scale speed etc. This was to avoid using Math.random() and was much quicker.
The downside being I was creating the look-up tables in the constructor which was causing a really bad performance spike. I thought it would be fine as all the particles are pooled, so it would only be a one shot hit, but where I wasn't pre-pooling enough of each particle that hit was really adding up.

I went a "Factory" route ( I believe that's the correct term, I don't really hold with proper terms. I'm the same with street names, I can tell you where a place is in relation to pubs, but not the actual street name ). I have one class which creates all the look up tables I use and trigger that right at the start of the game so it's pre-populated with random goodness, then each particle just grabs a reference to the data it needs to do it's thing.

Next up Scout was showing that the Movieclips were causing a really large hit. We all know Sprites are quicker than Movieclips, but the difference is really quite startling.
Level 4 was playing up really badly, the water level. It's turns out I'd forgot to call gotoAndStop on all the water clips I make. I have one water object, and it's as simple as simple can be. I create instances of my different sized animation clips ( 13 in total I think ), but without calling gotoAndStop on them all when you first make an instance of them, the timeline runs. So that's 13 clips running on every water object in the whole level ( I can't even estimate how many there are, got to be over 60, there's a lot of water in that level ). Simple fix and it stopped the huge performance spikes.

Right so Movieclips are very costly, and nearly everything is a Movieclip. Hmmm. I went back to my factory method, and created a couple of classes for all the animation for things like the particles ( Explosions being a good example of an animated MovieClip we used a lot ), and the baddies.
These factory classes are basically just a list of public vars pointing to bitmapData, nothing more.

Let's take a baddie as a straight forward example. Rather than having it as MC, I changed it to a Sprite and put a bitmap in it, centre aligned. I then grab a reference to all it's frames ( As bitmapData ) from the factory and to animate it change the bitmaps bitmapData reference ( Ha, what a God awful way to explain that ).


Hopefully that's a little clearer. Now all the baddies and animated particles ( Debris as well as explosions, etc. ) use this Sprite / Bitmap combo and performance has improved a hell of a lot. We use the "Ghostbusters" sequence in the canteen in level 2 for testing, as we're throwing lots of explosions in there with baddies, it's a really full on set piece, and after these changes it always comes in on time, whereas before it would lag at times.

And that's our little story.


PS. I know I promised not to do it too often, but we're still after some Greenlight loving, cheers.


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)

Knocked it out of the park!

Lost Outpost is up on FGL,

Something tells me the reviewers heart just isn't into it.

( This may come across as slightly bitter, but it's really not, I predicted straight 8's with a 9 for sound, same as Outpost:Haven got, so I wasn't too far out. It's just the pointless nature of the FGL reviewing beast which I wanted to share. A year in development and we fucked up the mute button up, I hope you can forgive us ).


Lost Outpost on Greenlight

Just to emphasise the point, just in case the title wasn't enough

Hang on, are you looking to charge us for a free game you've been banging on about for a year ?

No, no we're not. It was always the plan, it's just how could we mention it sooner with the game not being ready ? With it being all but done now it's kinda time to try and push things forward.
What this means is Lost Outpost will still be coming to a portal near you as soon as we can sell it, nothings changed there. What we're aiming to get onto Steam is Lost Outpost: The Directors Cut. That's Haven, Swarm and Lost Outpost in one sexy package. It'll be the definitive version of the game, as it should have been all along.

Let's recap. Lost Outpost is coming out to your favourite portal as soon as possible. Nothing has changed there at all, there won't be any charges, any in-app purchases, nothing.

In terms of the Greenlight page, we'd really like a favour. If you could vote for us and tweet about it it would help us out so much. It doesn't matter if you've only got a handful of followers, if you vote and just one of your friends vote that's two votes we wouldn't have got. It all adds up.

Our page is here:

Thanks. Oh, and don't worry, the blog isn't going to turn into a constant "Vote for us", that would bore me silly.


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)