View previous topic :: View next topic |
Author |
Message |
bane
Joined: 01 May 2007 Posts: 41 Location: Pancevo, Serbia
|
Posted: Tue May 01, 2007 7:21 pm Post subject: I like this engine :) |
|
|
First, my impressions:
Engine looks like powerfull, simple and clean (same as D language) as far I got chance so far to look into source. I hope this is a startup of a great project
Secondly, a possible feature request.
Is there a chance to include a simple networking library? Games need that, and sdl_net is included in Derelict as I see, so... Nothing fancy, basic UDP server/clients replicator with simple api to get things going. I know I need that first thing with a game engine.
And thirdly...
I checkout-ed trunk couple hours ago. Could not start demo, problem lies in calling "scene.start(60)" line of the main.d:
Code: |
// Create and start a Scene
Log.write("Starting update loop.");
Scene scene = new Scene();
scene.start(60); // update 60 times per second
scope(exit)scene.stop();
|
it just dumps "win32 error/exception". Anybody has same problem?
I use windows xp and GF FX-5200.
Allso, I could not build it untill I placed folder in path withouth spaces (like "c:/yage" instead of "c:/Documents And Settings/...".
Cheers to all |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
bane
Joined: 01 May 2007 Posts: 41 Location: Pancevo, Serbia
|
Posted: Wed May 02, 2007 7:26 am Post subject: |
|
|
strike that bug out. i reinstalled windows and its working. i like engine even more now ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Thu May 03, 2007 10:36 am Post subject: |
|
|
Glad to see you like it so well. I just wish I had more time to work on it. I already have networking support listed under possible features in the roadmap, but it probably won't be implemented until after 1.0. However, if you plan on using the engine for a project and that's a feature you'll need, I can work with you to get it developed and into the engine.
Scenegraphs already update their scenes in a separate thread and at a constant rate, so that should help with synchronization, but network code still isn't an area I have much experience with. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
clayasaurus
Joined: 21 May 2004 Posts: 857
|
Posted: Thu May 03, 2007 11:01 am Post subject: |
|
|
I need a networking library too, it would be best if it were written in D.
I know the Deadlock teams has weird problems with raknet as well.
Maybe us D game devs can join together to make a D networking lib. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
bane
Joined: 01 May 2007 Posts: 41 Location: Pancevo, Serbia
|
Posted: Thu May 03, 2007 3:36 pm Post subject: |
|
|
D is promissing language and I wold definitelly want to explore it.
As far as network lib - i played with zoidcom and found it has terrible manual/api (my impression). On the other hand, ENet low level lib is great, but some wrapper for replication has to be made couse it is to low after a while Had a nice time building that wrapper. I was not satisfied, though, much more becouse of limitations of c++ than of ENet wich was great.
Untill yage is operation I will play with raw opengl / glu and sdl. And I need network lib, one way or other.
Been thinking of implementing sdl_net, maybe phobos/tango raw sockets (or even best ENet ported to D) for a udp client / server networking model.
I would also make it first as standalone library that can be used for any project. Then, if it gets stable and mature there would be fairly possible to integrate it in yage model.
Something like zoidcom/raknet, but simpler and more understadable for redneck like me
Any ideas of api model? |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Thu May 03, 2007 9:42 pm Post subject: |
|
|
I should first throw out a disclaimer that I've written very little networking code. With that out of the way, I'll go over what I've brainstormed so far for networking support in Yage. Constructive criticism and highlighting of flaws is definitely welcome. And most of my API idea is high-level and specific to Yage.
First, for the uninitiated, Yage uses a scenegraph. Each scene updates the positions, rotations, velocities, calls custom callback functions, etc. for all of its nodes at a fixed interval inside its own thread.
Code: | //A Scene could have the following methods:
scene.setServer(char[] ip, int port) // This scene will synchronize with a server at this location.
scene.setListen(int port) // Act as a server and listen for clients on port.
//Nodes in the scenegraph could have the following methods:
node.setSyncInterval(float seconds) // How often to attempt to sync this Node and its children (unless overridden) with the server, negative for no sync. |
As for behind-the-scenes networking, I'd hoped to add methods to serialize nodes, and maybe send a compressed version of that through a regular D socket. Scenes that act as servers might also have an option to operate in tcp/ip or udp mode.
But like I said, this implementation may be a bit naive since I don't have much experience in this area. Prediction still becomes a bit of a mess, since the synchronization of nodes will always be a few frames behind, especially with higher pings, although I think I could build such a prediction system into my current model without too much trouble.
I realize this doesn't describe the low-level lib that's been requested, but just my own thoughts on the matter ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
bane
Joined: 01 May 2007 Posts: 41 Location: Pancevo, Serbia
|
Posted: Fri May 04, 2007 5:39 am Post subject: |
|
|
Its ok, that is high level end api most of users should know only about.
Not going into low level implementation, these are basic guidelines most of network libs state:
1. tcp is good for slow stuff only, like turn based games / strategies or such, adventures. For anything like FPS or simulations UDP is only choice.
2. pure UDP is not good enough. it is unreliable protocol (you lose packets and dont know about it), unordered and packet size is limited. So, to use UPD there must be extra work on packet and connection management.
3. Once you have way to send data, there must allways be tendency to filter noise (unneceseery stuff) and send as little data as possible.
4. replication of any kind is your best friend in network games
5. Replicating every node with every property automatically is not the only way (not even good, in my opinion, becouse there is lot of unnecesery stuf - not every node is important, really)
If we consider this with your basic idea of every node updating: if you have 1000 nodes of some kind and 200 of them are changing some state at the moment, that is adleast 200 x 1 property (lets say speed as float). That is need for 200x4 bytes to sunchronize per turn (not counting bytes sent for identifiers of nodes).
If we use serialized data for transfering whole nodes, well, that is a lot of data, even for one time only transfer during connecting. 1000 nodes serialized can be easily 100k or more.
There are ways to manage what data is needed to send (update) anyway.
Basic server/client mode I worked on (influenced by zoidcom replicator) works like this: data about all nodes that server holds are authority. client data are occasionally updated (replicated) with one from server. If there is not enough badwidth/or lag happens - well tough titty client (player) i
n RPG game will still think he is allive and kicking, while there on server there is allready known that we was hit with bullet/sword and dead. So, when bandwidth allows, client will be notified of that fact.
It is very important that clients have no authority and that all relavant calculations are done on server. Clients are passive and when they create event data is sent to server first, server handles event and then whe sends response to all clients. Client do not handle event.
There are allso ways to reduce data transfered. All clients can have their own calculations for movement and all, there is no need for each frame to be updated from server. But occasionaly, real state will be updated from server to clients so clients can correct their version of reality ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
bane
Joined: 01 May 2007 Posts: 41 Location: Pancevo, Serbia
|
Posted: Fri May 04, 2007 1:27 pm Post subject: |
|
|
Acctually, in real life I work in software R&D dept. of one ISP company, and there might be soon a project involving high load/speed UDP server, a project very similar to game networking lib we are talking here about. D is the language of my choice, off course. I'll let you know if I'll be able to somehow relate that with this and make two things instead of one ![Smile](images/smiles/icon_smile.gif) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Fri May 04, 2007 2:39 pm Post subject: |
|
|
Agreed, and all of those are excellent guidelines. I'd already for the server to of course have absolute authority, and only sending state changes. I knew that UDP is faster because it sacrifices reporting back, but I didn't know that pure UDP would be too unreliable.
There will also need to be a way to prioritize events invoked by player actions over the code that keeps everything in sync, so that firing a weapon has as little delay as possible. With my constant timetsteps, there shouldn't need to be too much to keep things in sync anyway. Since various types of games (fps, rts, racing, etc.) should probably handle this differently, I don't know what should be inside and outside the engine api. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
bane
Joined: 01 May 2007 Posts: 41 Location: Pancevo, Serbia
|
Posted: Fri May 04, 2007 3:47 pm Post subject: |
|
|
Yeah, that question "what user needs" is constant pain in the ass.
Instead of forcing programmer to use api optimized for only one thing, more important is to give tools so he can make what he needs for his type of game. So, I see this way:
1. layer one - low level lib. basic server/client classes and connecting. Ways to send packets as bit arrays. Api and capabilities comparable to ENet library. Who likes it, can use this layer to build what/she wants from scratch (allmost).
2. layer on top of that - universal replicator class. I personally like a "data array" model, something like generic object/property replication. I will post examples latter to see is it logically only to my brain or other people will accept it easy. API ideas and discussions of this layer are *very* welcomed, couse API style ( and manual, examples) are most important things for attracting people . This layer of network lib will be usable for any D project and could be similar to zoidcom/raknet (but not that powerfull). This way people might acctually start to fix bugs in it if they use it
3. layer on top of that - connection of these generic objects to yage node objects and some way to prioritize what object and their properties are more important to update and when. This is your job, Joe .
I'll guess I'll contribute to layers 1 and 2.
PS. Just found out mu firefox has spell check. Nice. _________________ "I apologize only for my spelling" - a quote shamelessly stolen from some guy at unknown forum. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Nthalk
Joined: 15 Jun 2008 Posts: 8
|
Posted: Wed Mar 18, 2009 6:26 pm Post subject: |
|
|
Given that projects with yake could vary in size, complexity, and intention, isn't it bad to include support very specific things like networking and object synchronization?
If someone spawns 500 entities (I.E: missiles) in 2 seconds, they should probably send a simple event message instead of the position,velocity,acceleration,angle, and model info for each entity?
Tying networking down into the scenegraph seems like a mistake, since often latency is resolved with positional prediction and not simplification of information.
For fun, I have started looking to Tango's tina clustering tools for ways to solve this kind of networking. =) |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
JoeCoder
Joined: 29 Oct 2005 Posts: 294
|
Posted: Sat Apr 11, 2009 3:40 pm Post subject: |
|
|
I'm very much open to different ideas at this point. Let me know what you find. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
Sage Rat
Joined: 25 Mar 2009 Posts: 10
|
Posted: Sun May 10, 2009 12:28 am Post subject: |
|
|
I'll just note that, personally, I had intended to use dnet as the base for my networking. Building a layer on top of that to make objects automatically networked would be something that would still need to be done, but at least the core networking code would be proven in large-scale environments. |
|
Back to top |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|