I’ll go into more detail later, but here’s a SUPER quick synopsis of the last (yikes!) six months:
Completed the demo build of Procyon
Level 3!
New title screen!
Finished game flow!
Working local multiplayer!
New control scheme!
New font rendering mechanism!
New tutorial!
Another bullet point with an accompanying exclamation point!
Sent it through several (sometimes-painful) rounds of playtest on the creator’s club forums, and got some great feedback (especially the feedback from one Jason Doucette of Xona Games, who gave some painful-to-hear but necessary criticism)
Submitted to the PAX 10 competition
Learned that I was not accepted into the PAX 10 competition 🙁
Started work fixing the networked multiplayer that I broke while working towards the demo (I’d disabled it for the demo so that I could keep my focus elsewhere!
Anyway, that’s my short update. But fear not, for here, too, is a pair of videos!
Just another quick update to show off a pair of videos of the in-progress level 2 boss.
First, note that the textures that I have on there currently are horrible, and I know this. It’s okay.
The first video was simply to test the independent motion of the various moving parts of the boss:
[video gone, sadly]
aaaaand the second shows off the missile-launching capabilities of the rear hatches (complete with brand-new missile effects and embarassing flights into the direct path of the missiles!):
What have I been up to since early June? Quite a bit. On the non-game-development side of things: work’s been rather busy (still). Also, I now own (and have made numerous improvements on) a house! So that’s been eating up time. But, that’s not (really) what this site is about.
(Procyon and texture generator devlog below the fold)
In my previoustwo posts, I started looking into what it would take to code the networking for my game, and came up with a first draft, before realizing that floating point discrepancies between systems totally threw my lockstepping idea for a loop.
Lockstepping With Collisions
In order to solve the issue with different systems having different floating point calculation results, I decided to somewhat revamp the network design, and really leverage the fact that I don’t care so much about cheating – you could never get away with a networking scheme like this in a competetive game.
(Latency, packet loss, and bandwidth use analysis below the fold)
In my previous post, I weighed the advantages and disadvantages of my game vs. a standard FPS with regard to networking. After doing so, I came up with an initial network design.
The biggest issue, personally, was dealing with the causality of the network game. Each player gets information about the other with a delay, so neither player is ever seeing exactly the same set of circumstances (perfectionism and network lag don’t mix very well). I think Shawn Hargreaves describes it best in one of his networking presentations: he says to treat each player’s machine as a parallel world. They’re not exact, but the idea is to try to make them look as close as possible. It doesn’t matter if things don’t happen exactly the same, but you don’t ever want the following conversation to occur:
Player 1: “Wow, can you believe I killed that giant enemy at the last second? That was amazing!”
Player 2: “…What giant enemy?”
Procyon’s Initial Design
The design I started with was a hybrid of both the peer-to-peer lockstep and client-server models.
