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.
I was playing an early alpha of a friend’s strategy game and noticed that the animation of the character’s feet wasn’t in sync with the ground below it. This got me thinking that I could add a feature into my sprite maker where you could preview what your character would look like at various animation speeds in relation to ground speeds so that you could more easily sync the two up. I still need to add the registration points to the editor too, my lasers are going to need those really soon.
Somewhere down the line, I would like little rotating turrets on my spaceships and battle-stars. With my current isometric point of view and 2D sprites, this could prove challenging. Just thinking out loud: I would need to use an orthographic projection of my models (but maybe not), then draw the sprites in a few parts to handle special cases like where a turret is partially obstructed by a tall part of the structure it’s attached to. If I handle cases where a turret can be obstructed by the structure it’s attached to, I’d want to handle that (somehow) in the sprite maker because the purpose of the sprite maker is to abstract these sorts of details from the programmer and let the artist handle all of this artsy stuff.
Not that I used to get a lot of search referrals, but I have not had a single search referral since I upgraded my website. I’m pretty sure I broke something. That ought to teach me to upgrade my website. Anyone had this problem, or know how to fix it? All of the old URLs no longer work, and you’ll get a friendly 404 if you try. I’m certain that has something to do with it.
Life has been keeping me rather busy recently, so I haven’t had time to develop AO any further :(. I’m hoping to get a few hours in this week though, see if I can make a quick video of the power pulsing and finish up with the network cleanup. The networking has a few complexities that need some thought, like: Will updating a ship’s location, velocity, and target, only when the target changes be sufficient enough to make a smooth client-side simulation? or will more updates be required? My instinct tells me that this should work just fine, as long as the game knows when this target change occurred and how to bring the ship into the present (keeping in mind that all network packets come from the past). There are some other organizational issues around how to send the initial state of the game to the client and how scenarios tie in to all of this, but I’ll elaborate on that in an other post.
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.
I mentioned in a previous post that I would be giving Mercurial another chance, because the first time didn’t go so well. The only real driving factors for me are the massive number of ads on SourceForge, and at some point down the road, I want to close Asteroid Outpost’s source. Having a quick look around, I found Bitbucket. They offer free, open and closed source repositories for small project teams. So far, round 2 is proving to be much smoother than my first attempt, maybe TortoiseHg is better than it was? Or maybe I’ve grown? Whatever the case may be, Merc and I are getting along now.
There is one nice feature that I will certainly be using: Guess Renames. Renaming in SVN was a pain in the ass. First you’d rename or move the file(s) in Visual Studio, then go to windows explorer, undo the rename manually, then re-rename the files one by one using SVN. With Merc, I can simply rename the files in Visual Studio then get Merc to guess the renames for me. Problem solved.
All of my Asteroid Outpost related projects that used to be on SourceForge have been moved to Bitbucket already, and I’m sure I’ll be moving more projects over when I get the chance. I have already added a few new projects to Bitbucket, here’s my profile link.
Work has begun on a Battlefield 3 Extra Stats page (powered by bf3stats.com). BF3 already has some amazing statistics on your playing, but I feel it lacks the ability to compare multiple soldiers. There are a couple things I would like to get out of this page:
To help me visualize exactly what I wanted before I wrote too much code, I made up a Google Docs Spreadsheet with me and some of my playing buddies to visualize the stats. The highlighted cells on the first sheet indicate weapons that I deemed underused by the player, and in the “Accuracy Slim” sheet the highlighted rows try to indicate which weapons may be more accurate than others, based on empirical evidence. The PHP for this page is open-source on Bitbucket, surprise!
I seem to be in an open-source mood today, so maybe I’ll upload some more of my older projects, like my Winamp G15 plugin. Speaking of my G15 keyboard, it is no more, it ceases to be, it no longer functions. What a sad day that was. On the plus side, I got a new, mechanical keyboard! On the down side, the new keyboard was a little annoying because it didn’t have dedicated media keys AND it was defective. The period key would double-bounce, making it really annoying to program with. On the plus side, they let me return it for a different new mechanical keyboard! And it’s awesome. I only have one problem with my new keyboard: Not all of the keys are mechanical, and I have to use the non-mechanical keys all the time while I’m programming. They can feel rather stiff and they don’t travel quite as far as the mechanical ones do. I would have paid more for 100% mechanical, but I suppose I can’t get everything. I’m still happy.
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.