Networked FPS game

Hi,



I have been experimenting with JMonkey with the aim of creating a networked FPS game. The reason I did this is because I have always been interested in how games like HL2 and battlefield 1942 present such a fast paced world in a networked environment. I have not done any networked game programming before, or used JMonkey, so it is all a learning curve, but I would like to share, and hopefully get some ideas and/or collaboration, so I have set up a google code project with my stuff in.



http://code.google.com/p/networked-fps/



I have some ideas on where I would like the game to go, but that is not my current aim. My aim is to get the ‘framework’ to the point where it is usable over the internet for, hopefully, 16 v 16 gaming. If people want to help, and design a completely different game, they will get no arguments from me!



So far I have implemented the following ideas:



An authoritative server architecture (the clients cannot be trusted).

Client side prediction (using bullet physics on the client and server)

Interpolation

Time lagged shooting (shoot at where they are, not where they will be when the message gets to the server).



The catch on all this is optimization - it is not very! There is a lot that needs to be done to get the message content compressed, only send messages when required etc. As it is now I have ‘played’ with 4 people connected over a LAN without any issues. I recon I could cope with around 8-10 if the server was on a seperate machine. I have not tried in the laggy world of the internet yet!



This is very much a W.I.P and there is an awful lot to do (and since I have not been working with JMonkey for long probably a lot of what is done could be better!). Top of my list are:



The entity manager is a complete mess…and the players can only be cubes! The logic is in place to load models etc, but I haven’t finished this off and need a model or 2 to work with. Vehicles would be nice as well…

The client and server code needs to live in its own manager; this will help out with the entity manager as well!

Optimization of messages (as above). Not fussed about other optimization yet!

Actual game logic. Firing pretty lines looks nice but currently there is no actual behavioural code when a hit is recorded (you get a message in stdout on the server though…)

The logging is awful. Currently everything is pumped to System.out and doesn’t use proper logging. It is all commented out for now.

When a client disconnects no other clients are notified and its connection is not cleanly disposed off when the GUI is closed.

There is no gui overlay.

A lot, lot more…



I only have a very limited amount of time I can work on this. Normally an hour at lunch and maybe an hour or 2 at the weekend. This is why I do not want to dictate where this should go; that should be up to the people that contribute.



Ok, onto the actual stuff…



The code should work as a standard JMonkey project. The server (GameServer) will launch headless and the client (GameClient) will connect to this. There is no nice code for this at the moment, launch the server first.



Upon connecting your cube will appear suspended in the air. Clicking fire (space or mouse) should cause you to fall to the ground and you are off. Look at the code to get the keys. H will toggle between 3rd and first person. Oh, the 3rd person camera isn’t set up to chase at the moment. And that is it. Thoroughly unexciting but if you put the rewind tolerance really low and switch on the logging in the if statement you will, hopefully, be amazed at how in synch the client and server movements are!



Matt

6 Likes

Right. Over lunch I have put together the next 5 things I will get done with this project. These are not necessarily the most important, just the next ones!


  1. Get the entity manager loading actual models. Does anyone have a sample model (perhaps with skinning?) available to use as an example? Ideally a soldier, or robot. Not a cube though, if possible :slight_smile:


  2. Ge the clients disconnecting properly. And starting in different locations, probably on the ground.


  3. Get a basic gui overlay indicating health.


  4. Limit fire rate and record damage when a shot hits - represent this on the GUI overlay


  5. Add a vehicle…



    The top 4 will allow the game to be played - an important step in any game!



    The 5th one will start moving down the route of player controlled vehicles. And no doubt cause major headaches for my synching code. I need something to keep me awake at night…it might as well be why after 3000 ticks my clients and servers start diverging.



    Any modellers out there want to help out. I enjoy modelling (I helped make Blender open source, dontchaknow - not with code or anything, but with money!), but suck at it…



    Matt
2 Likes

Great contribution! @normen has the details, but I think this is the sort of “framework” that we’ve envisioned to be “SDK pluggable”. By that I mean, this could be the start of a special plugin collection in jMonkeyPlatform, where users could download starter-packs for popular genres, i.e. FPS, action-RPG, RTS etc.



I think it will be very interesting for users to see network code written especially for an FPS game (particularly once it’s optimized, he he), as sometimes saying “one size can’t fit all” is not convincing enough. There are going to be questions about why you are not using SpiderMonkey, so it’d be good if you could elaborate on that.


mattm said:(...) Does anyone have a sample model (perhaps with skinning?) available to use as an example? Ideally a soldier, or robot. Not a cube though, if possible :)

I'd recommend just using the default OgreXML Sinbad model for starters. It should just work, and it's a pretty advanced model too, so it might show you a thing or two about good practice.

p.s. Your post would be much less prone to "tl;dr" if you moved the bulk of the information (especially the changing parts, like what's done and not) to the networked-fps frontpage/wiki on GoogleCode.
1 Like

Definitely thumbs up for this one, yeah… The simplest form of what we thought of would be MonkeyZone a bit stripped down as a SDK project template including some template files for new controls, ai actions etc.



Of course the fact that the structure would be premade allows for more plugins that alter data, e.g. a configuration panel for the game project that includes game specific options like “use AI type X” or “physics framerate” by using properties files in-game(-template).

Things to ponder about are what one wants to have as “closed” libraries (e.g. for pathfinding etc.) and what should be available as source code directly in the template project… We should try balancing this so it will appeal to noobs as well as experienced users.



So yeah, I probably wont give too much input on the “how” as I am mostly occupied with getting MonkeyZones “how” to work :wink: but ask me when you are unsure on how to go about a certain aspect of this, if this goes nicely you might supply the first template for hundreds of jME3 games :wink:



Cheers,

Normen

I am using spidermonkey, maybe not correctly, but I am using it :smiley: I don’t think there is any problem with spidermonkey (beyond those which are known) but I think there is a lot of optimization on the game side that can reduce network traffic and it is this I probably need to focus on w.r.t FPS logic.



Nice idea about the wiki. I will set up as soon as I have a moment and move my todo list to that. This is the first time I have open-sourced any code (and used googlecode) so I am a little unsure about what goes where with it, but the wiki looks straight forward enough.



Matt

mattm said:
I am using spidermonkey (...)

D'oh, looking properly at your code I can see that now, sorry for the confusion. That's cool too; the recently overhauled networking system (by @pspeed ) will use all the feedback it can get.

Just a quick message to say that I have added a wiki page detailing the next 5 things that will be done. This is a rolling list; I find 5 enough to keep momentum but not too many that focus on what is being done gets lost.



From now on updates will only appear on the Wiki. This post will be reserved for milestone updates, previews etc.

2 Likes

wee

You did the right thing 8)

Just a quick update.



This is still progressing. Still don’t have a lot of time on it but some important progress is being made:


  1. Moved to the new spider monkey code. Works great.
  2. Not far off this sort of being playable (people only, no vehicles yet :frowning: ), at which point I will try and set up a server and get some testing going for performance etc. Hopefully by the 21st (2 months after I started).



    What I am really after is a well animated character with walking, ducking, jumping, firing and reloading a weapon. The model does not have to look good (even just tubes and rectangles) as long as the animation is fluid and complete. I am currently using the Ogre model from the Ogre3D project, which works great but does not have all the animations I would like (firing and ducking, for example). it also has a few too many bones doing stuff I don’t need (eyes etc).



    Bear in mind my project is open source, so your work will have to be too. Also, there are no real financial rewards, but you will of course be credited.



    Other help:



    I did have one person wanting to help, but I guess his studies got in the way so he hasn’t been able to commit anything yet. My code is a bit messy at the moment and mostly in my head so coding help on the core logic is difficult (but not unwelcome). However, Nifty work (I need a TF2 type UI!) is desperately needed!



    Matt

Unfortunately due to commitments at work and eleswhere I am going to have to abandon progress on this project.



I was wondering if anyone wanted to take on ownership of this before I remove it from googlecode? I would love to have seen it to some form of completion but realistically this is not going to happen in the near-term (next couple of years at least).



Matt

I don’t mean any disrespect to your hard efforts, but in my experience, ‘transferring ownership’ only works when the project in question is being actively used (i.e. usually a tool) by others, so a combination of investment, necessity and passion already present in other developers drives the project further. jMonkeyEngine and WordPress are successful examples. Radakan (an early project by me, Momoko_Fan and many others) and a thousand other WIP games were not so “lucky”.



Best case scenario that I can see: MonkeyZone sparks into active development again. This would create a lot of the (dare I call it “boilerplate”?) code necessary to springboard a project such as yours. I might make some threads about it soon, if time between studies allows it.

You’re gonna close down the code.google repo?

No disrespect take at all. I guessed that there would be no takers but felt obliged to offer it out before putting it into hibernation.



I will archive this into my storage area for now and if anyone wants a copy then just drop a message here. I may work on it from time to time, but it will be so slow as to not bother tracking progress really!



Matt

I was thinking about taking my name off the owner of the project. I will need to check what happens in this situation; I think the repos remains but need to check to be sure.



Matt