I have trouble "putting it all together"
This is a problem I've always struggled with: I can write pieces of code and small modules that do very specific tasks like the wind, but when it comes to organizing the program as a whole I break down. As a recent Computer Engineering graduate, this isn't such a bad thing since most of my professional tasks are extemely low-level. However, for hobbyist and educational purposes, I've been trying to put together a relatively simple networked game server.
So far my server consists of what I called the "Xcvr" module, which handles all network communication, and the "Simulation" module which keeps track of the world, updates objects' positions, etc. I had the idea of using FIFO queues to "post" messages between modules, giving them a sort of asynchronous medium of communication. Each module, at some point in their loop, then "pops" messages off their queue one-by-one to examine and handle it. I thought this might lend itself well to splitting the program into concurrent threads - or maybe you're about to tell me "no that's retarded there's a better way." Let me know!
My biggest problem at the moment, however, is as follows: every Client object has its own pending message FIFO which gets dumped out the UDP socket when the Xcvr gets around to it. My problem is that all of the Client structures are contained in a linked list within the Xcvr module... the Simulation has no way of posting messages directly to Clients. I've gotten around this for now with a fairly sloppy hack, but I really feel like this is important to get right before I go forward.
In case that was just way too much text, I drew a pretty picture in a rather sad attempt to visualize what I'm aiming for, and where my most immediate problem is.
I suppose the long-winded point I'm driving at is that my engine feels way too inter-connected. I'm trying to keep everything separated into their own little worlds, but failing miserably. I've tried searching for things like "game engine design patterns," and "multiplayer server architecture," but most of what I find covers the more concrete topics like handling input, working with sockets, algorithms - stuff I already know, or at least know how to find when I need it. Where are the articles about overall organization, or program structure?
Some questions I'm battling with:
"How is the Simulation going to post update messages to clients when it can't find their message queues?"
"Maybe the Sim shouldn't be posting messages to clients? Maybe that should be the responsibility of something else, but then how will that something else know which clients to update with what?"
"Maybe the clients shouldn't store their own message queues, but instead be linked to their queues by ID number the same way they're linked to their player SimObjects? But then how will the Xcvr find and transmit their queues?"
Suggestions and reading material would be greatly appreciated!
Thanks
Some things you can only learn through blood sweat and tears.
I read a neat story a while back about a ceramics class where the teacher broke the class into 2 groups.
Group A was graded on their quality of work. The prettier the thing, the higher the grade. If they only made 1 thing the whole year but it was amazing they would get an A.
Group B was graded on sheer quantity of work. Literally the teacher would put their work on the scale and grade them based on weight of how much junk they produced each week.
What's interesting is at the end of the school year, group B was creating better looking / more skillfully crafted pottery than group A.
The reason why is because instead of sitting around trying to aim at what would be perfect, they spent their time DOING and getting better by making lots of mistakes and moving past them etc.
In the end my point is...
You might be overengineering the problems, maybe you should just focus on getting it to work any way you can without worrying about things being correct.
When its finished you might say "oh well in hindsight i should have done this or that" and when that happens you will actually know what to do the next time around and the reasons for those ways being the right ways.
Hope that makes sense (:
basically: do it however you want to / however you can, and worry about problems when they come up, but not before.
EDIT: btw the same applies to profiling your code. Get functionality in first and then worry about optimizing your bottlenecks. Optimizing before you know what is actually slow is a common mistake people make and is a major time sync and source of unnecesary bugs :P
I read a neat story a while back about a ceramics class where the teacher broke the class into 2 groups.
Group A was graded on their quality of work. The prettier the thing, the higher the grade. If they only made 1 thing the whole year but it was amazing they would get an A.
Group B was graded on sheer quantity of work. Literally the teacher would put their work on the scale and grade them based on weight of how much junk they produced each week.
What's interesting is at the end of the school year, group B was creating better looking / more skillfully crafted pottery than group A.
The reason why is because instead of sitting around trying to aim at what would be perfect, they spent their time DOING and getting better by making lots of mistakes and moving past them etc.
In the end my point is...
You might be overengineering the problems, maybe you should just focus on getting it to work any way you can without worrying about things being correct.
When its finished you might say "oh well in hindsight i should have done this or that" and when that happens you will actually know what to do the next time around and the reasons for those ways being the right ways.
Hope that makes sense (:
basically: do it however you want to / however you can, and worry about problems when they come up, but not before.
EDIT: btw the same applies to profiling your code. Get functionality in first and then worry about optimizing your bottlenecks. Optimizing before you know what is actually slow is a common mistake people make and is a major time sync and source of unnecesary bugs :P
Thanks for your reply, and very good points! Your story and what you say about "overengineering" is certainly true, and is something I've had to admit to myself that I struggle with several times in the past.
I kind of think that another problem I have in this area is that I don't have any social contacts who are knowledgable or even remotely interested in these sort of things, so I have no one to bounce ideas off of. I often find that just explaining my problems to someone else (or sometimes just explaining them aloud to myself, which can be awkward when someone walks in on me) will stimulate my brain to think of creative solutions - which may have subconsciously been the entire purpose of this thread ;).
With that said, I think I've solved the immediately problem described in my first post. I'd still be interested in any suggestions or reading material anyone would like to offer on the subject of how large software like this is typically approached, subdivided, and organized as a whole.
Thanks, again!
I kind of think that another problem I have in this area is that I don't have any social contacts who are knowledgable or even remotely interested in these sort of things, so I have no one to bounce ideas off of. I often find that just explaining my problems to someone else (or sometimes just explaining them aloud to myself, which can be awkward when someone walks in on me) will stimulate my brain to think of creative solutions - which may have subconsciously been the entire purpose of this thread ;).
With that said, I think I've solved the immediately problem described in my first post. I'd still be interested in any suggestions or reading material anyone would like to offer on the subject of how large software like this is typically approached, subdivided, and organized as a whole.
Thanks, again!
I use a kind of chain-of-responsibility/tree-of-responsibility pattern, similar to the events in a GUI.
For example, when a creature dies, it sends a "death" event to the room. The room then dispatches the event to the other objects in the room (additional visibility/darkness rules might apply there). If an object is a player character, then the event is sent to the corresponding client. Note that the event is part of the simulation, because an object linked to an AI will be allowed to react to a "death" event too (and it's efficient to react to events rather than polling for changes), or to a noisy event transmitted through a door.
I'm not sure though. Check the network FAQ of this forum too, and examine open source code.
Hope it helps.
For example, when a creature dies, it sends a "death" event to the room. The room then dispatches the event to the other objects in the room (additional visibility/darkness rules might apply there). If an object is a player character, then the event is sent to the corresponding client. Note that the event is part of the simulation, because an object linked to an AI will be allowed to react to a "death" event too (and it's efficient to react to events rather than polling for changes), or to a noisy event transmitted through a door.
I'm not sure though. Check the network FAQ of this forum too, and examine open source code.
Hope it helps.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement