Tag Archives: Asteroid Outpost

Six Scenarios and a Story

I need to create a small number of scenarios, get them linked together in a campaign, implement saving, add some sounds, and tie it all together with a story. Asteroid Outpost needs to make it to a cohesive state. I’ve built my vertical slice of gameplay, now it’s time to build horizontally. Five or six scenarios sounds about right to lay down my horizontal framework, and it will be long enough to have some fun. I’m aiming for ~10-20 minutes per scenario, which will result in 1-1.5 hours of gameplay awesomeness!

Scenarios and Explosions

It feels like relief to finally make some decent progress in Asteroid Outpost. I have been trying to focus on some of the larger and more visible items, starting with those ugly yellow power lines. This was followed up with improving the laser miner beam and making it extend from source to destination:


I was getting sick of the single style of AI in the game: “move forward until you’re within laser range, stop and shoot”, so I designed some new AI that uses a mix of missiles and lasers, and attempts to strafe. Each unit has 6 missiles and will only use laser beams as a last resort. Here’s a quick video example:

Scenarios are an important part of my game, so I sunk some time into the “Science Station” mission. In this scenario, scientists require more and more power to conduct an experiment. Without access to power, they will be unable to keep their experiment under control and the entire station will erupt spectacularly.


The explosion could look better, but I do like the fires. It’ll do for now. The scenario isn’t quite done yet, but the power requirements ramp up, and if they are not met, the science station explodes.

I have started to seriously think about how many scenarios I want the game to have, and how to link them together with a bit of a story. It would be great if I could create skeletons of these scenarios and connect everything for the first time. No, it would be incredible.

Recent Activities

Been a while since I’ve provided an update, so this will be a big one.

I won the first, and second ever GDSE Game Jams! For the theme “There can only be one”, I created Like Clockwork, a web-based bot programming game where you program your archer to navigate the battlefield, seek out, and destroy your enemies. The second jam had the theme “Time is Broken”, and I made (In &) Out of Time (works noticeably better in Chrome), a web-based adventure game. Both are open source and available on BitBucket here and here.

Asteroid Outpost could be coming along better. I created a nice dialog screen that shows who’s talking, added a new enemy spaceship that’s practically the same as the first, and started to make a new scenario. The new scenario demanded a giant super-structure, but since my game is 2D, I needed to split the new entity into 2 sprites so that it would properly draw over and under other entities in the scene. My entire engine is capable of handling two sprites for a single entity, except the current JSON format I’m using to load entity templates and send entity data to Awesomium. Now I either find a shortcut and move on, or take the time to fix my JSON. Shouldn’t be too bad, but it’s still one more thing I need to do. On the plus side, I was really happy with how quickly I was able to get a new bad guy int he game.

There have been a couple bugs in TeeVee that have been annoying me recently, and I’ve been thinking about completely redoing the UI for a few years, but haven’t made the time. This weekend, however, I finally took the plunge and created a brand new web-UI that replaces the UI portion of TeeVee. The scanning and updating from TheTVDB.com is still handled by TeeVee 1, but I plan to write two stand-alone apps that will do each of those tasks. I must say, TeeVee II is already looking way better. Not only is it significantly faster, but it’s also way sexier.

When I’m done with TeeVee II, I’m not sure if I want to release it open source or what. It’s valuable to the right audience, but my gut is telling me that the audience is too small, and none of my audience will be actively seeking out an XBMC replacement because they don’t know that it could be better. Let me be clear here, it may be better than XBMC for heavy TV viewers like myself. I tried XBMC for a few weeks, and my main annoyances with XBMC were: It’s very folder-based, lack of “favourite” shows, and it didn’t handle sleeping very well. TeeVee is file-based, so you can just download your TV to wherever you want, and TeeVee just picks it up and runs with it. It can save a lot of time if your library is large. You can select favourite shows in TeeVee, and those shows will appear above all of the other shows. I have 157 series in my database. How fun do you think it is to watch Vikings with XBMC? And the last point: if my laptop would go to sleep with XBMC running full-screen on my second “Monitor” (the TV), when I woke up the laptop, XBMC would be full-screen on the primary monitor (the laptop). Anyway, look for TeeVee II hitting the shelves near you!

Changing Hats

Gears are changing! Engine and tool design is phasing out (with a few major exceptions), and game design is in. It feels weird to say it, but during the last 4 years, I’ve had a very nebulous, hand-wavy idea of what I wanted in the end. Now that I’m at the point where I’m adding end-game content, I’m scrambling to figure out what I actually want in the game. What sorts of structures do I want, what kinds of weapons will be used, what kinds of upgrades do I want, what will the scenarios look like, do I want a story line, do I want voice acting, etc. So many questions. For now, I’ll add content bit by bit while finishing off the engine and tools. The content is going to take some play testing to see what works and what doesn’t, so it’s a good thing that it’s easy to add stuff and play around with it.

And for a quick status update: single-unit upgrades are physically working but not pretty, the solar station can now be upgraded to level 2, added auto-healing to all structures, constructing and upgrading units can now be cancelled, and worked some more on the context menus.

Closing the Source

After much thought, I have decided to close Asteroid Outpost’s source code. The current repository will remain as-is, and development will continue in a new, private repository. This saddens and excites me. It has been a pleasure to work in the public eye, being able to link directly to the source, and those proud moments when someone forks your solution. sigh. At least the excitement of what this means overwhelms my sadness. I’m starting to think that the game is at a point where most of the engine is in place, and I can start adding real content. This has been in the back of my head for a while, and it feels like I have been holding off on adding too much content to the open source version. If I ever want to sell the game, there’s got to be a cut-off point, otherwise nobody would buy the full game. That cut-off point is now. I can do this.

In other news, I have created a new Asteroid Outpost YouTube channel. I am unable to move all of my existing videos over from my personal account, but I will just re-upload them. All new content will be on the Asteroid Outpost channel, so subscribe if you want the latest videos.

Tooltips and JSON Entity Definitions

Tooltips have been on the brain, and I looked into implementing them, but realized I didn’t have anywhere to store the required data. Perfect excuse to move everything into JSON files. I’ve wanted to define my entities in JSON files for quite some time now, but I didn’t have a good reason to do it until now.

I have designed a layered JSON system where each layer overrides or adds values to the previous JSON. Currently, I have defined a base entity, followed by one definition for each entity type, then the most specific data is provided at run time when the entity is created. As I was writing this system, it occurred to me that I could write my unit upgrades in the same JSON and just apply it. So much is possible: reloading these JSON definitions on the fly, tying in the entity editor, and even networking. Everything is coming together, and I’m loving it. Now to actually implement what I set out to do: tooltips. That is my next step.

While implementing this JSON system, I came across a few issues. First was that fastJSON didn’t really want to deserialize to a generic placeholder object where I could apply the layers of JSON one after the other. I am glad I gave Json.NET a try, if for nothing else than the JObject and its collection initializer. It really helps to write C# code that looks like JSON instead of writing out a string that contains JSON data.

The second issue was a humorous fail cascade that caused the starting Solar Station to instantly disappear as the game started. You couldn’t select it, so it wasn’t a sprite issue. The creation code was executing, and all the right components were being created. You also couldn’t press Esc to get the in-game menu to pop up, odd. After some digging, I found out that it thought the game was over, which is normal if there’s no power producers in the game. Since it thought the game was over, it thought the in-game “game over” screen was already up and wouldn’t let me press Esc. Mystery one solved. So my solar station was being deleted, but why? With some more digging, the Armour was zero, so the game thought it ran out of health and deleted it automatically. The JSON showed a non-zero value for Armour, and it was loading, or at least it was being set. The setter for the Armour field had a bounds check that made sure it was 0 <= Armour <= TotalArmour. Oi! My TotalArmour was zero, at least for a brief moment while the Armour was being set. Sigh A setter designed to prevent invalid values can really throw a wrench. After loosening the setter’s rules, everything started working as intended.

Screenshot Blog

I saw an other game developer with a screenshot blog, and I thought it was great idea! So I made one for Asteroid Outpost. You can check out the album on Imgur. The screen shots go all the way back to 2009, man it’s been a while, but I haven’t worked on it full time either. You can see obvious gaps over the summer and winter months. Pretty fun to see how far I’ve come.