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
