Gaming Your Way

May contain nuts.

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 ).

Squize.

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: http://steamcommunity.com/sharedfiles/filedetails/?id=177695239

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

Squize.

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)

Lost Outpost Trailer

So we've got some good news. Let's start with the trailer should we ?

In other good news, the game is now content complete. Thank fuck. We've got another couple of weeks of bug fixing, tweaks and polish ( Plus I've got some copy to write, I've not done the info-cards yet ) but we're nearly there.

Squize.

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.

It's been forever hasn't it

We've been crunching for weeks now, hence my disappearance from here ( It was nothing you said ).

And in saying that, this is only going to be the shortest of short updates.

We posted a new demo to our Facebook page the other day, and have had some great and really useful feedback, so that was well worth the effort of getting a vertical slice in place.
Level design / build is on-going, just to prove it, here's some level 6 action:

I've literally just finished that level off, hence me having 5 mins to post here.

So we're looking at 3 more levels, all of which are already in some state of development, and the Swarm levels, and that should be nearly it game content wise.

We're getting closer...

Squize.

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 http://www.ironbloggerruhr.de/. 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.

nGFX

This isn't going to end well

Thought I'd show a quick grab of Swarm mode now it's back in. I don't think Jameson is going to survive this somehow.

Just in case you were wondering, that highlighted area is a "Hardpoint", earn double cash for every kill you get in there.

Squize.