The Great Return(tm)

It was a fun adventure out in the wild. I don’t know about you though, but I’m ready to go home.

An update.

Of Life

Whew, it’s been a while.

Exams are long since finished — which went well, to all parties who are curious — and I’ve been ‘vacationing’ back home until the end of the month. It’s nice to see the family, but I’m eager to get back to uni and get rolling on my co-op position this fall.

Of GameDev

I’ve been project-hopping pretty badly for the last few weeks, which means that lovely screenshot of that dungeon crawler in my last entry is probably the last that will be seen of it. I need to cut the ambition down a few notches.

I’ve been toying with the idea of a small not-too-ambitious little Wolf3D-like game, which I think grades nice and low on the ambition-o-meter. According to my “research”, this might fare well:

The Ambition-o-Meter

I figure if I embark on a project that’s pretty darn simple, motivation should be a plentiful commodity, since there’s less tricky stuff (like networking ) to get caught up on. Membrane Massacre began much the same, and it resulted in a completed game. We’ll see where this one takes me.

Humble beginnings.

Pillar Dungeon

My first two finals are tomorrow, and I am once again up too late working on “certain things”…

No monsters? No lighting? No problem!

Rise of the GP2X; Fall of Skirmish; Legacy

GP2X Arrives!

Several days ago a little bundle of joy arrived on my doorstep. No, not a baby, my precious little GP2X. It’s every bit as groovy as I had hoped, and after acquiring a 2GB SD card I’ve already installed a ton of software. The community has already matured enough to have produced many emulators, so I’m playing Genesis, SNES, NES, and GameBoy games on this thing like nobody’s business. Not to mention ports of other excellent PC games, such as Duke3D, Quake, Cave Story, and CDogs.

I’m not sure if I’ll be getting into the homebrew gamedev scene for this device, but for now I’m more than satisfied with just being a gamer.

Fall of Skirmish

No, Skirmish isn’t dieing, I’m just making a pun. I’m still really busy with studying for exams, and simply just haven’t been in the Skirmish mood lately. I’m slowly working on a side project at the moment, for the month of August or so. I want to pick Skirmish development back up in September, thus making it the “Fall of Skirmish”. Ho ho ho, get it? Sorry.

Legacy

The code-name of my side project for August. I don’t think it will be finished within the confines of a mere month, but I just felt that I needed a change for a little while after a year of working on Skirmish. I’m not sure exactly where it will go, but I’m satisfied just with working on it for now.

The viewstyle, as you can see, is a sort of 3D-rotatable-isometric type. I’m not sure what other game it’s comparable to, so for now it feels sort of unique.

The original plan was to use voxels for the map components and draw them in real-time, which fell through as I became less interested in writing tricky rendering optimizations and more interested in actually making a game. So I’m currently working on moving it over to use OpenGL and 3d models for rendering, after which things should be a lot easier to work with. This is particularly interesting, since I’ve been looking for a chance to play with 3D programming in OpenGL and 3D modelling for a long time.

We’ll see where things go, but I’m leaning towards a sort of fantasy hack ‘n slash adventure, which the existing tiles might suggest.

Back online — already.

I have my new development journal set up now on the free wordpress.com webspace. It’s not as fancy as before, but it’ll do for the time being. Unfortunately I wasn’t able to migrate my post attachments with everything else, so all of my posted images/screenshots will be vanishing sometime soon. I have them all on my harddrive still, so I’ll have to see about getting a gallery set up.

Progress on Skirmish has been deathly slow as of late, since final exams are just around the corner. I finish these around the middle of August, so I expect progress to leap back into action somewhere around there.

GP2X

I finally ordered one of these awesome handheld gadgets, and am impatiently awaiting its arrival. I just learned that manufacturing has just recently been discontinued, , but I’m happy that I will at least be getting one of the last ones left.

These things are geared really strongly towards homebrew developers, and I’ve always dreamed about developing on limited non-PC hardware, so this will be a huge adventure. No doubt this will suck up a good chunk of my development (and exam studying ) time as soon as it arrives!

Dual 200mhz processors of FUN.

Announce thyself!

I’m very curious if anyone managed to find my new journal location amidst the sudden and spontaneous host change. Please take a moment to place a comment, if you wish to help sate my worries.

A year of toil…

Happy Anniversary Skirmish!

Whew, it’s hard to believe it’s been (a little over!) a year since I started this wild ride of Skirmish. Why, I can still remember how crude my early engine work looked. Actually, it looks frighteningly similar to what I have now.

While the ‘dream’ of Skirmish started many years ago, the work that has led up to what I have today began during lengthy train commutes to-and-from my first co-op position downtown. It started as an engine over OpenGL, gradually became a ‘tech demo’ of sorts, grew to have a map editor, then a master server, then networking of its own, and heck, by now it’s just about at the point where it could be called a ‘game’!

Although any reader can go back and see my several tangent project attempts through the year, none of them were able to draw me far away enough from Skirmish for long. I’m incredibly proud that I’ve manage to stand the test of time on this project, and genuinely feel that now that I’ve survived this, nothing can stop me from taking Skirmish all the way to prime-time.

Ahem. Progress?

Ah, yes. I haven’t updated for a little while, but it’s not from lack of getting work done. The vast majority has simply been in the category of miscellaneousness. Bug fixes, GUI/HUD tweaks, minor additions, code refactoring, and all of the other things that nobody likes to hear developers talk about. It’s not the glamourous side of game development, but it’s definitely a necessary one.

That said, fun is waiting just around the corner. The ‘major’ feature that I’ve been working on between bug fixes is reloading, which is more or less done. With just about all of the small-scale work done, I’m finally free to slide into the bread and butter of this milestone: health, death, and respawning. At last! Skirmish is almost a real game!

Just a little more code…

Lesson Learned(tm): Game synchonization

Good testin’!

Tonight’s testing session was a most illuminating one. I managed to get up to five players on total at once, which is (surprisingly) the most that the game has seen at this point. The networking engine seemed to handle the multitude of players pretty well, and there no were visible lag spikes. We had a couple of overseas players that suffered from a fairly unavoidable latency addition.

(As always, massive thanks to tonight’s host of testers (Knarkles, Rip-Off, Prinz Eugn, and Danger))

The lesson: following the rules can be “bad”.

The session was going pretty well overall, when some “strange” things happened. Really peculiar things like players sometimes being unable to throw their weapons away, or players claiming items were on the ground in spots that the server saw nothing at, and the ilk. In a nutshell: really weird synchronization bugs.

As you may know, Skirmish has a lot of logic dedicated to propagating changes in props across the network to other players in an attempt to keep the game simulation looking and behaving the same on all of the clients’ computers. The problem is herein: the server sends out messages to clients dictating what events are to transpire. However, there is a fair bit of client-side logic that prevents seemingly impossible things from happening.

For example, there is a restriction that the player can only have a certain number of certain items in his possession at once. Such as only 1 Assault Rifle at a time. What happens if a client has 1 of these items, but receives a message from the server saying to add another to their inventory? Huh? What does the client do? Allow this should-be impossible action to occur anyways (on the basis of, “the server said so”), or stop it outright, knowing that it’s just not sensible?

The current logic is set to work such that client-side logic wins the battle in the case of an argument between server commands and illogical actions. The problem is, this causes some pretty nasty synchronization problems when the server tells the clients to do something that is (from the server’s perspective) totally logical, but the state of the clients says that it’s just plain silly. Normally it’s not a problem, but even tiny slips in client-side logic can lead to all of the nasty bugs that I mentioned earlier.

All of that said, the lesson is that there needs to always be a very clear course of action for any significant event that can occur. And when there isn’t, the client needs to keep a verbose log of whenever local client-side logic prevents a server command from being carried out. For anyone else embarking in any online game projects, I beg you to keep this in mind. If you don’t, some of the nastiest to track down bugs will rear their ugly heads.

Artistic talent climbs aboard!

Some of you might know the legendary name of Mark the Artist, or “Prinz Eugn”. He’s worked on several projects with fellow developer Sir Sapo, and is a top-notch artist and pixel manipulator.

By some chance, I happened to be low on testers and invited him into a short Skirmish testing session. Nothing fancy, certainly, but soon after he expressed his interest in doing some sprite-work for Skirmish. He’s not contracted or anything to the project, but has agreed to do some art (specifically, firearms and player sprites) on a as-he-has-time basis.

I’ve recently plugged some of his revamps of the existing weapons into the game, and I’m liking them a whole lot. It’s hard to tell when you have sprites so small, but overall just the look and feel go a long way in making things look more professional. I was practically oozing with anticipation when he mentioned the reloading animation he was working on.

Anyways, a huge kudos to Mark for his interest in Skirmish and the stuff he’s working on. I’m looking very forward to plugging more of his stuff in!

More player actions.

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.

Good night!

Next Co-Op Position (and Player Actions)

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.

Continued adventures in networking

Movement Prediction

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.

 

Prop Synchronization

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.