Replay functionality, new icons

Yes, you can now view the last five games you played as a spectator! All I did was save each network packet that’s sent out into a big list, then use Python’s pickle module to serialize the list to a file. Each packet has a timestamp, so I just read the packets back in order, checking the timestamps to make sure it reads the packets back at the right speed. Fast forwarding is not implemented, but it would be pretty easy. Rewinding/seeking would be more difficult, so I’m not sure I’ll get to implement those.

On the artistic side, here’s a sample of the new icons! They’re monotone so they can be tinted with the team color.

Top to bottom, left to right: cloaker, player, shield, shotgun, chaingun, sniper, melee.

November update

This month’s release will start to show more of the Real-Time Strategy side of Stainless. One new feature that unfortunately will exclude a section of the target audience is speech recognition. I’m using the MS Speech API, which obviously only works on Windows. Sorry Linux and Mac users.

Still, it’s going to be worth it. Right now the level design and AI are not quite advanced enough to benefit from speech commands, but the potential is there. Also, the game has a new system for money management, which means players will have to start rationing their money and deciding which units to buy. Basically, you’ll buy the right to use a certain unit for one round in a game, and no matter how many times that unit dies that round, he’ll respawn for free. But then the next round, you have to buy all new units.

Also new: players and units no longer spawn only at their home base. If you die in the middle of the map, you’ll respawn a few seconds later in the same spot. Which can be good or bad, depending on the situation. Basically the idea is to keep the game moving at a quick pace during the round, and then slow things down in between rounds to allow players to strategize.

The new respawn mechanic required some interesting new art and sound assets, because respawned units and players basically drop out of the sky in drop pods. Here’s some screenshots of the drop pod in action:

Several drop pods deploying their units. This will be the first thing you see when the round starts.

A close-up of some drop pods. This is me respawning in the enemy base.

Stainless v0.3 beta released!

Along with an HD trailer. Free download here!

Prepping for first release

Less than one week away from release! Looking at the to-do list from last week, I actually haven’t worked a lot on the items listed. I’ve been ironing out a lot of bugs and adding polish. The multiplayer scoring is now working, and you can see everyone’s scores on the top of the screen, conveniently color-coded. I killed the ugly black boxes around the scores and added drop shadows instead, and I moved your current balance to the right side of the screen, to avoid confusion. Take a gander:

New, less confusing UI. And that icon over that droid means it's a cloaker. Hence the transparency.

The bar on the left shows you how long before you can use your grenade again. The recharge time is around 12 seconds, and I’m counting it as the player’s “special action”.

The main thing I’ve been working on is networking. The old system made the game simply unplayable. I couldn’t figure out why there was so much lag. The game itself didn’t run particularly slow, but the network seemed to be clogged or something. I decided to use threading to speed up network performance, at the cost of CPU performance. After a great deal of debugging and hacking, I managed to get it working.

I also took the opportunity to implement a new packet system that can mix-and-match packets when sending them out, which allowed me to package the different types of packets (entity creation, deletion, and controller updates) into one comprehensive packet that is sent out at 30 FPS. as opposed to 24 FPS with the old system. The new setup also queues critical packets in between network updates, in case something important (like firing a gun) happens during one of the frames where we don’t send out a network packet.

One big advantage of the threaded network system is that resource cleanup has been, well, cleaned up. All the network resources are allocated in the thread function, and they fall out of scope when I kill the thread.

More on networking later. For now, there are other more exciting changes! I removed the “Cloud City” map from earlier, and added a work-in-progress map called “Impact”. It’s the largest, most complex map so far. I haven’t done any detailed modeling or texturing, so here’s a first glimpse at it:

New work-in-progress four-player map called Impact. This will probably end up being a 2v2 setup.

First release is going to be AWESOME.

Production schedule

Yes, I have a schedule/deadline now. I’M SO NERVOUS.

Here’s the plan. And when I say “forum”, I am of course referring to the fabulous GameDev.net forums.

1. October build – Release 0.3, Oct 31 – with the following AI droids: shotgun, sniper, shield, cloaker, melee, chaingun. Virtual file system, XML map format, working multiplayer with scoring and simple “game over” condition. No ability to choose units yet. First forum announcement.
2. November build – Release 0.4, Nov 30 – implement unit suppression from grenades and melee jump jet. Complete match/round logic. Simple squad orders. Unit selection screen at match start. Rough draft YouTube trailer. Forum announcement update.
3. Official release – Release 0.5, Jan 9 – special abilities, finalize multiplayer maps, finalize YouTube trailer, overall polish, official website goes live. Image of the Day post / official forum announcement.

January 9 final release! Which means Stainless will have been in development for exactly one year! Quite impressive for a guy who never seems to finish these things.

I’ve made a ton of progress on the gameplay. All the droids listed for the October build are complete. Actually, the October build is just about ready to go, minus the scoring and game-over condition. I’ll see if I can knock out the unit selection screen from the November build ahead of schedule. That would make this first release almost like a complete game or something! Crazy, I know.

Of course, there is new eye-candy, but I don’t have time to post it right now. Next time.

More shiny!

Three updates, one in graphics and two in gameplay.

Graphics: new water shader! Thanks to Panda3D’s new built-in support for user clip planes in the shader generator, the reflections were a piece of cake. It’s a very basic shader that simply deforms the render buffer and the reflected render buffer, then blends the results 50-50. No fresnel, no lighting, nothing. It works, though.

Using the distortion shader from my last post, I added a shield droid that puts little shields around team entities in its vicinity. The shields decreases ranged damage by 25%.

Which brings me to the next item: the new “Claw” melee weapon. It’s basically a giant claw that can do 100 damage points, where most characters have 200 HP. The catch is, you can only use it once every few seconds, and you have to be in the air, a few feet away from your target, pointing pretty much right at it. If you get all that right, your droid lunges forward, whips out this huge claw (with a pretty nifty animation, I might add) and shanks the target. Otherwise, it makes a sort of “fail” sound and half-heartedly stabs at the air. And of course, the new shields are powerless against it.

Here’s a screenshot showcasing all three new features, along with a new, stripped-down map. You’ll also notice I added colored halos around the droids, for easy target identification.

Yes, the water has all kinds of visual artifacts. But it's pretty at first glance, and taking into account my performance goals, that's good enough for me.

Panda3D distortion sample

For any Panda3D users out there, this is an improved version of the frame-buffer distortion sample currently shipping with Panda3D 1.6.2. Whereas the original sample just samples a wave texture to offset the frame-buffer sample location, the shader in this version actually uses normals from the Egg model. It also gives a slight tint to the object. You can easily adjust the color and intensity of the tint at the top of the “distortion.sha” file.

Screenshot:

I also made the ball in Blender.

And here’s the download. Just copy it into the samples folder of your Panda3D installation.

New artwork

Yeah, I’m back to art now. I am ashamed. But I’m starting to get the hang of this Blender stuff. Check it out:

New weapon model. This is a Blender Render, not in-game.

And here it is in-game. Don’t worry, I fixed the clamped textures on the bottom after I took this screenshot.

Here stands the inanimate metallic ball, ready to kick butt and take names.

And here’s the new map, along with the new and improved springboard/booster thing model:

There's two of these platforms, one for each player, with one of those big glowing rocks on each.

And now for something completely different…

I actually planned a full-fledged single-player campaign for Stainless, before I came to my senses and downgraded it to a much simpler multiplayer game. However, I’m still considering a short (2-4 hours) campaign. What I have in mind is similar to Valve’s strategy with Left 4 Dead: a short, highly replayable campaign designed for 2-4 players. With one catch: the players are fighting against each other.

With my limited marketing and branding skills, I have dubbed my idea an “anti-cooperative campaign”. It would be best with 1v1 or 2v2, but regardless of the player count, the computer would balance the teams by bestowing various power-ups. Which means, if I ever add an online component beyond LAN, matchmaking would be unnecessary.

The big question is, if the teams are somewhat even and neither team makes any significant progress, how does the story advance? Obviously we need a special kind of story.

There are lots of great story-lines for a lot of great games, but rarely do they intertwine with gameplay. They are tools designed to motivate players and introduce the next level (the Halo series comes to mind). The story may be rich, and the gameplay fun, but they rarely affect each other. When the story advances, the player thinks “Oh goody! Unlocked gear, new enemies, and fresh eye-candy!”

I’m not going to try and solve the problem of detached story-lines. Rather, I’ll take advantage of the fact that no one seems to mind them.

So we have two teams playing against each other. I imagine a story that would make both teams feel like they are in the right, and portray their enemies as bloodthirsty barbarians. Perhaps their superiors are feeding them propaganda to increase their battle effectiveness. Over time, informed by cut scenes or another plot exposition tool, players would see through the propaganda, join together, and usurp their commanders. Maybe it changes from “anti-cooperative” to a cooperative campaign. Maybe they find out they were both under the same sadistic commander, and all four players defeat him in a final boss battle. Just a few possibilities.

Anyway, I’ve been thinking about the story-and-game-design side of things. With the core engine relatively stable right now, it’s time to start thinking ahead about the game design. Who knows? If I do come up with a small story in writing, I might post it here in episodic tidbits. Stay tuned!

Network system description

As promised.

First, a small disclaimer. This network system is designed for a very specific task: handling networked physics/gameplay over a LAN network. The structure described here might be useful in other scenarios, but the actual Python code is certainly not fit for much else.

The system follows a modified Model-View-Controller pattern that focuses on two main types of objects: Entities and Controllers. The “View” part is split between the Entity and Controller. Entities handle most of the assets tied to a standard object in the game world: namely, the physics geometry and graphical representation. Each Entity has exactly one Controller, which handles all (and I mean all) actions the Entity can perform. The Entity will not move at all without a Controller.

Two objects manage all the Entities and Controllers: the EntityGroup and the NetManager. There are no separate versions of these classes for client or server mode; they behave similarly in both instances. The advantage of this design is that clients can behave like the server in some ways. Certain Entities, such as a client’s player character, are designated as being in “server mode” on the client. So, the player’s Controller simulates everything on the client machine, and sends update packets to the server, which then forwards the packets on to all the other clients. The client machine can also spawn Entities if necessary, such as when the client player throws a grenade.

Each Controller has two update functions, one for server and one for client. The server update function accepts a network packet as a parameter, to which it adds its own data. On the server machine, the NetManager calls the server update function on all of the controllers, and broadcasts the resulting data packet only if enough time has elapsed since the last broadcast. (Packets are limited to under 30 FPS.)

Now, the server update function doesn’t actually do anything to its Entity. It just packages up its data (which may be different for different types of Entities) and sends it off to the NetManager. So for anything to happen on the server machine, the NetManager must also process its own data packet that it just sent out to the clients, as if it were a client itself. In a way, the server is connected to itself as a client, although it is completely in software.

The client update function accepts a read-only data packet, from which it reads all the Controller data. It handles all client-side effects (for example: lighting, sounds, and sparks from gun shots). The data packet is an optional parameter, though. When a packet is not available, the client update function simulates the Entity to the best of its ability. Of course, on the server, the client update function gets a data packet every single frame.

Client-side prediction is not done at the moment, but all it would take is to advance the physics world a small amount after receiving a server update packet. You can check out the source code here: http://sourceforge.net/projects/stainless/develop. Most of the network functionality can be found in net.py, entities.py, and controllers.py.