Just completed some support structure for the track. Players would be able to race through them as they race on the seabed.

Posted by Prometheus
Interaction system. It's funny how the simplest and most important piece of a game engine could be so difficult to design. If there's no interaction, then there's no game at all. Hence, a game engine MUST have a unified way to deal with interaction.

When talking about interaction, input controls come to mind. Keyboard, mouse, gamepad or even those driving force feed back steering wheels. These controls would be bound with the in game characters, crafts or even turrets.

However, here lies the question. What about characters, crafts or turrets that are not controlled by the player? AI comes to mind. Better still, what about replays? Or how about in a multiplayer environment where certain crafts are controlled by some other players over the network?

These scenarios shows one thing. A controller that controls any element in a game should be abstracted from the physical input devices. They should only care about what to simulate when a certain command is executed without needing to know who is executing it.

Hence, I came up with what I call the Action System.

As you can see, the core of an Action System lies in the ActionManager. It will manage a list of action controls. These action controls are basically action devices(in red) bound to a controller(green) through what is called an ActionMap(blue).

Action devices can be anything that handles action inputs. It can be a real input device(keyboard, mouse or gamepad), AI device, Replay device or a Proxy. A proxy device is simply a device that clones whatever the true controlling device's(Owning devices) state. The proxy device is meant for network use only.

Bellow is a rough idea of how it would look like in a network environment with two clients connected to a server.

Now, the underlying structure of an ActionMap holds the key to how one interacts with a controller. It holds a list of actions that defines what is a toggle button, what is an analog axis or even a world vector for FPS styled games.

Having that, the next complicated one is the physical input. How does one bind a physical input to the ActionMap? Here's how I devised it to work. An action input device will hold a list of InputMaps. These InputMaps basically defines the bindings of the input to an action in the ActionMap. This design allows the designer to constraint what input type an action should use while allowing the players the freedom to define their own input within that constraint.

To cap it up, bellow is how the InputMap and ActionMap interaction will look like for an FPS.
Note the vector action doesn't have a direct input from the InputMap. It instead receives it's input from the controller that calculates the look-at of a player through the mouse axis input.

That's it. Next up I'll be talking about buffering the ActionMap for network prediction and Replay. Stay tuned. ;)
Posted by Lf3T-Hn4D
Just started working on different track variations. Heres a couple of destroyed track pieces.

Posted by Prometheus
Heres the completed holographic road barrier.

Posted by Prometheus
Wasnt too fond of the last holographic projector model. Decided to rework on a new design. Based on normal concrete road barriers but with a futuristic design.

Posted by Prometheus
Heres a hi poly version of a holographic "no entry" barrier to block players off certain paths for the 2nd level theme. Will be working on a low poly version soon.

Posted by Prometheus
Time synchronization is very essential to a network game. Though for the most part, what I've read about realtime network games tend to not bother. But what they do bother was implementing client prediction to compensate network latency.

I suppose it's quite acceptable to use enet's rough estimate of round trip time. But I believe if we can improve the estimation of server client time difference, the client side prediction would be more accurate. Besides, getting a good estimate of time synchronization only takes up the first few seconds of a connection. So it's worth doing it. :)

The time sync i'm planning to implement is from this article: http://www.mine-control.com/zack/timesync/timesync.html

Though the design of time syncing is more for RTS styled network, it should still be very useful for realtime world snapshot based network.

However, implementing this time syncing algorithm requires that the internal logic code respond to the network as soon as possible. Any delay due to application layer will only jeopardize the quality of the time syncing. This being the case, I need to poll enet in a separate thread from the main rendering thread. That way, I eliminate the delay caused by any main thread's busy logic and also the beloved monitor vsync.

Then from this polling thread, whenever there's a new incoming streaming enet event, I immediately push them to the streaming thread. This gives me almost immediate event receiving for the streaming system. That way, I could implement the time syncing using the net streaming system which is a good thing. :)

However, I still need to pass normal messages back to the main thread. For that, I used a lockless queue system to queue the event messages back to the main thread without any need to do mutex locking. That means less expensive threading. Yay!

I've only just got this part compiling. Not tested yet. Hopefully it'll work. :P

By demand, here's a list of articles I'm referencing when designing my network system:

Oh, i forgot to mention about the net streaming system during the last post. Just a quick cap, the net streaming system is a way to write synchronous network protocol in a separate thread without interfering with the main thread. This works very well for stuffs like handshake and file streaming. ;)

Lf3T-Hn4D out.
Posted by Lf3T-Hn4D
Posted by Prometheus
I've got basic networking done. Now the game engine deals cleanly with connection handshake and network command messaging.

These two feature is essential for the game. Handshake exist such that verification between server and client must exist when initiating connection. This will allow server to verify if the client is the actual Aftershock game client and not some other random app who so happen to use the same port number. It also filters bad version matches so only game binary of the same version can connect. Last but not least, it also deals with filtering of conflicting user names.

Eventually, this system will be extended to authenticating with our central server for validating users in online play. :)

The second system which is network command messaging acts as a way for two computer to communicate and send command to each other. This is important for world synchronizing where the server needs to tell clients to spawn objects, shoot some fireworks, trigger some sounds, or even send chat messages.

Unfortunately, network is not as nice as graphics. There's nothing flashy to show even though the underlying part is a masterpiece. :P So no screenies for this post.

But one thing I must say before I end. I'm glad I planned for network when designing the engine. Writing a single player game engine and a network multiplayer game engine is two totally different thing. A single player game engine can never be enhanced properly in a multiplayer environment. I'm glad to have so many reference articles by Epic, Valve and id-Soft for puny little me to refer to. :) Gotta love living in this era. :P

Next up: Time synchronizing :)
Posted by Lf3T-Hn4D

Catch the making of game art for Project Aftershock in Blender Art Magazine Issue 21: Look What I Can Do! page 31

Download link here : http://www.blenderart.org/issues/

Posted by Prometheus
Liquid Rock Games and Project Aftershock. All Rights Reserved.