I figured you would all like to know that I have my first iteration of zombie AI working. The zombie character just kind of mills around (because I've only implemented his idle state), but eventually I'll add some refinement to his shamblin' and allow him to viciously attack the player.
I'm also trying not to implement a lot of systems the same way as Glow, but it's kind of hard when you have something that works. Time will tell if I'm able to get the gameplay to the same level of fun.
The lectures for my games programming course started, and we've got professional developers giving us the entire course content over the course of this week. One of the things that I took out of their first day of presentation is the importance of metrics, so I went home and made a pointless FPS graph that does nothing really useful other than look super cool.
I'll probably have more soon. I think the sim concept is being rejected by my appointed team in favour of a Mario Kart-ish combat racer, but I'll try my hardest to steer (har har) it back into car bore territory.
As an attempt to pre-emptively destroy any hope of scheduling or reasonable expectations from this eventual project, I'm going to post my top wants out of this ahead of time:
Clean driving model -- Free of a lot of temporal aliasing and jitter, steering feels solid and tires feel grippy. I would also like to put in an entire transmission system, but I will probably have to hide it behind the scenes (autotragic) for keyboarders.
Upgradability -- I should be able to buy upgrades for my little car.
Multiple cars
Tile-based racetracks with an editor
Time will see how well this is pulled off, but I'm confident that I should at least be able to make a tiny buggy that will perform well.
If not, I can always use my nice new G25 with Live For Speed, or write my own sim. Wouldn't that be a terrifying concept? You'd get even fewer sexy screenshots and lots more boredom about differentials and gear ratios.
So I did a bit of work on Afterglow today. Big things that are on the docket:
The player getting injured notifies the game state. You get a nice red flash that isn't too distracting.
You can shoot NPCs. My poor twin assistant received many explosive bullets to the face from my modified HK-64 (now with more blowoff valve). You can see a video here. It's really short, but it gives a general idea of what's going on with a riff of Seabound in the background.
Player statistics affect gunplay. Something that's new for Afterglow is that I've changed the way your weapon skill affects your guns. In Glow, upping your weapon skill increased your accuracy as well as your maximum damage. This means that if you had something like all your points put into weapon skill, you could kill people with the worst guns in the game.
I've inverted this; in Afterglow, putting points into gun skill increases your minimum damage. In Afterglow, an HK-64 causes 15-25 damage for an untrained gun wielder; once you put a few levels into Weapons you will then cause 18-25 damage, and so on. I have to do some more playtesting before I figure out if this system sticks, but I like it for the realism even though it cuts into Glow's characteristic psychotic endgame. Trust me, though, there'll be plenty of opportunities to make pistols that cause 750 damage. You are talking to me after all.
For instance, notice how I now have explosive bullets. Is it possible you could find a Bonesaw and then modify it so it fires a wall of fast-moving high-explosive tipped bullets? No, that would be too crazy, right?
Hopefully your Christmas was good; if I had been earlier to the punch this wouldn't have been a 2009 entry, but I suppose you'll have to put up with my late entry.
Today, I implemented the player start entity (controls where the player is "spawned" when the game loads a new level) and made guns actually consume ammunition. Since the last update, I also cleared up some asset caching issues and fiddled some more with my rigid body functionality.
My AI actors are still pretty braindead. I have a half-finished implementation of a look ray going, but I am sensing that I will soon need to figure out a solution to the pathfinding problem.
Additionally, in case you haven't caught it yet, the source code responsible for the Zune lockup has been discovered and poked at. It should be a sobering lesson about trusting your supplier (i.e. don't do it).
SHilbert and I worked through the night last night to figure out a fix for my polygon collision behaviour.
The issue was that the player could slide off of one wall and "rebound" through another very slowly. You can see the behaviour in this low-quality YouTube video.
It turns out the problem was that I used 'continue' in an inner loop when I meant to make it continue from the outer loop; this is the same issue as the AT&T Crash which paralyzed the United States' telecom infrastructure in the early 90s. So at least I'm in good company.
Anyway, I'm glad I fixed this bug without a ton of math required; Afterglow feels more solid now and I should be free to implement more functionality.
I will probably make another (higher quality) YouTube video eventually when I have more to show off.
I've been working on the first inklings of AI for the zombie hordes in Afterglow. One of the things that you'll see improved over Glow is that different AI classes will act differently; in Glow, every AI character had the exact same behavior.
Afterglow implements its "AI" in the same way that Novarunner did: through pluggable "brains" which control the linked actor during an update (and also when receiving various stimuli: pain, enemy locality, etc). I have a basic skeleton framework of stimulus response and idle updates, and a sample "brain" which doesn't really do anything except run on the spot. As development progresses, I'll update the sample brain to use more of its facilities, then begin implementing the subclass brains for each enemy type.
One of the big problems I've been dreading is tackling pathfinding. While I had a reasonable A* implementation going in Glow (albeit with a sloppy tendency to cut corners), I will have to spend some actual time thinking about the problem in order to provide pathfinding through my extremely sparse, convex levels. One thing I've thought of is explicitly placing waypoints for the AI to follow to get from point to point, but this might be prone to failure and will mean more fiddly "content maintenance" than I really should be doing. We'll see how it goes.
I've also been helping Trent a little bit with his first attempts at iPhone development. Soon, he (like all others) will be unable to resist the lure of the Apple Macintosh, at which point I will cackle maniacally and move back to the Amiga because the Mac is too popular.
Not a huge amount of news, but you can now play Afterglow with the mouse again. The right mouse button still pulls the player forward, and the left mouse button fires.
I also made some interface improvements, so the mouse scrolling gradually gets to the target position instead of instantly. This also made tearing issues less apparent, and makes the game feel more "solid." Implemented, too, are ammunition consumption and some additional attributes for guns (firing time and spread).
There are still some major bugs on the core gameplay (collision issues) but I'm going to ignore those for now during my quest to improve. Not sure what will come up next -- exam season is in full effect, I just finished my first of four -- but hopefully you will like it.
Missed me? I just spent several weeks wrapping up the semester, so I'm going to make an update here before final exams get hot and heavy.
I made a bunch of changes, but didn't let you guys know. Sorry!
Afterglow gained a tabbed window control, which will be used to change between inventory and character setup:
It also gained explosions, which are implemented as area-effect entities which fire once but remain visible for a short period of time, drawing their asplode sprite.
I'll have to start work on enemies eventually, and that means that I'll have to implement dying, experience gain, and a bunch of other stuff. I also intend to fix some of the wonky-ass collision.
Next semester is going to be an interesting proposition -- I've been accepted to a games programming course. I take a week of lectures from industry people (last year, Radical, this year, who knows?) and then have the rest of the semester to develop a racing game. My idea for a racing game is to write a crappy car simulator; so many racing games give an unrealistic view of road racing because they give you these awesome tuned cars to race around a track. I'm going to try and implement as much of a simulator as I can (I already have a six-speed gearbox working using the Cavalier gear ratios) and then see if I can make it vaguely fun. Unfortunately, there's a proposal stage, and I'm hoping that the rest of my group (as well as the prof) will be okay with my idea. Racing a Neon around the Nurburgring and trying to keep your doors from falling off doesn't sound nearly as fun as it is.
Another difficulty will be trying to convince my team that they shouldn't abandon my copious amounts of pre-existing base code just because the lecturers said that OpenGL is used rarely in industry. It would be depressing to have that happen, so hopefully the promise of having a fully rigged user interface library and a ton of pre-existing code and examples will tip the balance in my favour.
Ask anyone who's spent track time -- it really is fun to drive slow cars fast.
I've added a body of usability improvements to the editor, such as letting the player know what they are currently doing to the map:
It also displays the current texture.
This is a relatively minor improvement, but it was something that was really bothering me about the editor. Now it's a bit fixed, so I should be able to more easily bang out some test levels when the time comes.
I also made entities serializable; the game can load and save lists of entities and their states and effectively initialize a level now (short of actors).
As a special bonus for being such good people for waiting for me, here is an extra screenshot:
Basically what you're seeing there is my text output, text input and "stack panel" control container at work, all of which didn't exist this morning.
So, not only do I have more controls now, but I also have a pretty keen console system up and running with resolution indepedent "smart" resizing. Awesome.
So just a short update since I'm still stuck in a (very extended) midterm season: I implemented a huge load of entity subsystem underneath the base game and also added a checkpoint entity, which works like the checkpoints in Glow.
Soon will come HUD notification of entity hits (requires textbox control) and also entity persistence (requires a bunch of serialization glue behind the scenes to make it clean). I'd also like to get into AI support when I get a chance, and at least get NPCs walking around the levels to be killed viciously.
So I've been working on a bunch of fixing and tweaking with the Afterglow code base. Still trying to track down some odd bugs with player-wall collision but the bullets properly smack into walls again.
Instead of working on the main menu like I said I was going to, I worked on the editor and improved usability (error messages are routed to editor window instead of stdout, scrolling is smoother, mouse picking bugs are fixed) and implemented the (now broken) ability to delete floor polygons.
I would like to work on the entity system next, but I'm beginning to suspect the success in implementing future features is inversely proportional to how frequently I mention them in my journal entries. So it'll be a surprise. I would also like to tighten up player control and start making the character stats tie into them so you can actually run faster when the speed statistic is increased.
I also finished Dead Space this weekend; if you liked System Shock 2 or the film Event Horizon, you can probably find a lot to like here. Just make sure to play it in the dark.
YouTube of the Moment: The Tiny Ferrari -- a modelbuilder builds a scale model of a Ferrari race car, and it actually works, tiny pedals, transmission, petrol engine and all. The level of detail is jaw dropping.
Last night I implemented polygon selection, so there's also now a polygon deletion function, so you can delete entire rooms. I'll work on vertex deletion (and possibly moving) in a bit, but I would rather work on the main menu first, so you can all have some pretty chrome-plating for screenshots.
Posted - 1/7/2009 12:16:46 AM
Time will tell if I'm able to get the gameplay to the same level of fun.
Posted - 1/5/2009 11:43:50 PM
The lectures for my games programming course started, and we've got professional developers giving us the entire course content over the course of this week. One of the things that I took out of their first day of presentation is the importance of metrics, so I went home and made a pointless FPS graph that does nothing really useful other than look super cool.
Posted - 1/3/2009 1:09:07 AM
Posted - 1/1/2009 4:10:36 AM
Posted - 12/23/2008 1:41:18 PM
Posted - 12/12/2008 3:47:23 PM
Posted - 12/7/2008 4:36:58 PM
Posted - 11/11/2008 2:35:49 AM
Posted - 11/5/2008 1:04:56 AM
Posted - 10/30/2008 1:25:54 AM
So I've been working on a bunch of fixing and tweaking with the Afterglow code base. Still trying to track down some odd bugs with player-wall collision but the bullets properly smack into walls again.
Posted - 10/15/2008 12:33:21 PM