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 :(

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.

A small update today: I have made the power lines light up when they are in use. It looks pretty cool. Screenshots/video soon.

Free video editors are hard to come by, but I finally found VideoPad Video Editor that looks like it will do the job…. Just in time for a significant bug to reveal itself and halt the video production. I have been planning to do some more major refactoring of the project, so I’ll probably just do that and produce a video when it works again.

If you remember, I looked into Mercurial once before (last paragraph), and I didn’t really take to it. I’m toying with the idea of trying it again, largely after reading this tutorial by Joel Spolsky: hginit.com. I have started up a Bitbucket project for AO and imported all of my core code from SourceForge, so we’ll see how it goes.

I have been playing around with creating a planet recently, and after seeing the results in-game, I should have done this months ago. This is completely temporary and is very likely to change, but I needed to take some screenshots and share:

Main menu with ice planet

Multiplayer menu with ice planet

In-game with ice planet

Right now, the planet is stationary, but I hope to make it move around with the camera a little bit. I made the planet from scratch using a photograph and a powerful image editor, nice eh?

I finished up with a ProgressBar component last night, then hooked one into the construction progress and an other into the hit points. I am quite impressed by how easy components are to build and use for multiple purposes.

The background is in dire need of an upgrade, so I started to look for space backgrounds, but instead found myself looking at tutorials on how to make my very own space scenes. Am I an artist? We’ll find out.

I have been busy ripping chunks out of major classes in AO and stuffing the code into new components. The more components I pull out of existing classes, the smaller and simpler my code base feels, even thought it’s probably bigger. You should see how simple my Entity class is now, it’s wonderful. Each component handles its own data and all of the operators on that data; this increases the encapsulation and reduces the feeling of coupling, even though there wasn’t any real coupling going on.

There are a few new sounds in the game, all home-made by yours truly, and if I have to be honest, they aren’t great, they’re pretty awful. Is it better than nothing? Probably. At the very least, it allows me to get a solid audio framework set up for awesome sounds down the road.

I should start releasing videos of the game on a semi-regular schedule. Every month feels like a good goal for now. Expect a new alpha and video around the end of the month.

Components! I have been working on building a component-based system into AO, and it has been working great. When I was told about components and how flexible they could be, I thought they were really cool, but unnecessary. They are still mostly unnecessary, but they do make for some clean and easy to read code, and I love that about it. I also thought that I would start building a component-based system at the leaves and work my way toward the core of the Entity, but in fact, I found it to be really easy to start at the core and move outward. The Position and Size were the first things to get converted and it went over really smoothly. All of the position and size code was stripped right out of my Entity class and made it instantly easier to figure out what was going on in the Entity. I can’t wait to pull out more components.

Oh, and I also

• Completely re-wrote the power grid and fixed all of the power grid related bugs in the process.
• Added floating damage indicators
• Refactored the event system to get rid of all the delegates and start using Action<T> instead