Leges Motus Progress – January Wrap-up, AI Begins

We have been hard at work on Leges Motus, since mid-December, and I have posted many of the important features we have re-implemented and discussed a few of the topics related to the refactor in my previous posts. Today, I want to give an overview of what we have completed recently, and start on the topic of AI.

Since my last post, the heavyweight server has been fully implemented and tested, and everything seems to be working very well with it. We now use it as the mainline server, and it has, as we hoped, improved the synchrony and centralization of the control over what the clients see at any given time. We have already seen the effects of the centralized server on player collisions – they now look natural, with no weird behavior such as players pushing past each other. This will enable a lot of cool things in the future, including moving map objects, and potentially even throwable weapons such as grenades, someday.

On the HUD front, we have redesigned the look and feel of the HUD, and we are very happy with how it is coming together. We have working health and weapon status bars, gate status indicators, and a radar. The theme is much more standardized and polished, and we expect to continue this focus on graphical improvement throughout the project. The following screenshot shows the current status of the HUD:

The in-development Leges Motus 0.5 HUD, as of February 2011.

Additional elements will be added to the HUD as we go forward, such as weapon indicators, chat, etc.

The gameplay features have been fully completed, including energy regeneration and gameplay parameters (which the server sends to the client, for flexibility in running custom game styles).

We still need to work on menus and configuration options, but we will be putting those off for now. They will be completed before 0.5 is released.

We are taking a break from the implementation of gameplay, HUD, menu, and other features (or at least decreasing our focus on them) over the next few months, to work mostly on the development of an AI (or, more likely, several iterations of different approaches to AI).

We will be starting with an AI somewhat similar to that seen in the now-defunct AI branch of LM 0.2 (except this time, with much better framework around it so that we don’t have to drop it next version!), which will not act with strategy but will react appropriately to the current situation. For example, if an enemy is in sight, it will turn towards the enemy and fire at him. If the enemy’s gate is available, it will move to capture it.

Later, we will implement path-finding, so that the AI can move towards specific points on the map intelligently, and we will eventually work on strategic action, finding a good search algorithm (or algorithms) to determine the best movement and firing decisions.

As we continue towards these goals, I’ll be sure to post about our thoughts and our work. Keep watching for more!

Lightweight vs. Heavyweight Servers: A Question of Design

In the vein of my previous post on Box2D and explosions, I’d like to discuss a topic that has been on my mind over the past few days: that of heavyweight versus lightweight servers… and possibly even a third server-architecture contender.

Recently, I have been working on a branch of the Leges Motus code that makes a radical change to the operation of the game as a whole. One of the main purposes of our large refactor has been to make the game much more modular, less tied to the original design. This has been extremely helpful in the process of this change: I am working on making the Leges Motus server, which previously served almost exclusively to relay packets and keep track of client addresses and scores, actually execute the game logic and take precedence over the clients in that respect.

In other words, the server will control where players move, holding a canonical game state and sending information about it to the clients, rather than allowing the clients to send it all of their own game data and just passing that information around to the others.

This is the difference between a lightweight server (more of a peer-to-peer relay node than a full game server) and a heavyweight server (which runs all the game logic and controls what the clients see).

There are certainly some advantages and disadvantages to both types of server:

Lightweight Server:

Advantages:

• Very small server storage and CPU requirements – easy to run your own server.
• Simple code on the server side.
• Very little data must be transmitted to a client about its own game state – and potentially little about other clients, if their state can be approximated somewhat by client game-logic – so network bandwidth can be reduced.
• What the player sees is exactly what he gets. Since the client controls bullet hits, movement, etc., lag is less of a factor when determining what the result of an action is.

Disadvantages:

• No canonical game state – clients can be somewhat out of sync with each other, and it might require more networking to get them to sync properly.
• There is almost no way to prevent cheating. Clients can send anything they want to the server, and it cannot verify that they are doing reasonable things while retaining the advantage of a small, lightweight server.
• Physics can act strangely when clients see different information about the current state of various physics objects. For instance, players might seem to push past each other when colliding, because they have no way to cooperate on the results – one might see the collision later, or have it resolve differently, leading to a strange-looking outcome.
• A client that is lagging or dropping packets can seem like it is cheating, e.g. shooting other players when they can’t tell that it’s moving into range.

Heavyweight Server:

Advantages:

• There is a canonical game state, so all movement and collisions, among other things, can be made to make sense.
• The server can get a better handle on cheating, because it knows everything about the game state and can tell when a client is acting strangely.
• Clients can be somewhat reduced in complexity – if CPU or RAM is a significant performance limiter, the client computers may not need to be as powerful to run the game (as long as GPU isn’t the limiting factor).
• Updates or in-game advertising may be easier, since the server can sometimes deploy new game logic or content without client version updates.

Disadvantages:

• The server will require more resources to run.
• If clients are lagging, they may feel that they can’t get snappy/proper results from actions.
• Network communication could be increased in volume, as each client must be told about relevant game state.

Given all of these factors, it is difficult to make a decision about the best type of server-client relationship for your game. Originally, we chose a lightweight server for Leges Motus, because the only important changing game-state was controlled by each client – none of it had to be shared or mediated, aside from the gates. This meant that snappy responses were more important than canonical game state. Additionally, we wanted to ensure that the server would be easy to put up and run from anywhere, to encourage the creation of new servers around the world. This situation was ideal for a lightweight server.

Now, however, we have much more intricate physics requirements. We can’t have clients disagreeing amongst themselves about the game state, or things could come out looking very strange. Therefore, a heavyweight server is looking more useful.

But a few problems remain with the heavyweight server approach – we don’t want players trying to shoot and then getting a miss from the server because they had a little bit of lag, for instance. Therefore, we’re taking a hybrid server approach. The server will control all positions and motion, and it will keep track of all the information about the game. The clients, however, will also store their own game logic and physics, and they will tell the server when they fire and who they hit. This sort of hybrid heavy-server-heavy-client approach might take somewhat more resources, but other benefits are maximized.

At the moment, it looks like this theory is paying off. The heavyweight server branch seems to be working fairly well, and most of the small problems that have cropped up were fairly simple to resolve. I will be continuing to test and improve the branch, and, if all goes well, we may see it get merged into the main trunk and become the standard Leges Motus architecture. It’s certainly been extremely helpful that we implemented the game logic in such a way that it is mostly self-contained and there was no dependency on a specific client design – it merely needs to know some information about the game, and then it can run mostly on its own. This made running it on the server quite easy, all things considered.

If you have any thoughts on this topic, please leave a comment and tell me what sorts of client-server architecture have worked well for you.

Area Weapons and Explosions in Box2D

I’m going to deviate slightly from just posting about progress on Leges Motus to talk in slightly more technical detail for a bit. Recently, for the game, I decided to implement area-of-effect weapons (explosion-like or otherwise blast-like kinds of guns).

The main goal here was not to create a realistic-looking explosion with particles and exact, perfect rotational energy on the items hit – there are some other good discussions of the issues involved in things like cover, rotational motion, and so forth here, here, and here.

Instead, I want to talk about simply determining which bodies are hit by the explosion/area of effect, when it is non-circular. For things like cone-shaped blasts, you can’t just use the AABB to find the objects affected.

I decided to create a new body, with a sensor (not a fully physical fixture) using the position and shape (as a b2Shape) defined for the blast. This has the advantage that it can detect hits of any shape and size, but it has the disadvantage that it requires waiting until after the next physics tick to determine what has been hit. Fortunately, if you set the shape up before the tick and apply the results immediately afterward, it takes only one frame extra, so it’s not a big problem. The other complication because of this, however, is that you must keep track of all the information about the shot until you get the results. For this, I used a “Bullet” class, storing an ID, position, and the weapon ID of the fired weapon, as well as which player fired it.

This works best if you have a PhysicsObject wrapper class that is passed in as userdata on your Box2D bodies, so that you can always determine what type of body is hit and cast to it, then call the appropriate methods to resolve the hit.

Now, you’ve got a list of players or other objects that are within the area, but you’re not done yet. Whenever you receive information about a hit, you have to make sure that the object isn’t blocked by others. To do this, I used a simple raycast at each vertex of the object (not just the center, because the center could be blocked without all the edges being safe from the blast). If any of the rays hit, the object is affected. Note: Though I don’t bother with it, as it isn’t terribly essential for Leges Motus, you can take this further and actually determine the percentage of the object that is affected and apply force/damage appropriately, but it’s a bit tricky.

So now, we’ve got a method to find all objects affected by an explosion or area of effect, using nothing more than the built-in Box2D functionality. Pretty cool, eh?

If you want to see the actual code, it’s available in the open-source Leges Motus project. You can either check out the SVN repository or view the specific files (common/AreaGun, common/Bullet, and newclient/GameLogic) using the online SVN viewer.

Leges Motus Progress: More on Guns and Graphics

In our last update, we discussed the progress we’ve been making on the refactor in terms of guns, graphics, and gameplay.

We haven’t been idle since then! All of the gun types are now fully implemented, including area-of-effect weapons (I might post a more technical entry about exactly how I made area of effect weapons work, because it’s an interesting topic for Box2D development). This means that the gameplay (minus graphics and statistics and HUD and such) is essentially complete, at this point, aside from a few minor changes (notably, game parameters sent from the server are not yet fully taken into account, but that should happen fairly soon).

Archaemic has been hard at work on weapons graphics, and guns now show up with the player sprite. They’re not quite all positioned properly yet, but that should be done very soon. I’m excited to start working on weapons effects, but I’m not sure exactly when we’ll get to that.

Additionally, I’m pretty sure we hadn’t finished all the map object types last time we posted, but we have now. Even force fields are fully implemented and working.

In any case, playability is definitely coming along, and aside from visual feedback, there’s nothing stopping us from playing a real game on the test server again!

We’ll keep posting updates as progress continues unabated, hopefully with more screenshots coming your way soon.

Leges Motus Progress: Guns, Gates, and Gameplay

Greetings! Goodness – gigantic gobs of time go galloping by as I greatly neglect to give good glimpses into the game’s growing completion. Today, I’d like to update you on what we’ve been working on with Leges Motus, focusing on guns, gates, and gameplay.

Gates are mostly done being ported to the new version now, aside from the graphics. We can sit on them, lower them, and win the round!

Gun functionality is also nearing completion. We have all but area-of-effect guns in place (again, except for graphics). So we can once again freeze our opponents as they make their futile attempts to sit on our gates!

Guns are actually implemented in a much more intelligent fashion, now – whereas before, separate gun types (such as spread, penetration, and thaw guns) could not be mixed, so their features were limited, they are now all part of a unified standard gun framework. This means that you can add thawing parameters to shotguns, or whatever your crazy gun design happens to be.

Gameplay is coming along, and with freezing, unfreezing, gate lowering, and all related physics in place, a basic game of Leges Motus is nearly fully playable in the new client!

So where are we going from here?

1. Finishing guns and map object types, and other remaining gameplay features: We need to complete the map hazards, forces, and other special map objects before we can equal our old feature set, and we need area-of-effect guns as well. Then, we need to round out the remaining minor gameplay features to approximately the same state they were at in the old client.

2. Graphics: We need to add gate graphics, gun/firing graphics, and frozen player graphics. This includes animations.

3. Interface: We need the HUD, chat, player names, stats, etc. to be re-implemented with our new graphics setup.

4. Menus: We will need menus to be finished before the next version can finally be released.

5. AI: Somewhere between 2 and 4 above, we’ll need to implement AI players. We will start on the AI around the end of January, so we’ll see what we have done by then. Theoretically, the AI could be started any time after #1 is complete, but I’d really love to have some of #2 and #3 done before it if possible.

As my final tidbit of news, we have an artist starting to draw up some concepts for new player graphics for Leges Motus. We’re very excited about the possibilities, and I’ll try to get his permission to show some of his ideas on here in the future.

We’ll keep you posted.

Leges Motus Progress: Refactor, Physics

Well, it’s been quite a long time since I last posted. My apologies.

But the good news is, the lack of posts doesn’t have anything to do with a lack of progress on Leges Motus!

We’ve been hard at work since v.0.4.0, and I’m very excited by the cool stuff we’re working on. First of all, it’s all part of a gigantic refactor that involves rewriting almost the entire client. In simple terms, this means we’re fixing all the bad design decisions we made the first time around, separating out the graphics code from the game logic and physics, and from the networking, etc. This will make many new things possible: AI clients, shaders, better GUI elements, better physics, moving obstacles, and so forth.

We’re already moving forward on making several of these new, cool things:

1. We’ve switched to the open-source Box2D library for physics. It’s the same physics library used in Crayon Physics, among many other games. We’re amazed at how much more interesting we can make the gameplay with a full physics engine, rather than our own simple collision code. Here’s a screenshot of the game with the debug drawing for Box2D enabled, so you can see the bounding boxes:

Debug drawing for the Box2D physics in the new Leges Motus revamp. Replacing the physics code with Box2D provides a lot of cool possibilities.

Really, though, it’s hard to get the full sense of how many cool possibilities there are with Box2D until you see a video. I don’t have one for Leges Motus, but there are other Box2D demo videos on youtube you can watch to get a feel for it. As for the current state of physics in Leges Motus, we’ve got jumping and attaching to walls working better than ever, and a bunch of other cool physics should be possible as a side-effect (such as player on player collisions).

2. We are now able to attach shaders to the graphics in the game, which means we can start adding some really cool visual effects. We’re already working on a ripple effect for the impact cannon, which will be much cooler to see than the little dots we had before.

3. Once all the gameplay is re-implemented, we will be starting on an AI client. This is more of a long-term goal, but it’s something we’ve wanted to do for a while now. We feel that, without AI, it’s hard for players to find out how fun Leges Motus is unless they have a bunch of friends playing at the same time. Empty servers are self-perpetuating, so having AI opponents would hopefully allow us to break this trend.

4. As a slightly less earthshaking, but still useful, feature (and one we could not do before), we have made it so that the game scales to fit the display window. This means that players with larger screens will no longer have an automatic advantage, because they will see no more of the game than anyone else.

I’ll try to make it a habit to post a lot more updates in the coming months.

What’s on tap for Leges Motus?

Well, Leges Motus v.0.3.0 is finally released! (Sorry about the delays – there were many things that got in the way of the release, both code-wise and project management-wise. But we’re past them now!)

But rather than rehash the new features (see the previous posts for those), I’m going to talk about what’s coming up.

We might take a long time to write 0.4.0 (yes, there will be another beta release before 1.0), but we’re going to try to make it worthwhile. We can’t promise any specific features will or will not get done, but here are some of the things I want to try to get in there:

1. Revamped internals. Over time, the initial design of some internal components has become a bit cumbersome. We created the original framework with quick and simple development in mind, but we now have goals that go far beyond the initial feature set. We want to separate the graphics from the game logic, so that we can create an AI client in the future. We also want to improve the GUI toolkit to make it easier to create dialog boxes and menus and such.

2. New weapons/functionality: I want to make two new weapons – a melee weapon that sends a pulse of energy out around the player to freeze nearby enemies, and a machine gun that must be charged briefly before it starts to fire (so it charges, fires a burst, and then needs to recharge). Additionally, I’d like to make the impact cannon fire in a small cone rather than just at a single point.

3. Menu art: We are hoping to recruit an artist we know to draw a nice menu screen background for us.

4. Keyboard settings and manual server connection menus: We want to allow users to easily change their keyboard bindings through the GUI, and to be able to connect to a server by typing in the IP address, if it’s not listed on the masterserver (currently, the latter can only be done using the command line arguments).

All of this will be a lot of work, especially when you include the smaller fixes and improvements. We’ll keep you posted.