Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

100 Neutral

About Tehforsch

  • Rank
  1. We have been rewriting the entire game engine completely so this is not very accurate but this is some sample code from the last version of the game: Some of the code for the server: private Vector<Package> createSyncPackages() { Vector<Package> packages = new Vector<Package>(); if(this.world == null) return packages; for (int i = 0; i < world.numBodies; i++){ Body b = world.getBody(i); Package p; if (!bodiesOnClient.contains(b.id)){ p = new Package(Name.ADDB, Savegame.create(b)); bodiesOnClient.add(b.id); } else{ // Synchronize body if (b.hasToBeSynced()) p = new Package(Name.SYNCB, b.createSync()); else continue; } packages.add(p); } for (int i = 0; i < world.numJoints; i++){ Joint j = world.getJoint(i); Package p; if (!jointsOnClient.contains(j.id)){ p = new Package(Name.ADDJ, Savegame.create(j)); packages.add(p); jointsOnClient.add(j.id); } else if (j.hasToBeSynced()){ p = new Package(Name.SYNCJ, j.createSync()); packages.add(p); } } for (Integer k : bodiesOnClient){ if (!world.containsBody(k)){ Package p = new Package(Name.REMB, Package.getBytes(k)); packages.add(p); } } for (Integer k : jointsOnClient){ if (!world.containsJoint(k)){ Package p = new Package(Name.REMJ, Package.getBytes(k)); packages.add(p); } } setClientCam(packages); return packages; } And some of the code for the client: private void handleReceivedPackage(Vector<Package> packages, Package r) { Name name = r.getName(); byte[] data = r.getData(); switch (name) { case ADDB: Body b = Savegame.loadBody(data); if (!world.containsBody(b)) world.addBody(b); packages.add(new Package(Name.RECADDB, Package.getBytes(b.id))); break; case ADDJ: Joint j = Savegame.loadJoint(data); if (!world.containsJoint(j)){ world.addJoint(j); } packages.add(new Package(Name.RECADDJ, Package.getBytes(j.id))); break; case REMB: int id = Package.getInt(data, 0); if (world.containsBody(id)) world.remBody(world.getBodyById(id)); packages.add(new Package(Name.RECREMB, Package.getBytes(id))); break; case REMJ: id = Package.getInt(data, 0); if (world.containsJoint(id)) world.remJoint(world.getJointById(id)); packages.add(new Package(Name.RECREMJ, Package.getBytes(id))); break; case INIT: World w = Savegame.loadWorld(data); world = w; packages.add(new Package(Name.RECINIT, new byte[0])); break; case SYNCB: id = Package.getInt(data, 0); world.getBodyById(id).sync(data); break; case SYNCJ: id = Package.getInt(data, 0); world.getJointById(id).sync(data); break; case SETCAM: id = Package.getInt(data, 0); centeredBody = world.getBodyById(id); packages.add(new Package(Name.RECSETCAM, Package.getBytes(id))); break; } } Note that the REC... packages are sent from the client to the server to acknowledge that the client received the corresponding package. If the REC... did not arrive for some amount of time the package would have been sent again. The server is constantly keeping track of the objects that the client has actually received (by their unique id) and whenenever an id is missing, an ADD... package is sent, if an id is on the client but shouldn't be (the object has been removed) a REM... package is sent. This code actually worked quite well, but I have to add that we didn't actually synchronize any of the game code. The client was just a standalone physics/graphics engine and would only display and simulate the world, not know what was happening. That way we only had to synchronize the physical world and some graphical attributes like the camera position etc. This was more or less just a test to see if it was possible to have the game logics running only on the server since that would have saved a lot of effort. We had a version where the game was send to the client, but except for initializing the objects on the client we were never really able to make it work. Thanks, Tehforsch
  2. [color="#1C2837"]What you want is a library for marshaling/demarshaling. There are many different approaches you can take.[color="#1C2837"]What you need to do is three things: 1) Make sure you can pack messages into packets such that the remove end can unpack the messages -- typically, this is a byte or two of length information per message within the packet. 2) Make sure that you can tag each message so that the remote end knows what particular code should receive that message -- typically, this is a byte or two of object ID, where "object" may be a player avatar, or a subsystem (such as the ammunition manager, or whatever) 3) Make sure that you tag each message such that the receiving code knows what to do with it -- typically, this is a type code of some sort. One way of approaching this is to build marshaling on top of reflection. Unfortunately, C++ does not have reflection, so you'll have to add it yourself. A few articles on this subject: http://www.enchanted.../cpp-reflection https://github.com/j...-and-Properties (code for my article in Game Engine Gems 2 about this) [color="#1C2837"]http://www.enchanted...2-introspection[/quote] Hi, thanks for your reply. We were doing something similar to this in our previous version (luckily we are using Java, so serialization and reflection are both available, thanks for the links anyways!). We had a working version were the initial state of the game could be loaded on the client, and objects could be added by the server. The main problem I had was how to write the code that synchronizes the changes in game objects for all clients. We have game-object structures that contain a list of physical and graphical properties as well as game logic code. We were able to get the parts of the engine (physics, graphics) across the network but we never found a way of writing nice code to synchronize the varying game logic of each object. But it seems like there is no way around writing separate code for each object? Most objects are just crates or bullets anyways and don't really need any synchronization but there are others like the player figure itself which consist of a lot of attributes and whenever we wrote new code for the player we had to extend the synchronization code aswell, which was kind of annoying. This is what we did in our previous version. What I had most problems with is - in your code example - the "otherUpdates" part. how exactly do games with a lot of code create those? Is there any way around writing individual sections for each object that you create? Thanks for your replies, Tehforsch
  3. Hi, I am the other developer on this project and I'd like to add something: I've read the articles on gafferongames.com (which were mostly on the topic of physics-engine synchronization) and some other articles which were really quite helpful but we both wondered why there never was any real discussion about how the data that is sent over network is created in the first place. We just found it to be a lot of effort to write the code that creates Strings/bytes for every object in the code and additional code that deciphers it and converts it into real data and even more "annoying" to always keep that code up with the current state of the game. We find it kind of hard to imagine that no one else has come across this problem, but we couldn't seem to find any real articles or presentations about that topic. Thanks in advance, Tehforsch
  4. Tehforsch

    RohXel - a physics based 2d shooter

    I actually remember having played Gusanos before, but that was long ago. I'm gonna have a look at it, thank you :) Tehforsch
  5. Hello, At first I want to introduce our game RohXel. Basically it is just a shooter in 2D, but it is based on a physics engine I wrote so everything ingame is based on physics. This makes it more interesting to play since sometimes unpredictable things can happen. The basic concept of the game is nothing new, its just a shooter, you walk around in sideview, controlling a ragdoll with a weapon or something else in its hand, shooting at other ragdolls. Great! To enhance this whole thing a bit we tried to introduce some weapons and features that don't exist in every second shooter: For example we just implemented a rope-thrower (remember worms ? ;)). You can swing around and make acrobatic moves with your figure, always trying to land back on your feet so you don't die. Since we have a nearly completely dynamic environment, you can also use this rope to pull a crate or some other obstacle to you, making your way free. You could also use it to pull the other player into the abyss, but you'd have to watch you don't suffer the same fate. This can be seen here: Youtube Rope Video The player also has a weapon that shoots little bullets "black holes" that pull everything to them (ok, this isn't really anything special, i think this times it actually exists in every second game) and after a short period they explode and push everything away. These little bullets are attracted by your mouse so you can shoot them and then guide them directly to your opponent who will then have some of the objects around crush him. Although it may not be that creative, it is still really funny to do. Our problem at the moment is that we are a bit in a lack of ideas. With our graphics and physics engine we are able to make a lot more than what we do at the moment. We don't really use the potential of the engine and we think that our game could be quite fun to play if we had some more game ideas. We thought about creating a game mode, where one of the teams sat on a hill or in a house or something and had to defend it for a definite amount of time while the other team has to attack it. Of course this is not something really special, but considering the possibilities of a physics engine you could for example take objects lying around and build yourself a bunker to make it harder for the other team to get in. I can imagine that to be pretty fun and we will definitely give it a try as soon as we have our network code running (I don't think we can make an AI so clever that it would be fun to play this game mode against it) We also considered to do something completely different from a shooter. (additionally to the normal game mode) We had the idea of some kind of a module-based vehicle. It would have a brain from which you could control it. Attached to the brain would be other modules, like engines, shields, energy providers, different turrets etc. Each player could then build its own vehicle before the game and then fight other players with it. But we have temporarily discarded this idea since we want to concentrate more on the original game "idea". To cut a long story short: If anyone here has any idea on what we could try to implement to make the game funnier, we would be really pleased if you'd share it with us :) Just for a quick look on how the game looks: Example video (ok this is a bit exaggerated, it doesn't always look like that :) ) If anyone is interested in playing it (or maybe even looking at the source code, it is open source): You can download it from RohXels Google Code page RohXels Blog (in german): RohXels gameblog Thanks in advance, (and excuse my English, I'm German) Tehforsch [Edited by - Tehforsch on June 22, 2010 4:41:29 PM]
  6. Hello, I am currently working on a game called rohXel which is (hopefully) going to be a 2d-physics-based shooter. I was writing a simple AI that could move to a target in the world by walking and jumping. To do this I implemented a system that reads walkable segments out of the actual physical world (the bodies etc) and after that finds connections between them if it is possible to jump. After that a simple A* search is done to find the path and than that path is given to the walking mechanism. Heres a video that shows it in work: (Its a bit old and the walking and jumping is much faster and smoother at the moment but I dont have a newer video, there is also no moving body for the AI to walk on, although it would work.) The problem is the performance : The second step, finding the connections, takes a lot of time since it grows with O(n^2) which slows everything down a lot when it comes to a large scene. I made the obvious optimizations such as : 1. Not recalculating static bodies 2. Not recalculating sleeping(ergo not moving for a period of time) bodies 3. Only looking at the jumps between two recalculated segments. (I also only walk on bodies with larger masses since the lighter ones can just be pushed away) Since all these things are just a factor and not slowing the growth of the computing time I thought about implementing some kind of Sweep and Prune algorithm, as I use it in my physics engine for the "overlapping" segments between which jumps need to be found. Do you think this could help me with my problem or do you see any problems concerning that? Appreciating any help, Tehforsch
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!