Game server
Blitz3D Forums/Blitz3D Programming/Game server
| ||
| Anyone ever tackled on a game server for their projects? How would you go about? Basically, I'm looking at sending chunks of data to various players, keeping their IP addresses and some info on where they are at in the game and stuff. |
| ||
| You may want to make your own code completely, but this will do what you want, and is free/cheap http://blitzbasic.com/Community/posts.php?topic=50546 |
| ||
| Im currently doing just that. If you are actually using a real blade server or other serious server hardware and coding this as a dedicated server with no graphics then I also suggest using win blitz 3d and at startup hide the blitz3d window only showing the gui. Also if you emulate threading you will be so surprised just how blazing fast a blitz server on real hardware can be. I can crunch through 500 types against 500 types in about 8ms with never more than 8% cpu usage, with an average around 2% :) It can be done, but it requires you to know exactly how youre data is getting back and forth. If you draw out the exact flow of it and how youre going to encapsulate everything, it makes this process fly by when you actually go to develop it on a server. |
| ||
| Do you have any links or advice on emulating threading in the way you talk of? |
| ||
| Basically I have a thread count... every main repeat cycle I increase this value. I have a timing sequence setup that after so many millisecs it will process whatever thread the count is currently on. I build a queue to process these in a timely fashion after that. Basically everything occurs as an event that is time separated and queued. If the server has had free thread space left during the last few cycles it decreases the total thread count in order to queue more events. If the server starts to bog down it will delay the events longer. So rather than dealing with everything at once and while it happens, it gets spaced out to a load that the cpu is comfortable processing. Also using WinBlitz3d and K-Netlib for direct play communication over udp, as well as blitz. These three applications will exist on different threads. If using proper hardware on a real server they will execute independently of one another, yet still interact. This gives HUGE freedom of processor overhead, in order to deal with things such as search for many many type objects in any given event. Mainly because you have 98% free cpu to do it, and it will only take a few millisecs, meaning that even though incoming events are being queued it will still perform others and tick them off the timer. It was rather easy setting up actually. To sum it up, use timers that execute scripting, and queue everything :) Id post source but it would give away vulnerabilities in my server code, and pose a potential threat to this gave ive been working on for so long now. |
| ||
| Thanks you guys for the very good tip on RakNet, I've downloaded the wrapper and will investigate feasability. The idea is I want to send level information like this (only once per client) and control the game information like this. I haven't tought about chats and multiplayer, but that could be a nice possibility, depending on where I want to go with this and how it can come up. I definately got this idea long ago when I imagined a game that is server centric and that the player only has a "terminal like" client software. The extra possibility would be for some people to set up their own servers and have their levels set up in there, so as a client, you'd have a server list, like all the other games and figure out what interests you, probably a country based thing. But really, it's all in the air right now. |
   |