Sunday, May 31, 2009
at
9:05 PM
|
0
comments - [Click to post comment]
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
Friday, May 22, 2009
at
3:17 AM
|
9
comments - [Click to post comment]
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.
Bellow is a rough idea of how it would look like in a network environment with two clients connected to a server.
To cap it up, bellow is how the InputMap and ActionMap interaction will look like for an FPS.
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
Tuesday, May 19, 2009
at
2:39 AM
|
2
comments - [Click to post comment]
Heres the completed holographic road barrier.
Posted by
Prometheus
Sunday, May 17, 2009
at
9:34 AM
|
0
comments - [Click to post comment]
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
Thursday, May 14, 2009
at
2:46 AM
|
0
comments - [Click to post comment]
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
Monday, May 11, 2009
at
3:20 AM
|
4
comments - [Click to post comment]
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
P.S.
By demand, here's a list of articles I'm referencing when designing my network system:
http://fabiensanglard.net/quakeSource/index.php
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
http://udn.epicgames.com/Two/NetworkingArchitecture.html
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
http://developer.valvesoftware.com/wiki/Networking_Entities
http://developer.valvesoftware.com/wiki/Lag_Compensation
P.P.S
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.
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
P.S.
By demand, here's a list of articles I'm referencing when designing my network system:
http://fabiensanglard.net/quakeSource/index.php
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
http://udn.epicgames.com/Two/NetworkingArchitecture.html
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
http://developer.valvesoftware.com/wiki/Networking_Entities
http://developer.valvesoftware.com/wiki/Lag_Compensation
P.P.S
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
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 :)
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
Tuesday, May 5, 2009
at
8:16 AM
|
0
comments - [Click to post comment]
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
Posts
