Nuclear Storm and the future

Hello there. It seems to be a bit of a tradition of mine to open a post stating how long it’s been since I last updated, but not this time! Not unless you count that previous sentence anyway. Onwards!

Nuclear Storm

Our beloved Nuclear Storm is now finished. Well, sort of. We had some discussions and decided that we’d push to get it to beta and then let people play for a while, seeing what sort of feedback we got. That was a month or so ago, I think, and we’ve not really done anything on it since, so we decided to leave it as is.

We’ve not made any real effort to spread the word or arrange any real testing, so feedback has been fairly thin on the ground, but most of the stuff that we’ve received was very positive, littered with suggestions and changes that we’ve known of for a while – general difficulty, no checkpointing, and the objective arrows implementation being the main culprits. But we’re very happy with how it turned out and we’ve certainly learnt a lot.

You can still play and/or download the game on the Nuclear Storm page. We’ve got no plans to take it down, and we’re always happy to receive feedback or bugs reports via the link on the same page. Just don’t expect us to implement any changes unless it’s a bug and we’ve got a good idea how to fix it. Sorry!

So, what’s next?

We’ve had a busy few months outside the world of making games, so we’ve made slow progress with the plans for the next project, but it’s starting to take shape now. Obviously we’re not planning on sharing what it is just yet, but mainly because we haven’t got far enough to describe it without it mentioning something that’s likely to change dramatically or just disappear. Also, we’re still arguing about whether or not it’s going to be in 4D and use motion controls*.

What we are planning on doing right now is try and get a bit more of an online presence for anyone who is interested in what we’re doing. and we are definitely planning on updating more regularly on this blog, with a better looking website at some point. There will be tweets and Facebook posts inbetween all that, though, if that’s your sort of thing.

Luckily, if that is your sort of thing, you can find us on Twitter at the @RelevantDev account. We’re all on Twitter individually, too, if you don’t mind completely irrelevant updates or complete silence, depending on who you follow. We’ve now got Facebook and Google+ pages, too. Plus, there’s still the mailing list if you prefer your updates rare and via email.

* It definitely won’t use motion controls. We’ll likely patch in 4D support sometime in the distant future.

Until next time…

So, after a busy few months we’re eager to get back into the swing of things and start making another game, which is nice. Fresh enthusiasm and new ideas should hopefully inspire us into keeping the site updated with what we’re up to and how we’ve achieved certain elements of the game, etc., which is hopefully interesting to you, the lovely reader.

So, that’s it for now. We’ll (almost definitely) be back soon!

Media 03 – GUI & Models

Nearing the finish line

As the project draws to a close, we’ve finally decided to tackle the GUI. Were now at a stage that we’re fairly happy with and just in the process of implementing it through out the game.

I’ve also been working on the Menu scene a little more. I managed to get the lighting a little more interesting and tweaked the the GUI buttons to better reflect the tone of the game.

Finally, I’ve added a few WIP renders of the Dakota Helicopter and the 3 turrets that you’ll encounter in the game.

You can find the most recent public build here)

Media 02: More screenshots

Screenshots: Part 2

We’ve added a couple of visual features over the last week or so which I think deserve another batch of screenshots.
Firstly we’ve added a targeting reticule (screenshot 1) that appears over a target when your locked on. This helps the player distinguish which enemy they’re firing at when multiple enemies are present on screen.
Secondly we’ve added spot light (screenshot 3) which has 3 functions. It helps the player orientate themselves, it provides a rough targeting area (Where the player missiles will hit the ground) and it also helps to judge terrain height.

The lovely chaps over at AlphaBetaGamer posted a few GIF’s of the game. (They’re a couple of builds out of date now, but you can find the most recent build here),

 

Media 01 – Screenshots

Screenshots:

As we near the end of this prototype project, I think I speak for us all that we’ve learnt a great deal.  We’re now in Beta and we recently invited everyone to play the game in more or less its completed form. (Save for some environment details and a ‘hints’ system.)

Over the last nine months or so, we’ve created a bunch of logos, models, textures and materials. The game looks half decent now and so in this first of a series of posts,  I’d like to share some screenshots of the environment. Later on I want to share a series of breakdowns of the assets used in creating the look and feel of Nuclear Storm.

Reaching a milestone: Part 2

Hello again. It’s been a quiet around here again, hasn’t it? Sorry about that. However, I do have two bits of news to share that I hope will make up for it…

News!

Firstly, our game has a name! A proper one, that is. We’ve been referring to it by it’s Unity project name since, well, we first created it as a Unity project, so we decided to have a session of sitting around and throwing words and names about and seeing what stuck. Thankfully, we found one we all agreed on and that is…

*drum roll*

Nuclear Storm!

There are a few reasons why that made sense, and some of those are due to the world the game takes place in, as well as the fact that it sounds more exciting than the project name. So there you go!

More news!

The other news is that we’re getting ready to send Nuclear Storm out into the world of testing. Exciting! Terrifying!

If you’ve signed up at the mailing list page (it’s still here) then you can expect an email at some point this week (I hope) with a little more info and the current state of the game, as well as some details of how you can report bugs and feedback so we can improve things.

It’s actually a little bit scary now that we’re this close, but I’m really looking forward to getting some feedback and trying to make a better game. So, if you’ve not done it yet, go to the mailing list and sign up!

Well, that’s it for now. Thanks!

Reaching a milestone

It’s been a frustrating few weeks for us, trying to find some time to keep developing, but then we know that this is the difficult part of working in your spare time. We’ve made some progress, and in some key areas, but it’s not been as quick as we’d like.

We’re at a stage now where some of the larger tasks need completing – the sort of tasks that break the game until they’re done, or at the very least can’t be implemented until they’re finished, but that’s where the good news comes in – we’ve finally reached alpha!

Alpha!

Our first post here mentioned that we’d reached pre-alpha, which basically means we have enough of the game core in to be able to play it. Being in alpha basically means that the game core is finished – you can now start playing from the main menu, complete your objectives (or die trying!), and then decide what you want to do next – quit or play again. There is still a lot of content missing, but the gameplay elements are functioning.

The biggest challenge lately has come from killing the player. It shouldn’t really be a surprise that when you try to remove the one thing that most of the game is focused on, things tend to break, so we had to be sensible – and very careful – when it came to implementing this, but we’re happy that you can no longer fly full force into the canyon walls and bounce off. I’m not quite so happy about doing it by accident while trying to test something else!

What next?

The plan now involves fixing the many bugs we know about, balancing the player and enemy health systems with all the weapons, adding in all the extra content that makes it look like a game, like sound and particle effects, and designing the actual level layout and balancing that. Oh, and fixing all the other bugs that we haven’t found yet. Easy!

Still, despite the amount of work that still needs doing, it’s a huge milestone to get the game where it is and we’re really proud of it. I’ve played through it a few times now and it’s good fun considering how rough around the edges some elements are, and how terrible I am at it at the moment!

More updates soon! Hopefully.

Don’t forget that we’ve set up a page for mailing list sign-ups here. Emails will be very rare, but we’ll almost certainly be asking for testers via this list if you’re interested in that sort of thing.

Adding some realism to player movement

We’ve been quite happy with the handling of the helicopter you control for quite a while now, but it’s spent most of the time just gliding through the air without any real animation. I had a go at fixing this a while ago using two different methods: One of these methods failed spectacularly, the other in the most mundane way possible.

Take one

The original method was to rotate the the chopper along one of its axes based on the direction it was headed in and it seemed to make perfect sense before I tried it. Thankfully the reason it failed made itself apparent really quickly:

The player is moved using Unity’s physics system. Obviously we haven’t tried to simulate the physics of a real chopper, but pushing the player with forces meant we could capture some of the characteristics of a chopper and get better reactions on collisions. The input system basically shoves the player forward while they’re pressing forward, sideways when they press sideways, etc, while momentum handles some of the expected handling characteristics. The problem with rotating the player was that when we pitched the chopper forwards, the forwards direction of the force was also adjusted, making the player perform a rather dramatic nosedive whenever they moved forwards. It looked amazing and I definitely had a good laugh for the 2 minutes it was in place, but that really wasn’t going to work.

Take two

The other method was a bit hopeful, really: I’d used Mecanim (Unity’s animation system) for the Stealth tutorial that Unity provides, but I wasn’t really all that sure of how to use it effectively. It also meant that I had to create a few different animation states for the player using Blender (the 3D modelling tool we use for the game’s assets) which I wasn’t all that comfortable doing. This combination of uncertain and uncomfortable meant that the end result was about  two hours of setup work and a chopper that did…well, nothing. Worse than nothing, really – it broke the rotor animations that were working fine before. Oops. I’ll come back to this later then…

Some time later…

Fast forward a couple of months and I knew that a reworking of the first method was the only real way that this was going to work. Thankfully, working on other parts of the game had made me realise that there was a really simple solution to get it working without meeting a violent end as soon as you moved forward – a container object.

I won’t go into detail about why that particular solution works, but it essentially means that the player gets pushed forward in the same direction, while a separate object rotates the physical representation of the player, making it look like a chopper should without actually simulating all the complicated forces and effects on a chopper in flight.

Amazingly, I got it working without any major issues within an hour and Miles and Dan gave their approval. A brief testing session later, Miles rather sensibly pointed out that the animation should be based on player input, not their current velocity, and after some quick changes we were left with the following:

Obviously everything is still being worked on. The animations have prompted a few conversions about the player speed and various other things that we still need to tweak and decide on, but after spending months looking at a chopper gliding through the air during testing, we’re all rather pleased with it!

Other updates

We had a really productive meeting last week going through Miles’ reworking of some old code and Dan’s first sketch of the level layout and his plans for adding more detail.

Since then, Miles has reworked more of the code with a view to us finishing the job the next time we meet up, Dan has been adding more details to the level and tweaked some of the existing models, and I’ve added some code so we can change some of the environmental effects when in certain areas of the map.

Up next: reworking the badly (oh so badly) broken aiming system, adding in another weapon for the player (hopefully), and more level design work.

We’ve also set up a page for mailing list sign-ups here. We’ll obviously not use your email address for anything else and emails will likely be (very) rare, so you’ll not get spammed. We’ll almost certainly be asking for testers via this list, so you know what to do if you’re interested!

Terrain 101

When asked to join the team, I’d never actually heard of Unity3D. I had some experience using the Source engine (Created for Half-Life 2 and used for the Left 4 Dead and Portal games) and Blender (A free, open-source 3D modelling application), so I at least had a good grasp of environment design and modeling.

So I poked around in Unity for a few weeks and, after creating the ‘Dakota’ model –  that’s the helicopter you fly in the game –  I decided to fall back on my Blender knowledge to tackle the terrain. And so, based on a sketch of the environment, I blocked out the terrain, generated a heightmap* and imported the terrain to Unity. Turns out this was a mistake!

* A heightmap is basically a black and white image used to convey height, with black as the lowest point and white as the highest.

Let’s try again…

Having rushed into the process  a bit enthusiastically and not really gotten the results we wanted, it seemed like a good idea to be a little more logical about the whole thing. And so, whilst walking the dog, I drafted up a “Terrain Action Plan” for my own benefit. I’ve added most of it with my notes below:

1. Create height map in Blender with following properties;

  • Dimensions 2048 + 256 units on either side

When using the Unity physics engine it’s generally advised to use 1 ‘unit’ as 1 metre, so at 2048×2048, our prototype map is roughly 2km x 2km. On the heightmap image, a single pixel also represents 1m.

The 256 extra units were later removed – the idea was to have 256 units all the way around the map to sculpt into mountains or impassable terrain to stop the player leaving the map without using invisible walls.

  • Create bounding boxes

These bounding boxes represent the maximum geometry height to avoid blocking the camera’s line of sight to the player, and the maximum height the player can fly. They also gave me a good sense of the map limits and where the ‘barriers’ could be added.

  • Sculpt Peaks up to 100 units high
  • Majority of terrain to be below 30 units as to allow Dakota to pass over.

The peaks were added to a height that we wanted to look impassable, so they were nice and high.

The last point was added prior to the altitude controller code we decided to include. You can’t adjust the height you fly at in the game as it’d be way too many buttons, but the game controls it for you.

  • Plenty of flat areas.
  • Camera Settings: orthographic, render size = 4097×4097 px, file = tiff 16bit

The flat areas were obviously there as the ‘play area.’ The idea was the edit this in more detail later when we have a better idea of how the level would play out.

The camera is set to orthographic to remove any perspective effects and create the image of the terrain in 2D. I created the heightmap image at 4097 x 4097px for additional detail, so each pixel now represented 0.5m squared. The image was saved as a .tiff 16bit image, which allows for a smooth range of grey scale, and so a smooth terrain.

2. Additional Detail in image editing;

  • Set resolution to 2049px

At this point we’d tested the 4097 x 4097px heightmap in Unity and the resolution was way too high. Oddly this also caused all sorts of lighting problems and jagged terrain, so we quartered the image size and everything ran silky smooth without losing any detail that we needed.

There’s a technical reason for setting it to 2049px, we weren’t just being awkward!

  • Add pock marks and craters
  • Flip whole image horizontally

This was to add some extra detail to the flat areas of the terrain and make it more interesting than a completely flat area. The image is flipped due to the way Unity imports the heightmaps – we’re not really sure why this happens!

  • Save as 16-bit RAW file

RAW is the file format that Unity (and lots of other tools) use for heightmap files.

3. Export RAW to Unity;

  • Create new terrain; Terrain size 2560x2560x100.
  • Terrain heightmap resolution needs to match .RAW file resolution.
  • Apply ‘terrain_bump’ material in terrain properties
  • Apply textures as normal

These are mainly related to the settings we used in Unity to import the terrain and get it to the right scale, etc.

More details!

Unity has a great terrain editing tool for adding small details (or creating a rough terrain quickly) that I used for tweaking the terrain at this point. It’s basically a set of paint brushes like Photoshop that lets you ‘paint’ height changes onto the terrain.

If you paint small changes with certain brushes this gives an uneven look to the terrain, like you’d expect to see in real life. It’s also much easier to edit certain areas from the heightmap without having to go through all these complicated steps again.

Surprisingly this helped a lot with the creation of the terrain. There were a few tweaks to make such as reducing the dimensions of the RAW file, but on the whole the end result is a step in the right direction.

blendersm

A little more info

Here we go, then: update #2.

I suppose the two screenshots at the end of the last post gave some indication of what kind of game we’re working on, but I thought it’d be worth going into some more depth about what we’re trying to achieve before we consider it “finished”.

2013-10-03 14-22-14-80

The game

You may have noticed that it has a slight resemblance to a certain early-90’s Mega Drive game. Well, there’s certainly an influence there, but aside from the obvious core features I don’t really know how similar they are, to be honest. I do remember playing early-90’s Mega Drive game but it’s only a vague recollection, not a defining moment in my gaming life or anything like that, so it’s more likely a starting point than an unofficial remake or tribute.

That said, even if that was the case, the plan has always been to build a prototype, so while we do have a list of potentially exciting features hidden away in our Google docs, undoubtedly creeping into other games, our scope is pretty tiny, really.

So, what is the plan?

Basically, our aim is to implement one mission in a decent-sized level. The mission will consist of several objectives in various places across the map, with lots of “areas of interest” in-between them for people who like to wander off and explore. Beyond the initial objectives, designed to let you get to grips with the controls, players are free to complete them in whatever order they like.

We plan on adding some sort of map or guidance system to help you find your way around, but exactly how we implement this hasn’t been discussed in a huge amount of detail yet. We also have a vague background narrative which helps when it comes to designing models and the level in general, but it’s not likely that we’ll explore it much while it stays a prototype.

Due to the size of the game and the fact that it’s never likely to be polished to the highest level we’re capable of (we still don’t even know what that is!), we’ll be making it available for free on this here website when it is eventually done. I wouldn’t even dare guess as to when that’ll be, though. This year? Maybe.

Oh, and it’ll be on PC and Mac, too.

Quick update

Since my post on Friday, Dan has knocked up several new models environmental models to decorate the map and generally make it look a little more like a real place – road sections, pylons, etc.

Miles started a fist fight with some of our older, clumsier code related to some of the objectives and didn’t come out of it entirely unscathed. We think we’re getting there, though.

I’ve been trying to improve the way the objectives work and making the while thing feel more like a real game by adding on-screen messages for players, listing the outstanding objectives, etc.

We’re considering setting up some sort of mailing list for bigger updates while keeping this as a development blog, so that might make an appearance soon. We’d like to get some other people testing it at some stage, too, so that will likely be posted here and sent to anyone interested, so let us know if you’d like to break it at some point!

Hello world!

Yes, hello!

So, we’ve been working on a prototype game for a few months now and after reading the development breakdown of the lovely Tom Francis‘ game, Gunpoint, I thought maybe it’d be worth posting some stuff here, on this website I set up ages ago and then left…

First thing’s first…

I suppose I should clarify who ‘we’ is, shouldn’t I? Well, I’m Ash (Hello!), and the other two team members are Miles and Dan. Since we all have full-time, paying jobs that aren’t making games and we’re new to this game development business, we don’t really have concrete roles, but Miles and I have been doing the coding while Dan does the vast majority of the artwork. We’ve all had a hand in the design of the prototype because, despite many, many years of playing games, we’ve never actually designed one before.

The plan

So, after a few months of Miles and I learning Objective-C (for no particular reason), we made the jump to Unity and asked Dan to join us. We poked and prodded at it for a while and made some good progress learning the ropes, before running out of steam a little when things started getting complicated. Then I suggested we make a plan to help focus us on the daunting prospect of making an actual game (prototype) and that’s what we’ve been doing for the last few months: we’ve created about 247,936 documents and spreadsheets on Google Drive (roughly), set ourselves tasks, and met up once a week (most of the time) to chat and see how things are going, and it seems to be working. It’s starting to actually look like a game.

Where we are now

Right now – as of yesterday, in fact – we’re in very early alpha (that’s what we’re calling it anyway) – the game has lots of unfinished stuff and most of the models are untextured, etc., but it has objectives and it’s technically possibly to complete it from start to finish. I was quite excited about this, to be honest.

There’s a subtle hint about some of the gameplay there…

So that’s a very brief update of the last few months. With any luck I’ll remember to post here every now and then about what’s happened, maybe even include some screenshots and/or videos of where things are and how it’s starting to take shape. And on that note…

Look at it!

Here are a couple of screenshots from a few weeks ago:

2013-10-03 14-21-19-092013-10-03 14-22-05-52