Gaming Your Way

May contain nuts.

Specular lighting

Progress with O2 is still going well, there's just a silly amount to do.

I've spent the past few days swearing at getting bump mapping in the game, creating a specular lighting effect. I think it was worth the pain.

The level without the lighting effect

With specular lighting

I'm really pleased with the effect. I did originally have both diffuse and specular, with the thinking that the outside level floors would look great with the diffuse mapping, but in reality the CPU cost wasn't worth it for the effect, it just didn't look as good as I wanted, so some perfectly good code was killed off today ( But I'm sure it'll make a return, in maybe an iso dungeon crawler, just a wild shot in the dark ).

Squize.

Outpost 2 title animation

Isn't it great when you can just be lazy and link to someone else's blog ?

Construction of the title animation.

Lux has done a great write up of all the steps which go into making the Outpost title screens just so insanely lovely. Maybe one for the artists out there rather than the coders, but getting an insight into good design is always important for everyone.

Squize.

HaXe, NME and I

Start of the week I had a play with HaXe / NME, I figured it was more than worth a day or two to play with them.

It was a mixed bag to be honest. I use FDT as I'm a Mac boy ( Plus I just like Eclipse, I don't understand the hate for it ), and they've really improved HaXe integration in it, but, HaXe and NME are different beasts, and the support for NME isn't as good. I did find a handy ant script for it, but... it may sound petty but it's a bit of a workflow breaker. Not a huge deal having to run an ant script, and I'm sure there would be someway to add it to the launcher chain which someone smarter than me could figure out, but screwing with my workflow really bugs me, and these simple little changes soon become an annoying chore. I don't want development to have more steps than it had before, that's the opposite of progress.

I'd read mono-develop was good with NME, and as Unity uses that and I'm looking ahead slightly, I thought I'd give that a go. Sometimes its better to start afresh rather than shoe horn things into your current setup. It's, well, it's ok but it's no FDT. I was missing auto-importing and code completion seemed to be lacking ( Again this could be a learning curve thing, I'm sure some people will read this and be screaming that I'm a dumb arse, it's just a simple key combo of <whatever> ).

So I set about porting O2, I mean it's just Float rather than Number, Int / int and Void / void pretty much. Got as far as my Init class where I call my fpsCounter and arse, first brick wall hit. From what I can tell you can't really included a code laden swc if you're using NME. Time to convert the code over to HaXe, which didn't take too long as there's virtually no code in the fps counter. K, job done, how do I include the assets I need ?

I had it in my head that HaXe supported importing swc's directly now, but the only info I could find was for importing swf's. Being the stubborn dick that I am, and stupidly believing my brain, I lost a load of time trying to find how to import a swc. You can't. K then, lets just import the swf. That was a bit of a struggle as I got my head around it, but at the end of day 1 I had NME set up, mono-develop installed, and 3 classes up and running with a fps counter. Oh.

Day 2 I started adding my Layers class, which required some assets from my huge assets.swc ( swf now ). It seems imported assets have to start with a capital letter ( Something I'd discovered doing the fps counter ), argh, I'm a camel case boy, every single asset export name in every game I've ever done is lower case. It's ok, it's fine, this will pay off when I'm running O2 on mobile at 60fps without stage3D. And now it's saying under mono-develop that it all compiles fine without errors, but there's no swf to run. What now ? ( Also before that I'd seen that my simple little 3k outputted swf was 24k when built with NME, there were some additional classes being shoved in there, but that's not a worry, shit it's only day 2, there's going to be things I don't understand and the community is really lively around NME so nothing to really worry about there )

At this point my spirit was starting to break. I wasn't liking mono-develop, the swf was taking nearly as long to compile as the full blown game using the Flex compiler just by adding the assets in there, and there wasn't a swf to test even at the end of it.

Fuck this. Time to go back to FDT and HaXe, let's get that working, then look at NME after. Ah, FDT I missed you, so much quicker and the build times are stupidly fast. Copied everything back over into the HaXe project and then this line gave me an error,

mapPlayField=new BitmapData((640/32)*7,(640/32)*6,false,0);

Really ? It seems using a division in HaXe casts the number as a Float, but the BitmapData constructor expects an int, which quite rightly threw an error. It makes sense, it's logical, I get it. It needs casting as an Int. But that was the exact moment this camel's back broke. I could either plough on for the rest of the week porting O2 to HaXe, and then hope that runs out of the box with NME, with the performance improvements I'd expect, or call it a day. You can guess which option won.

If this seems critical of haXe / NME, it's not meant to be. They're both as sexy as you like, it's more a combination of things. Losing my workflow, a lack of patience, and just the vast scope of porting a project as huge as O2. I've got an upcoming client project which targets Android ( I may be an indie, but an indie who needs to afford food ) and I'm going to use NME for that, it's a perfect way to test it and I'm glad I've done this ground work, it wasn't two wasted days, but when it comes to porting a large existing project I think it's not feasible until you've got a lot more experience of working with it under your belt.

Squize.

PS. Thanks to all the guys who helped me via Twitter, wow, Team HaXe / NME are like Amiga owners in their love of the platform.

Bye bye Swarm, hello side quests

We have been thinking what we could do with Swarm mode in Outpost 2. I really like the mode, it's just a nice switch off your brain bit of shooting fun, and I think it holds up well on it's own ( Outpost:Swarm turned out much better than I could have hoped ). But, I don't think we integrated it well enough in Outpost:Haven, the idea was to add a little extra to go back to after finishing the story, to give the whole game more value. It does, but it's a little bit disconnected ( To the point that it actually works as a stand alone game with very little story context attached ).

Our thinking with Swarm in O2 was to make them optional "Side quests", kinda. The plan is that even during the game itself you'll be able to select a side quest from the mission select screen and go and have a bit of fun there before coming back to the story mode. Going down that path meant what do we reward the player with for doing a side quest ? They'll get extra XP which of course helps with unlocking items, but is that enough ? We want to encourage people to play the mode, there's no point adding value if only a small percentage of players are taking advantage of it, so we're going to add unlockable perks as your reward which should make a very real difference to the story mode.

So that's the current plan, anything to make this game even more complicated and hellish to code.

Squize.

PS. Should we release Swarm:Facebook this week ? I can't see why not, so we'll do a soft launch some time this week I guess.

Look who's getting all social

Just a really quick post to mention we've got a Facebook page set up for all things Outpost.

At present it's more focused on the development of Outpost 2, so if you want to see the brand new inventory screen WIP for example, shoot on over there, with the view that eventually it'll become a hub for everything to do with the 3 games.

( I'll still be posting here about it, but the less sweary ones will be mirrored on the FB page, plus my hands are a little tied with what I can post. Tech things like the shadows are fine, but I don't want to be giving too many spoilers away, so yeah, I'm a little limited in what I can share ).

Anyway, here's the all important link: https://www.facebook.com/outpostGame If only there was some way on Facebook to show your appreciation for something, some sort of button you could click to show how fond of things you were, because if there was such a thing I'm sure you guys would happily press it.

Squize.

First design faux pas*

If you've played Outpost:Haven you'll know on the first level it's a bit of a mini-tutorial where we have both characters, Lee and Jameson.

Very early on we split them up, Jameson goes and takes a lift and goes off to have all the adventures in Outpost 2. For continuity we're keeping that sequence in O2, except obviously this time you play as Jameson.

So yesterday I started adding the path finding code to the main player class, you hit the invisible trigger, the text comes up "Lee, do your thing here, Jameson get on the lift and have your own adventures" ( Paraphrasing slightly there ) and the pathfinder kicks in and moves you to the lift ready for level 2.

No, sweet baby Jesus, no! In the cold light of day I see how wrong that all was. Was I really going to take control away from the player during the opening minute of the game ? What was I thinking. That was truly awful game design, to take the player out of the game before it's even started. So today I'm ripping out all that badness and doing it properly, and writing a blog post to shame myself so I never do anything that bad again, and to hopefully show how what may seem an ok design choice always needs thinking about.

Squize.

*In Outpost2 that is, there have been dozens and dozens of other design fuck ups over the years.

Dynamic shadows in Outpost 2

This is a freshly added feature, so it may yet be ripped out due to performance concerns, but I thought I'd share anyway.

Sexy big shadows

So we've now got dynamic shadows on the player sprites in the game. We can't do anything with the static wall shadows as that would be just too costly, which is a pity, but I'm hoping we can run it on the larger baddie sprites without the game grinding to a halt ( Since O2 has been basically in pre-production for a week and a half now I've been refactoring a lot of the code, such as the particles, to gain performance which should hopefully enable us to add even more eye candy than in the original ).

Let's get our hands dirty with some theory of how it works.

Ah, light probes

On the map we add some "Light probes", which are our light sources ( The actual light images you see in the game / map are just that, bitmap images, so we had to add specific ones. It does have the advantage of giving us more control though ).

When we plot our level we loop through all the light probes and store their x,y and alpha. Then we do a distance test to the player and sort the array where we store all the light probes based on that, so the very first one closest to our player at the start of the level is at the front of our array.

From there we just check every time the player moves their distance to the light probe. Based on that we can set the length and darkness of their shadow ( So it's a little bit of atan2, and some scaleY / alpha code wise ).

The tricky bit is moving from one probe to another. Originally I just checked the next and previous light probe in the list ( Hence pre-sorting them at the start ), but when there were a few together ( Like in the example above ) that could break, which wasn't part of the plan. So I've just altered it that on even frames we check the 5 probes "behind" the current one in the array, and then odd frames we look 5 in front ( The check is just a simple distance check, if the probe we're testing is closer to the player than the current one, then make that the current one ). That seems to have fixed things, although it needs testing on a complex level, which is why it may still yet be ripped out.

The first approach wasn't a dead loss, it's much quicker than the current one as we're only checking against 2 probes, so I've kept that code for the npc and it'll be what I use for the baddies, as I think we should be able to get away with it.

As a final touch the shadow is animated, it's actually a walk cycle from our Knight's Quest game, but with scaling / blurring and alpha you couldn't ever tell. Speaking of alpha, the reason we store each light probes alpha property is because that sets the intensity of the light source, with full 100% alpha being the brightest possible light sources. I'm toying with adding colour information to them too ( It'd be so easy if we could just add a tint and read that, but unfortunately not ), as it would be cool if for example when you're approaching a console the screen would not only let the player cast a shadow but light him up too ( It would make them similar to their Unity Light Probe namesakes ).

There are limitations to this, we're only ever running one shadow sprite as opposed to 4, so in the in-game grab above the sprites should be casting shadows from the other 2 light sources too, but this is just meant to be a bit of subtle eye-candy so there's only so much cpu cost we can spend on them. I'm sure someone on Kongregate will let us know about it anyway.

And that's basically it, hopefully it'll make the cut as it does look cool.

Squize.

It's not you, it's me.

Oh dear sweet blog, we've been treating you badly for a while now haven't we. Flirting with Facebook and her whore sister Twitter when all along it was you we always felt ourselves with.

Basically I'm trying to apologise about the lack of posts here in forever now. Lot's of stuff has been happening, we've knocked out two adver-games and a website between the two of us ( I don't know if we'll ever link them up, one for vanity reasons, one because it's behind a registration and I don't think we're allowed to take credit for it ).

Also we've been working on Quantic Velocity, twice. It started off as a stage3D game when DN8:Pulse was still in bidding, as there's no way a stage3D game can do badly is there ? Lux and I had a long chat about it, and realised it was pointless pursuing it as DN8:P had done so badly, so we rebooted the project. The new version was going great, until we put corners in the map ( It's basically a top down WipeOut like racer ), which badly broke the AI. I threw a week at it just trying to fix that, and with no joy. I'd coded myself into a corner and just couldn't get out of it. All my passion for the project went, and it was becoming a painful chore. So, that's on hold for now ( It's not ditched, as it was playing really well, it's just that I made a mess of it ).

What are we on now then ? Well it involves the number 2 and Owlmen.

More soon...

Squize.

Just a quick one...

I do love it when a bug does something you could never code in a million years, with the added bonus of it looking pretty.

Perhaps not the best way to show a first glimpse of the new game ( Quantic Velocity ) but we're drowning in work, so this is all we've got right now.

Squize.