I just finished up a basic tutorial for the game. The tutorial is on rails right now, so if you veer off-course, it’s probably unforgiving. I’ll need to have some friends play test it while I watch, see where they get confused, whether they listen to the dialogs or accidentally dig themselves a grave. This tutorial is a good stepping stone for creating more complex scenarios, a lot of the bits and pieces are together and ready to go.
There’s still a lot of work to do on the game, sadly. At least it’s getting to a point where it’s playable. Once it’s playable (and hopefully enjoyable), I can start improving things one by one.
IndieDB has been kind enough to accept my game in to their database. You can watch my progress over there now too. I’m still not quite sure I’m going to put over there except duplicate blog entries & screens, but it should bring in a little traffic.
I’ve added some progress bars & icons for various changing values for the selected unit. It looks pretty good. Here’s a video of it. As usual, it’s best viewed at 720p and up
I’ve started to participate in #screenshotsaturday on twitter. The idea is that game developers like myself post a screenshot of their work on Saturdays. There’s a pretty cool website that collects all of the tweets and displays all of the Saturday screenshots, aptly named screenshotsaturday.com. Here’s my entry from last week where I added a power indicator for the solar station that will fade away at further viewing distances (click to enlarge):
And my entry for today, where I’ve started to create a missile launcher.
So yeah, I have finally added something to the game, can you beleive it? Nor can I. The missiles still don’t do any damage, they’ll just fly straight through the enemy ship and continue to accelerate into oblivion, but it’s a start.
As you can see, there’s still some more work required: certain datatypes don’t have an associated control (Vector2 and Color), the numeric sliders’ max-value isn’t fixed (it uses current value * 2), and modifications to the values go nowhere. Once I’m able to live-edit these values, this will become useful for debugging, balancing, and perhaps scenario editing.
Oh, and I may be turning into a Twit. I have started a twitter feed where I will try to regularly post about Asteroid Outpost.
My laser tower, spaceship, and beacon are back! I still haven’t thought about how I want to network this stuff, but that will come.
I just released alpha5 for Asteroid Outpost on Bitbucket, along with a changelog. It doesn’t feel like there’s a lot of new content really, but I have completely rewritten both the UI and Entities, so I’ll push this out now in hopes that my next release will be just around the corner. Now to get my laser tower working again…
My components are comprised of nearly 100% data with no methods. All of the manipulation of the data occurs in my systems. Some of you may be wondering why you need to separate the logic from the data. Doesn’t it just make work and reduce encapsulation? Well… not really. Once you start working with data-only components, you notice that components are able to encapsulate an idea without worrying about the world around them, and each system handles a particular aspect of the game, one to move things, one to build stuff, one to draw, etc. Even though the data and logic are in separate classes, everything has a very clear role: Components store stuff, Systems do stuff.
After following the development of Overgrowth, watching some pretty cool development videos about live-coding and live-editing, and cutting my teeth with some near-live-coding for my web-UI, I thought to myself: “I want that!”, and who doesn’t? Adding a way to view/modify the component data for the selected entity(s) on the fly wouldn’t actually be that hard, I’d just need some web-UI controls. Googling web controls quickly led me to jQueryUI which looks amazing compared with some of the other solutions available. Since I have data-only components, I can easily wrap them up in some JSON, pass a collection of them down to some jQuery that will display the values using jQueryUI controls. When the user changes something, data would travel the other way: jQuery would produce some JSON and pass that up to XNA where the changed data would overwrite the data in the component. So what if XNA were to consume JSON from the UI in the same way it would handle it from the network? Wow, everything just clicks. JSON wins.
Starting from the beginning: I’ll have partial JSON files for each entity type that will define which components to build and any default values for those components. At creation time, I will provide value overrides for real-time values like position and rotation. Since everything is data, that’s all that’s required to construct a new entity. The same JSON used to create the entities will be used to populate things like the selection info panel on the HUD, the entity viewer/editor discussed above, and to transfer new components, or changes to existing components across the network. Since it’s just data, it’s easy to visualize. I better get the last of the logic out of my components before anyone notices.
I can’t say that my game is a game again, but I’ve re-built the solar station, laser miner, and power node. I built the power node most recently, and it was eaaasy to do because I just slapped existing components together and gave it a name. The more components I build, the easier it’s going to be to build new entities from them. If things keep up, maybe I’ll be able to add something new before Christmas!
I’ve had to break almost everything in my game. So much so that it’s easier to list things that I didn’t break. Why did everything break? Because I have deleted my entire Entity class hierarchy. No more Asteroid class, SolarStation class, LaserMiner class, etc. All gone, and good riddance!
Instead, I have been converting piece after piece into data-driven components with systems that process lists of these components. There is a great 5-part blog series on this topic over at T-Machine. I’ll describe what I’ve done once I manage to get a little more working. So far, I only have a single asteroid that consists of nothing more than a few components. It may not sound like a lot, but it is a great start to a data-driven game.