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.
Posted - 12/23/2008 1:41:18 PM
Posted - 12/22/2008 8:57:00 PM
Posted - 12/12/2008 3:47:23 PM
Posted - 12/7/2008 4:36:58 PM
