Tag Archives: Asteroid Outpost

Asteroid Outpost Update 2012-07-13

Life has been rather busy recently. Between the Calgary Stampede, Close Quarters, a flat tire, and making invisible improvement after invisible improvement to the back-end, it has been a little tricky to find both time and motivation on the same day. I did have a few spurts of time + motivation, and have been moving ever so slowly toward an ES design (Entity-System). Since I didn’t start with one, or know about their existence when I started, the conversion process is a little extensive, and very invisible. When I’m done, I will have a scripting language in place for all of my entity-specific code, components that are 100% data, and systems that will work directly with the components. This should allow for two major things: rapid development of new entities, and modablility. Modability being a side-effect, I really just want the rapid development. Oh the dream.

Asteroid Outpost Update 2012-06-12

Over the weekend, I integrated Awesomium into Asteroid Outpost, and it looks pretty sweet, but not only that, it’s easy to make changes to. Instead of posting stale screenshots, how about you check out the screens for yourself! They’re just html after all. Here’s a link to my Awesomium Screens for AO. They will only work properly in Firefox, Chrome, and probably Safari. IE will partially work, but all of the cool CSS3 will be stunted and cause the page to look lame. Also note that the background image in this sample is only 1920×1080, so if your screen is gigantic (like mine), please reduce the size of your browser window for your viewing pleasure. Some things you may not think of trying:

  • Use the arrow keys, and press enter to navigate the menus
  • Press ESC once in the game* to bring up the in-game menu, press again to dismiss
  • None of the text is selectable. This is really annoying for websites, don’t ever do this, but this isn’t a website, and selecting text in a game is weird

If you hadn’t noticed, the multiplayer menu isn’t completely working yet. That will come. I want to get a few more features working first, like tooltips and maybe a console? I kinda want to make an html console, especially after looking at Wolfire’s blog post about doing awesome CSS3 transitions for text entry. Like, is that sexy or what? In case you were wondering, reading Wolfire’s blog is what inspired me to use Awesomium.

Also, MindWorX and I have created an AwesomiumXNA component that you can easily add to your own XNA project. Here’s the project on Bitbucket.

  • not really in the game

New Screens on the Way

Diablo 3 has been consuming me! Good news though, I wasn’t playing D3 the whole time, I did manage to scrape together a few minutes here and there to work on some new web-based screens for Asteroid Outpost. I should have something to show soon, and be prepared for some major differences. The new interface should be way easier for people (including you!) to edit, and will allow me to make some much-needed UI changes on a whim: tool tips, icons, progress bars everywhere, a console, mutiplayer chat, some proper controls for the server settings, need I go on? The first version I’m planning won’t be pretty, and will only replicate most of the functionality for the singleplayer portion of the game; multiplayer menus, the radar, and “pretty” will have to come later.

You might be thinking: “Won’t a web UI feel like the web”? Thanks for asking, and nope! I’ve been trying hard to make it feel like a native UI, and it’s surprisingly easy. Add some JavaScript keyboard support, a dash of CSS3, a few special keywords, and you’d be hard-pressed to tell it was html.

Asteroid Outpost alpha4 Release

For those who want to try out Asteroid Outpost, I have uploaded a new Asteroid Outpost binary to Bitbucket and SourceForge. Some of the changes are:

  • Icy Planet in the background and nicer looking stars
  • Health bars with floating damage indicators
  • Rewritten power grid with lots of bug fixes (Why the rewrite? The old one was built right into the entities, this one is its own separate object and much easier to handle because of it)
  • Better networking code and significantly fewer network glitches
  • Starting a component-based system
  • Lots of bug fixes

Now that I’m using Mercurial, I can’t be lazy and just use SVN’s revision number to tag the release, so I’m starting the count at 4 because it looks like this is my 4th public release since… wow… since September 2010. Dare I see what AO looked like back then? Yeah… let’s do it. LOL, wow! Awesome. That makes me feel awesome inside.

Asteroid Outpost Update 2012-05-04

I have just finished fixing up how a network game is initialized, at least for now. First the scenario is initialized, this creates the asteroids, force(s), local controller for the server, power grid(s), and an AI controller (if applicable). Next, the network class gets a chance to do its thing. For each client, it serializes and sends the game state that was created in the scenario, then asks the client to create its own controller and start the game. Sounds easy right? Well, it is now.

A bug was also introduced, or at least noticed during this latest round of changes. It’s a small graphical glitch, I think. On the client, my structures aren’t completing construction properly. So far, this is only making the power lines between two power nodes show up in the “constructing” colour:

2012-05-04ConstructionBug

Power Grid Demonstration

I have compiled a short video demo of how the power grid lights up the shortest path from consumer to producer. Check it out (720p and up is recommended):

Also visible in the demo is my ice planet, beacon (green thing above the planet), and some stuff related to the tutorial scenario I am working on.

Asteroid Outpost Update 2012-04-23

Over the weekend I decided to rename the Actor class to Controller, because that’s what it really is. While doing that, I found some hideous code smell wafting from the server start/scenario start methods. There was a lot of duplicate code, and quite frankly, I’m surprised that a) It actually worked b) I didn’t notice this sooner. Ah the joys of working with a growing codebase. The Scenario classes are gaining some more responsibilities now, including setting up the players with their initial base. It’s a good step forward, although still very invisible :(

Asteroid Outpost Update 2012-04-15

It’s been a while since my last update, and not a whole lot has changed. I’m focusing on smoothing out the multiplayer experience. If you’ve had a chance to try it, you’ve probably noticed many issues including the spaceship jumping around on the client. The core problem is that I’m treating the client like a dumb terminal, and am not doing enough (read: any) simulation on the client to make a smooth experience. Until now, the server was running “the game”, and telling the client what’s going on. Whenever the client wanted to do something, it needed to ask the server to do it and only then would the server tell the client to do it. Ping time could cause some real grief with that system. Most of the issues were quite straight forward to fix, I just removed the if(isServer) checks around many of the “server only” code blocks to let the client do some simulation of the server’s state. This does however, give rise to a slightly new way of thinking about what the information that my network packets should transfer. Instead of transferring raw data related to state changes, I should convey commands and trust the client to do a reasonable simulation of that command. I’m sure there will have to be a combination of the two, so that when commands are sent, it also sends some of the raw state data involved with the command, like when an AI ship picks a target, it could be useful to also send where the ship was when it picked the target so that the client can adjust its world view. The game will still run on the server like before, but now the client will make certain assumptions about what the server is doing. My hope is that in a hack-free environment, the client will be right almost all of the time. There’s no reason the client shouldn’t be right unless an other player interferes and causes the client’s view of the world to be altered, and there’s very little that could cause that. I’m going through and figuring out all of the cases where the client could be wrong and making sure that the server sends an appropriate message to correct the situation.

Notice that I mention a “hack-free environment”. In a situation where the client is hacking, those changes will be client-side only and they will not affect the server, or the other players. At least for basic hacks. I’m sure if someone wanted to, they could figure out a way to trick the server… somehow, but that’s not work concerning myself with.

Until recently, my game has also had no concept of a unified “game time” between the client and server. So actions would happen when the packet is received, not when it was sent. I always knew I needed to keep track of the “game time”, but until recently there was no real need to spend time on it. No pun intended. I’m going to be working toward this in the coming weeks, and hopefully get mutiplayer to work beautifully. That is the dream. Once multiplayer is working really well, there are a few other things that I’ve been wanting to do. I want a missile launcher, and some particles to go with it. I have an old particle system I wrote for another game that I may pull out of its grave, but it looks awfully simplistic. Maybe it will provide a good starting place though.