Times, trials, and turbulence.
Monthly Archives: June 2008
A Friendly Testing Session
Managing testing sessions for an online game is something that I don’t think I’ve ever really spoken about, but there are certainly words that need to be said on the topic, for those of you who haven’t had the experience. 🙂
Testing is a task with a difficulty exponential relative to the number of testers involved. Now don’t get me wrong — all of the folks that help me test Skirmish are absolutely awesome folks — but the management of it all is rough. Tonight only saw two other testers, so it was very manageable, but as the numbers increase (try 10+!), things get challenging.
The first step is to alert everyone about the test. This can be done via long-term notice (ie. email) or short-term notice (ie. instant messaging). I always recommend the former when it’s possible, but oftentimes the case is simply that a feature has just been implemented, and (desperately!) needs testing. This consists of messaging several people — as many as you dare 🙂 — and explaining the situation to each of them. Then comes launching the game and meeting everyone inside the game itself. If anyone has any problems launching the game, or additional questions, or can’t come on for another 5 minutes, things get held up for everyone. And from the perspective of a tester, well, it’s not that much fun to sit around waiting on some guy who was pleading with you a minute ago to help test.
Once the monumental task of getting everyone in-game has been completed, trying to get a general direction going for the testing is the next step. Answering questions, introducing testers to other testers, and telling people not to play with the rocket launchers all occur frequently, so you need to pay attention to everyone AND try to keep track of bugs and events that transpire within the game. And if anyone does have a bug or glitch, you need to either plead with everyone to stop testing, or try and address that tester’s bug while hopefully not missing others. It’s a mad-house when you get over 5 or 6 testers at once.
And that’s it. There’s no real moral or lesson in that; unfortunately it has just degenerated to a rant about how testing can be painful sometimes while developing an online game. A sort of “dark side” that I don’t think a lot of developers really think about beforehand. 🙂
Tossing the ‘ol Pigskin Around
On an opposite note, tonight’s testing was quite enjoyable and illuminating. Big thanks go out to Steve-o and Cobrask for their invaluable help. Some bugs were uncovered in the process, and also revealed that my movement prediction (again!) needs some more work. It starts to break down and look ‘jumpy’ once player pings move over 150ms or so.
I took a small handful of screenshots while we tested, which I shall affix tag-lines to. 🙂
(Getting everyone settled into the one-room map.)
(Tossing weapons into a big heap in the centre of the room. “End the violence!”)
(Finally, things just got plain out-of-hand. Had weapon firing been implemented, it would have been a blood bath.)
The focus of the testing session was to see how well movement prediction stood up against higher pings, and to test the two most basic player actions: picking up items, and throwing them about. The latter worked quite well, and I’m feeling ready to move on to (finally!) implementing weapon firing and reloading, which should be exciting territory indeed. This weekend is a long one for us Canadians (Canada Day), so I’m hoping to maximize the progress that Skirmish will see.
Working on the “Inside”
As some of you may know, at my university we alternate every 4 months between studies and co-op. Near the beginning of each term of studies, we apply to and have interviews with employers via an online job application system at our uni called JobMine.
Anyways, I’ve been through seven interviews over the last month with various companies, and today was the point where I got to see which companies extended offers of employment to me, and was to make my choice of which offer to accept. Most were software development companies, but I instead decided to take a fairly off-the-wall job compared to what some might expect: tutoring at the university.
I will be tutoring a second-year Computer Science course (which happens to be my favourite CS course that I’ve taken so far (involving assembly, parsing, and basic compiler creation)), which will involve giving weekly tutorials, marking assignments, creating model solutions, proctoring/marking midterms and exams, and holding office hours (and likely some other miscellaneous administrivia). In terms of work-load, it’s pretty light (35 hours/week, and very close to home), so I’m planning to take a course at the university itself during the term, and perhaps even freeing up more time for Skirmish. 🙂
Skirmish: Player Actions
I’m feeling comfortable with where the prop simulation work I’ve been doing is, such that it’s now at the point where props can be seamlessly created, flung about, moved in/out of players, and destroyed, all over the network without any noticeable glitches. Now comes the implementation of allowing players to interact with this system of prop simulation: via player actions.
The atomic actions that a player will be able to execute are both few and simple: start/end use, start/end throw, reload, interact. “Use” means to perform the primary use of the currently-held item, which may be firing a projectile, healing a teammate, or detonating a bomb. Throwing and reloading should be straight-forward. Interact is the action of attempting to ‘use’ a prop that is on the map near the player. Interacting with an item results in picking it up, interacting with a switch might cause a door to open/close, interacting with a vehicle might cause the player to enter/exit it, etcetera.
After the completion of player actions (and a healthy amount of testing), the fundamentals to actually having a somewhat playable ‘game’ will be in place. Players will be able to interact with the environment and fire weapons at other players. Player death and respawning will come soon after, and Skirmish will be roughly at the same stage it was at in its previous iteration, albeit far more stable and scalable. Exciting times ahead. 🙂
I think I’m finally at the point where I can call the movement prediction — that’s the logic to perform both ‘guessing’ of where players will be based on old data packets, and the correction logic when prediction errors occur — as being in working order. I haven’t tested it much under high-latency situations, so more fine-tuning will definitely be needed in the future, but it’s at the point where remote players generally appear to move around smoothly and without visible delay.
How does it work? The first half is in performing good estimates of where a player will be after a certain amount of time. Player movement information is sent at a default rate of 4 times per-second. This player movement data packet contains the player’s location, velocity, rotation, and the keys that the player was pressing at the time. From this, once the packet arrives, a decent estimate of how old the contained data is is performed (for now, simply adding client1-server and client2-server latency together). Given a good guess at how old the data is, the remote player’s position/velocity/etc is extrapolated using the regular local player updating logic to where that player should be.
The next step is applying smooth corrections. Usually players will move in pretty predictable ways (eg. in a straight line down a long corridor), so this isn’t often a problem, but in complicated gun fights or when pulling off tight dodges — especially with players that have higher latencies — estimates can quickly diverge from what is ‘expected’. Typically the error isn’t too large, so the real problem is just to move the player from his previously estimated spot (now incorrect) over to the newly-received spot (which is correct) without the user behind the monitor noticing the discrepancy. In previous projects I would just apply linear interpolation between the current-position and the newest-position, which technically worked, but looked pretty cheesy (and obvious) to anyone looking at it. I instead opted for a cubic spline, which is composed of a start point, an end point, and a control point. This creates a smooth curve whose direction is influenced by the given control point. By using a start point of the old position, an end point of the newly-received position, and a control point of where the player would be in the future if the new position didn’t arrive, it creates the illusion of the player continuing to move in the same direction, but smoothing deviating to the player’s true position in a non-obvious manner.
This is the next area I’ve been working on, which is also the last stepping stone before Skirmish is essentially playable as a game, rather than just a neat little demo. 🙂
Props are the most generic object in the game world. Crates, desks, chairs, rockets, firearms, grenades, and shrapnel are all props in Skirmish. A prop could be defined as a “game object that is physically interactable and simulated. Most of these props need to be synchronized such that they behave the same on every player’s computer, which is the crux of the problem.
The current development item is to create a manager which will automatically track the state of the simulation of the players, and send out network messages to update props as appropriate, such as when a player picks something up, throws it away, uses it, or, say, steps on a mine. Doh!
I’ll be talking about this in more detail once I have it implemented and in proper working order. So, here’s to looking forward to smashing some crates together. 🙂
Skirmish Breaths, Slowly
It’s been very busy here lately, with a combination of assignments and the co-op process through my university. That means resume-building, applying for jobs, and, of course, interviews. My schedule is full of them in the next couple of weeks, so progress on Skirmish will naturally suffer some slow-down.
The current development item has been movement prediction, which is actually a very broad topic in network games/simulations: the ‘art’ of guessing where a player/object will go ahead of time (since all data received via the network is delayed by some amount of latency), and seamlessly applying corrections when the predictions are not entirely correct. This is very difficult to do well, and it is critical to get it done correctly. Poor movement prediction is evident in many online shooter games, when you find that shooting directly at an enemy has no effect, or when you need to ‘lead’ your enemy (ie. fire ahead of where he is moving) in order to land hits. If even many commercial online games suffer from this, rest assured that it will certainly be a challenge. 🙂
Free plug: onGameDev.com
I wanted to offer a plug for the ‘underdog’ game development portal, onGameDev. They’ve been doing some revamping of their layout and structuring, and are looking to getting off to a really good start. The main shortage is in their supply of members, so you’re encouraged to pop by and check out the fairly close-knit community, and perhaps even join in on the party.