Gaming Your Way

May contain nuts.

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.

Outpost:Swarm postmortem

It may seem a little strange doing a postmortem for Swarm without yet doing the Haven one, but it's up on Kong now so it felt right to give it a pimp shot in the arm, plus it should be a lot shorter for me to write as I'm just going to cover the specifics in this game rather than the whole thing.

What went right:

1) The huge advantage we had over Haven was the insane amount of feedback we had banked when making this one. Filtering out the noise with feedback is always tricky, but with so much and so many detailed ideas it was a lot easier. Because of that Swarm is a lot tighter in many respects than Haven. The movement is better, the indicator showing the direction of damage, just so many little almost unnoticeable things got tweaked that even though we finished this only a couple of months after Haven, it makes a lot of things in the first game feel dated to me.

2) The AI co-op is the most obvious stand out feature. I'm not sure how this came about, I mean it's an obvious thing to do, but I remember Lux and I talking at the start of the project and agreeing that we had to make the game stand up on it's on, it wasn't meant to be Haven lite, but a good game in of itself.
From memory I just spent a day seeing how it would play out, if it worked and worked as well as we would have liked then sweet, if not then we'd just drop it and write that day off. More by luck than judgement it did play so much better that it set the mood for the rest of the game. I'd say having Jameson as your wing man in this game makes it what it is as much as the aliens.
One last thing to tie a bow on this one, having the different colour schemes for the main sprites made a huge difference, something we really should have done in Haven. 

3) The new tilesets / locations worked so well. We managed to re-use a fair few assets without hopefully feeling like we'd just lifted them wholesale ( I think we only added one new visual effect though, the smoke flares on the planet side levels. In our defence, we did make a lot of one shot visuals effects for Haven ).
From that basis Lux really came up with some beautiful stuff, the sewer level is great ( Unfortunately a bit of a CPU hog ) and the planet side levels used the terrain splatting which we developed for Knight's Quest at last. The out doors levels are just stunning, we're going back to visit that planet again in O2.

4) The game flow, from pressing Play to actually playing the first level, was tweaked a lot thanks to feedback from Miniclip. Normally amends just 'cause a groan in all coders ( And these did too to be honest ) but they removed a lot of clicks and helped you get into the game much quicker. Amends which actually improve a game ? Anyone who does just adver-games will think that impossible. It did have one downside though, but lets save that for the next section.

5) I really like the "pop-ups". Popcap nailed giving awards to players, and I've always been a fan of that, and the COD titles have just taken it and put it in an arcade / shooting context, which I really like, so we embraced that a lot more this game, and I'm really pleased with it. We're always flashing up some update ( The mode in the recent Halo games whose name escapes me right now also inspired me with this a lot ).
It helps ground the game I think, shows we're not playing a survival horror, but a shoot'em up with terror aspects. 

What went wrong:

1) Time. We just ran out of time and budget to do all the things we wanted. We had hoped to add a new baddie type ( A flying bug type thing. I had a vision of them being like a swarm of gnats ) and I wanted to add the sentry weapon ( Which is something I think everyone wants ). I think the AI just ate into the time to do those things and it was a worth while trade off, as it brought more to the game than anything else we could have added.
I can't remember how much we over-ran the deadline by, 16 days or so, not a great deal, but there are always lose edges which need tidying up and adding major things like a new baddie would just have blown the deadline completely. As soon as you're past that deadline you're working for free and you can only do that for so long no matter how much you love the project.

2) After the whole Owlmen story running throughout Haven there was a lack of context in this. We did have a briefing in there, which we removed to improve the flow, but we had no story at all, no reason for this to be happening. I assume people who played the first game got it, but that's not really valid as it's meant to be a title which can stand up on it's own. I was toying with having info-cards really hidden in levels which would progress the story, but they would only have been relevant to players of Haven as we didn't have enough scope to explain the whole thing.
I regret that we didn't explain Swarm mode more. In my head it was always like a TV show being shown back on earth, Lee and Jameson are basically dead men walking at this point, there's no escape, so they'd go out fighting and all the money they earned from the bug hunt would go back to their families on earth ( These aren't stupidly brave men, they're just two guys caught up in a shit storm which they have to tackle head on ). Even at one stage I thought of having crowd cheers if you did something really cool, like you were watching this in a bar back on earth on a TV, but without any sort of context it would just have been mental.

3) Some of the levels aren't great, level 2 is too hard as it's so small and restrictive. Also we had to re-use a [ Tweaked ] level from the swarm mode in Haven as again we'd run out of time. Level design doesn't come easy to me, it's something you need to iterate over to get just right, and with that clock ticking I didn't really have the time.
Plus making an interesting level which is basically just a loop is tricky, with no clear objective, no going from point A>B, it's hard to make it interesting, and I failed on a couple of levels, with the medical lab being the stand out mis-step ( And it really doesn't help that it's only the 2nd level ).

4) We'd reduced the difficulty of the challenges due to the feedback in Haven, but like in the first game we struggled to come up with the unlockable awards. They're ok-ish, but we didn't do ourselves any favours by having such a limited pool to draw from, and they were very last minute and of course with that the panic of "Shit, we haven't got enough stuff".
Not a major failing, but something we need to think about more for the next game. 

I'm sure more things went wrong, but they escape me now, but those things annoy me enough for 5 issues.

 

When it went on Kong the other day I thought I should really give it a go ( After voting 5 for it, it felt like the right thing to do ) and I'd forgotten I'd used the "They're here" sample on the intro which made me jump. Then I gave the first level a play, kinda half hearted as I have played it once or twice before, and I really loved it. There's a bit in Aliens after the sentry guns have run out and they're all in a room as the aliens are closing in, and then they all fall through the ceiling and it really kicks off. It felt like that. Fucking felt great to be honest.

So I think that's this about done. Not many regrets, lots of things to be pleased with. I wish in a way we could have done this one first before Haven, but things like that are impossible to second guess.
As always it was a pleasure working with Lux, and Rob and Theresa at Miniclip were a joy too.

We can't wait for the Owlmen to return, and it's going to be soon...

Squize.

Stage3D stats for DN8:Pulse

That's quite a bland title for us isn't it, sometimes I guess we've got to be a bit literal.

Anyway DN8:Pulse has been out for 23 days now, so we've got some figures to share.

Thats some nice pie

No exact figures I'm afraid, more on that later. So, out of everyone who loaded it 81% had the best time ever, shit they loved it, they likened it to seeing the birth of their child.

14% were stuck with software mode, 2.7% were playing it on a site where wmode="direct" wasn't set ( I assume that for the most part that was shovelware sites who just blindly put up any game, I mean who cares if it works or not, they still get the ad rev, and if a games broken it's not the portals fault, it's those lame devs not checking their own work. And it seems after writing that I'm a lot more bitter about it than I thought ). Coming in last place is players without FP11 even installed, with 1.9%, which is much higher than I would have thought.

This is what we're looking at with stage3D right now then, only 80% of your target audience is going to be able to play it as intended ( Software mode is just poo and not worth entertaining ). Factor in that we all pretty much live and die by our ratings on portals, that's 20% of people thinking you suck so hard 'cause their machine can play WoW but not some shitty free Flash game ? Wow, that must have been coded badly, 1/5 for you. Now I mentioned above how 81% loved it so much they were willing to kill Helter Skelter style for you, but that's not true is it. At best you're looking at 80% of people who actually play a game really liking it ( And that's on a big fat hit, not a niche bullet hell shooter set in space ), so that of course is reflected in your overall rating.

It's like doing a AAA game for Kinect, you're reducing your audience before you even start and then you've got to hope everyone who does get to play it love it. DN8:Pulse is a good little shooter, but it's far from the best thing ever, I'm aware enough to understand that.

Ok, I don't want to give out exact figures for the number of players, as that's TurboNukes information to do what they like with, not for me to hand over ( That's like saying how much a game got sponsored for ), but even picking up a daily first on NG, and sitting on the front page ( And getting a great review on JIG ), it's done woefully badly. I mean really badly. It's had a lot of plays, and the average play time is 12mins, which I think is pretty good ( over 34 million baddies have been turned to pixel dust ), so people who have played it seem to like it, just no one has played it. It's currently on 98 sites but the traffic is just dire, and it's taken a while to spread to that many sites.

In terms of selling it, we couldn't have had less interest if we'd made a game about kitten genocide. Not one single site lock sold ( And only a couple of approaches for them, neither panned out ). We could say that a bullet hell in space is always going to be a hard sell anyway and it may not purely be because of stage3D, and I think to some extent that is true, but stage3D really hasn't helped it.

Anyway, time to wrap up this tale of woe. It's far from all bad, I'm really pleased with the game and I got to work with some really cool people to get it out of the door, so that's a major win right there. We've got the Android version 95% done and I got to take a crash course in ND2D and Away3D. In terms of performance, yeah it's blown, but quite a lot of players have really enjoyed it, and that's what it's all about.

Squize.

PS. Look out for some info about our next stage3D game soon. Yep, we started it whilst DN8:P was under bidding. I'm never going to be a business man am I.

So how does the NPC AI in Outpost:Swarm work ?

Now Outpost:Swarm is live I thought it may be an idea to explain how I did your in-game partners AI.

If you've ever read up on Boids you'll know they have 3 simple rules,

Separation

Alignment

Cohesion

And all the examples you'll see are bird like objects flying around, maybe towards your mouse pointer, maybe avoiding obstacles. All seems simple enough. Adding them to a real game however quite a bit trickier.

For separation we have to ensure the NPC is avoiding both the player and all the baddies. Firstly we find the distance to the players sprite using a simple

distance=dx*dx + dy*dy;

Like you would in your usual circle to circle tests. If we're too close then we need to repel the NPC from the player, via:

tmpPoint1.x+=dx+dx;

tmpPoint1.y+=dy+dy;


Where tmpPoint1 is just a new Point(0,0);

That's part 1 of the test done, the second is checking against all the baddies, and there can be a load at any one time. What I did was use a flip flop, every even frame we get a list of all the possible neighbours ( Baddies which are close enough to care about, if they're on the other side of the screen then we can skip them ), every odd frame we do exactly the same distance check as we did above.


Finally we divide our Point value,


tmpPoint1.x/=speedDivisor;

tmpPoint1.y/=speedDivisor;

( private var speedDivisor:Number=20; )

 

This keeps the values within a respectable range so we don't move too fast.

Outpost:Swarm

The next rule is alignment. Lucky for us we don't care about that in this case, we're not creating a flock of birds or swarm of insects, we just want one guy to look fairly smart and follow his friend around.

Cohesion in this case means following. We do another distance check to the player, but this time with a greater radius ( We want them close and for the NPC not to lose sight of the player, but we don't want them virtually kissing. That's planned for the sequel, Outpost:Date&Fuck ).

var dx:Number=bodyXPos-targetX;

var dy:Number=bodyYPos-targetY;

var distance:Number=dx*dx + dy*dy;

if(distance<3000){

  tmpPoint2.x=tmpPoint2.y=0;

  return tmpPoint2;

}

 

tmpPoint2.x=(targetX-bodyXPos)/speedDivisor;

tmpPoint2.y=(targetY-bodyYPos)/speedDivisor;


Note the use of targetX/Y, rather than PlayerX/Y, we'll come back to that at the end of my presentation. As you can see, it's pretty much the same thing as before, and something I'm sure most of you have done with your circle to circle checks.


Right, we've got two Points after running our rules, time to calculate the NPC's velocity.


velocity.x=rule1V.x+rule2V.x;

velocity.y=rule1V.y+rule2V.y;


Then we do a quick test to make sure the velocity in both directions isn't greater than the max speed we've set for the NPC, we don't want him outrunning the player ( Or actually, not to outrun the player enough that people will notice ).

The next part was the tricky one, we can move him around fine, but what about the walls ? It turned out to be surprisingly simple. We use good ol' tile based checks. If there's a wall on the horizontal of the NPC we set velocity.x=0; and then the same with the y. 

We're finally there, we just finish off with

sprite.x+=velocity.x;

sprite.y+=velocity.y;


Cool, and that's how you can use Boids in real life ( The same principle handles the baddie movement ).
 
Let's test that out in game. Excellent it works, and if I manage to lose the NPC behind a wall then... oh tits, he'll just sit there. That's not a great look for a hard as nails space guy with a big ass gun.
 
Check this level map out,  

AI path

Within each level we lay down a path for the AI. Every couple of frames we look to see if the NPC can "see" the player using a line of sight. If he can't it means we've ditched him behind a wall.
When that happens we fire out 4 rays from the NPC until it hits one of those path tiles ( Remember at the heart of the game is a tile engine running alongside the purely physics based one ). Once we've done that we can easily find out which is the nearest part of the path, we change the TargetX/Y ( From above ) to our tile and the same code that moves him towards the player moves him towards the path.
All the time we're moving towards the path we're doing our line of sight checks to the player, if we spot him again we break off from the path and go back to following the player.
 
It's not fool proof, if he gets lost then he's only going to make his way to the path and then not do anything really clever, but because the levels are small enough you should soon bump into him again to get him following the player. Also, he doesn't really need to be that smart when he's off on his own, we just want to create the illusion that he's not a dumb arse, he doesn't need to be Stephen Hawking ( Perhaps not the best example when talking about movement ). Finally, we're still using Flash, we don't have all the CPU time in the world to do something really fantastic.
 
And that's how we move the NPC.
 
Squize.
 
PS. Wow, looks like I've got about 40 fonts / sizes in this, nasty, but it took enough time to write this up, I'm going to swallow it looking slightly ugly.