Today I was working on the GUI system for Stick Soldiers 3. Like the one in Novarunner, it's based around the IMGUI principle and some previous code I had written not so long ago.
The big benefit of having IMGUI is, of course, reduced infrastructure. You're effectively adopting a more functional approach to GUI development than one with side effects (although side effects certainly do crop up and are a pain to resolve occasionally).
SimmerD is using IMGUI for his game, and check out the mind-boggling complexity of his editor and other stuff. Believe me: the framework code behind that is dead stupid simple. Oops, I guess I leaked his secret.
If you haven't looked at IMGUI, I recommend you do. It greatly simplifies the amount of work you have to do, and makes for some relatively simple controls and management code. Remember, we're making games, not full scale applications. We don't need a complex messaging system like the one in X11, Aqua or Windows. I'd be surprised if stuff like Flash and other "light" toolkits of the sort aren't doing a similar thing under the hood -- this just seems too good to be keeping to games alone.
What's left for this week? Well, probably some updates on Novarunner, but they'll mostly be backend work. I'm definitely going to try for getting weapons firing, but don't expect an inventory interface to go with it. I'll probably just bolt the weapons onto the ship for the first run-through.
It occurs to me suddenly that EVE Online seems to get the interface and a lot of the feel of my game right, which makes me wonder why I originally patterned my game controls after the X series, something which is almost completely inaccessible by ordinary humans.
I will have to make some modifications to mouse control of the ship, for sure, and might even have to put some normal GUI objects up in the HUD.
Anyway, today I added Message Beacons. These are a special class of actors which contain a special Brain (AI module) that responds to a ship coming nearby, and bombards it with helpful information about how to deal with life. Incidentally, to implement this I ended up implementing an onShipNearby method in the Brain which responds to ships coming close to each other, which will be necessary to implement "actual" ship AI eventually. This iterative method really does work!
Also, ships now have a teensy bit of inertia, which helps make them feel like they're large objects moving through space (albeit very friction-tastic space).
Here's a screenshot of me interacting with a message beacon.
Miscellaneous bug-fixes and some back-end stuff. I'm getting pretty close to firing weapons, if not equipping them yet. It's taking me a long time to make UI screens but I can't really justify writing a code-generator tool for them, since there's so few UI screens in the game. It's a conundrum.
I've also been making tweaks to the HUD: stuff like targeting working properly, the radar becoming more useful and a crosshair added. I'm now working on ammo and energy indicators, and figuring out if the ship menu is really where I want to go with this.
One other thing I want to do is revamp my websites; my installation of Pivot is junk and it can barely format articles right. Writing tonight's mini-entry took me almost 15 minutes to reformat just so it doesn't look horrible when you click (more)... and it still looks really bad. Grahh!
I've been writing the ShipStats class, which handles most of your RPG-ish stuff and your inventory and cash supply. Obviously this is damned important to save and load!
This is but one of the many pieces I have to implement before I can get weapons to work properly.
More fiddling about with engine gubbins; I'm working on a better VBO and some other internal bits that will eventually propagate up to Propane Injector (better context management, UUID, scene graph).
I'd do some more stuff on Novarunner, but to be honest I think I need to pare down the tasks a bit more. I'll get the main menu hooked up tonight and then get started on inventory and buy/sell instead of weapons.
Slow. It doesn't help that those bastards at Realtime Worlds came out with two new Crackdown expansions. Gah!
I spent today playing videogames, driving between various places for errands, and evaluating what needs to get done on Novarunner.
I've started using my bugtracker as a "to do" list of sorts; I picked this up from work where they use Trac to write down their sprint plans, which is a good idea.
The big plus now is that I can see what I have to do and check it off as I go, which makes me feel better about my progress of development. Right now I have 23 tasks to complete, but these should get banged out pretty quick as development proceeds.
Tomorrow: I want to get weapons firing. That takes a lot of work, but I think I can make a good sized dent in it. I'll be ahead of the curve if I can take a screenshot of weapons firing.
So I was bitten by the bug to work on Stick Soldiers 3 more, so I put Novarunner aside for the weekend and banged out some animated sprite support, like I've been promising the guys for months.
It's hard to see, but yeah, it's animating at a variable rate. Shiny.
It's given me practice with sprite-sheet support, which might make it into PI.
Speaking of PI, I'm thinking of adding Vista game explorer functionality (so you can check parental ratings and get that Games for Windows certification for your PI game). This isn't really important to me, so it's way in the back of my list of things to do. Is this important enough to anyone else that I should put aside rejigging the sprite and VBO systems for it?
Well, I finally decided to start being a better programmer and adding more targets to my Xcode projects. So now I have some simple unit tests running on my gameplay code, which should help reduce the amount of serialization/deserialization bugs I encounter in my daily life.
Right now I'm working on cleaning up the backend code and trying to cut a cleaner path; I had left vestigal code stubs kicking around from tangents I had been going off on and abandoned, so cleaning up the code and making it have a simpler critical path to accomplish things will fix a lot of the problems. Once that's done, enough of the 'game' gubbins will be installed that I'll be able to give you guys a few screenshots of flying around, targeting ships and deploying weapons.
Other stuff I'm working on: I'm going through my bug list for all of my previous projects and patching up Propane Injector. I'll have to make an official v1.0 launch of that damned thing one of these days, which means I need a preview game that isn't the driving one. I'll work something out.
I'm also trying to resist getting the new Crackdown downloadable content.
I was getting irritated by the radar's positioning and other stuff, so I did a bit of tweaking to make a nice looking HUD that'll show your health and whatnot.
Here it is:
Working on the front-end menu too, but that looks like ass. More later.
When I come back to this HUD I want to have "curvy" health bars. I'll have to figure out how to do that, which means I'll have to get my old protractor and geometry books out again.
I got enough done in the backend to be happy for now while I implement the most kickass part of the game: weapons.
While the system won't be as flexible as the one that shipped with Glow (or the one that future games will use), it is pretty nice. I'm thinking of three main types of weapons:
Projectile Weapons -- These are traditional guns. Don't ask how they work in hard vacuum, they just do. Stuff like high-powered machine guns, ship-to-ship shotguns and missile weapons fit in here. Damage is based upon your ship's Weapons statistic (increased by buying better Targeting Computer upgrades). Ammunition is limited by your active cargo space -- you can carry 1000 rounds of 50cal ammunition per tonne of cargo room, but this reduces the amount of stuff you can carry.
Energy Weapons -- These are weapons that are self-charging based on your ship's Recharge statistic (increased by buying better Power Plant upgrades). Damage is constant; only the fire rate is upgraded as your ship improves.
Turret Weapons -- These are weapons that target and fire upon enemies autonomously; it helps cut down some of the punishment of moving in 3D and allows you to do quick 'drive by' pecks on other ships' armour while travelling through a system. Their damage and firing rate is constant; there is no upgrade that affects turret weapon performance.
Now that I've talked about upgrades, I want to talk about the five main statistics of a ship in the game. Each ship chassis comes with a predefined value for all of these stats; by buying upgrades you add bonuses to these stats as appropriate.
Weapons -- How accurate and damaging you are with projectile weapons. Upgraded by targeting computer.
Recharge -- How fast your ship's energy supply recharges (used for energy weapons and afterburner kits). Upgraded by improving your ship's Power Plant.
Defense -- How much damage your ship can take. Upgraded by improving your ship's Shielding.
Agility -- How fast your ship can go and accelerate. Upgraded by improving your ship's main drive.
Jump -- How far you can jump, and how quickly you can jump again. Upgraded by improving your ship's jump drive.
The goal is to make the system relatively simple, so you can see the effect of an upgrade clearly, but also to give the player the ability to "stick with" a chassis they really like and upgrade it to the same level of power as an end-game chassis would provide.
In addition to these upgradable stats, a chassis has some other statistics attached to it:
Cargo Room -- How many tonnes of cargo your ship can carry.
Base Armour -- Once your shield is down, this affects how many hits the ship can take before it is destroyed.
EM Resistance -- This controls how susceptible your ship's computers are to the EM Attack maneuver. Ships hit with an EM burst are disabled for a variable amount of time.
Kit Slots -- The kit slot lets you add functionality to your ship (mining laser, EM Attack weapons, extra battery, afterburner). Only some forms of ship chassis have a kit slot.
So there's a little walkthrough over the game system. Obviously, there's some polishing and work ahead, but I'm confident this system works well. I'm thinking about how to make the user interface for purchasing and upgrading simple; I'd love to have an "Auto Buy" feature that would purchase and equip you with the best ship possible, but we'll see if I can make the time.
A big part of the game after this point will include making sure it plays well in 3D; I still find it a pain to navigate around the systems, although for some reason it feels much more pleasing with the Xbox360 game pad. I can't wait to get back to 2D gameplay!
I'm working on spawning tables; just like in AD&D you'll roll some dice to figure out what kind of ships will be present in the system you've just jumped into.
This is surprisingly hard -- I want to have some 'unique' ships which you'll only see very rarely, and for the rest of them a generic probability 'slope'. There's probably some kind of economic and political constraints on which ships show up where, but I'm ignoring those for now, and probably for the rest of the project's lifetime. Yes, we're in feature cull mode here.
I've changed the HUD around a teensy bit; I found a new font I liked more than my current HUD font.
Expect more as I get settled into my new job and stop playing Crackdown so goddamned much. That game is addictive in a way that I cannot quantify.
I'm working on some rather unsexy contents of Novarunner -- I just fixed the input system so it saves and loads keybindings properly, and will be going back to write the Actor save/load functionality so we can start to suspend the game state and populate new systems when you jump into them.
I've decided to abandon the deferred shading engine; it'd just take too much time to set up and debug, and I think I can get the game to look good enough without it. However, the big win here's gonna be in the gameplay; expect some new sexy GUI shots of the inside of the space station and the game's front end in less than a week.
My next game will probably be designed from the ground up to take better advantage of MRT, and the code that I was going to use for Novarunner is in PI now.