Hello I'm currently having a hard time with a project I'm working on.
It is a video game made using unreal engine 4 and i have to implement the network part on the project. So first of all, we have multiples pawn possessed by players, every player is allowed to spawn blocks(can be different type of blocks). We are currently using a Grid (an actor) that stores all the blocks in the world. We are using a GridManager ( an UObject) to manage the grid.
The GridManager can create AActor : BuildingAction, PushAction, FallingAction, and all others action that can be applied to any blocks in the grid. So i know that for spawning theses action and block i need to call RPCS from either the PlayerController or the pawn. The problem is that because the gridManager manages the grid and Spawn the actions on the world, the actions dont work on multiplayer. I guess spawning them in the player controller would work but it would need a function for every type of block and a function for every types of actions on the player controller, this would make no sense to store these functions on the player controller. If anyone could help me finding a good way to make this work on the network , it would be very helpful.
Related
What is the relationship between SDL_Joystick and SDL_GameController? These are the only things I know of right now:
SDL_GameController and related functions are all part of a new API introduced in SDL2.
SDL_GameController and related functions are built on top of the existing SDL_Joystick API.
(Working Draft) You can obtain an instance of SDL_Joystick by calling on the function SDL_GameControllerGetJoystick() and passing in an instance of SDL_GameController.
(Working Draft) You can obtain an instance of SDL_GameController first by calling on SDL_JoystickInstanceID() and passing in an instance of SDL_Joystick, then pass in the SDL_JoystickID to SDL_GameControllerFromInstanceID.
Even though SDL_Joystick and SDL_GameController are both interchangeable, it seems like SDL_GameController is here to replace and slowly succeed the SDL_Joystick.
Reason is, when polling for SDL_Event, the SDL_Event instance contains both the SDL_Event::jbutton and SDL_Event::cbutton structs, representing the SDL_Joystick buttons and SDL_GameController buttons, respectively. I guess I can use either one, or both, button events for the player controls.
I could be wrong here.
I would like to ask:
What are the differences between SDL_Joystick and SDL_GameController?
Is SDL_Joystick now referring to this controller?
And the same for SDL_GameController?
What are the advantages/disadvantages of using SDL_Joystick over SDL_GameController (and vice versa)?
First of all, SDL game controllers are the extension of SDL joystics (for the scope of this answer when I say "controller" or "joystick" I mean SDL's implementation, not hardware device category in general). As wiki says,
This category contains functions for handling game controllers and for
mapping joysticks to game controller semantics. This is built on top
of the existing joystick API.
If you are running your game from Steam, the game controller mapping
is automatically provided for your game.
Internally SDL uses joystic events and processes them to produce game controller events according to controller mapping. Hence one may say that joystic is lower level thing while game controller is a generalisation upon joysticks to produce more predictable/compatible (but more constrained) for games that wants gamepad-like input devices.
With game controller, you can program input for just one xbox-like controller thing, and SDL will make user's controller compatible with that (sometimes with the user's help - there are way too many different controllers, we can't possibly expect SDL to have configurations for all of them). Of course if controller is very different (or not controller at all - e.g. fly simpulation sticks, wheels, etc.), that would be problemmatic.
Basically game controller provides xbox-like buttons and axes for user side, freeing application developer from the need to support controller remapping - as remapping is done in SDL itself. For some popular controllers SDL already have builtin mappings, and for others user-defined mapping can be loaded via environment variable.
There is also a configuration tool that simplifies remapping for end user, including exporting resulting configuration to said environment variable. Steam also have builtin configuration tool, which configuration it (supposedly - I've never used that) exports to SDL - essentially making users themselves responsible for configuring their controllers.
I'm designing a component-based system and everything works well, but a critical feature is missing and that is to be able to obtain a type of component from within a class of type Object, whereof this class can be added/removed components. In the Object class there exists a vector of components thus:
vector<Component*> pComponents;
And in the Component class, a Component has to have a name. So, a component such as Drawable would be called like so:
pPlayer->addComponent(new Drawable("Drawable"));
And that's all that's required for the player to be drawable. Now this is the problem: when it comes to adding loads of components that rely on other components, is there a settlement in how components communicate with one another?
Currently, in my Game class (which is not of type Object, although I might have it derive from Object albeit not sure if that's a good design decision) I have this code in the update function:
void Game::update()
{
pPlayer->update(0);
pSpriteLoader->getSprite()->move(pPlayer->getVelocity());
}
I'm using SFML2 solely because it's easy to use for the 2D graphics. The player update function calls the components' respective update functions. And the sprite loader is also a component and it is in charge of handling the loading of sprites through textures/images that can be read from file or memory. If I were to omit this line of code then the sprite would not be able to appear moving on the screen. As you can see, it's odd that pPlayer has a getVelocity() function and it's because I haven't moved all the physics stuff into its own component. What is dreading is that once I have moved the physics stuff out of the Player class into a Physical component class, how can I get these components to communicate with each other without having to resort to the lines of code ascribed above?
My solution is to create a component manager which registers each component and any component that requires another component will have to consult with this component manager without having to do so directly. Would this be a viable solution, and how can I proceed with the logic of such a component manager then?
Well, I suppose you would start by designing a messaging system.
It appears that you want to heavily decouple code and create components as much as possible. This is fine, I suppose, but the answer to having dependencies without coupling is probably something among the lines of message passing.
Say you need an Achievement system. This is a perfect example of a system that needs to stick its hand into as many nooks and crannies as possible in order to allow for the greatest flexibility in designing achievements. But how would you be able to stick your hand into, say, the Physics, AI, and Input system all at the same time and not write spaghetti code? The answer would be to put listeners on event queues and then run them by certain criteria based on the contents of the messages.
So for each component, you might want to inherit a common message sending/receiving component, possibly with generics, in order to send data messages. For example, say you shoot a laser in a FPS game. The laser will most likely make a sound, and the laser will most likely need an animation. You will probably want to send a message to the sound system to play a certain sound, and then send a message to the physics system or such to simulate the effects of the laser.
If you're interested, I have a really, really crude library for modeling a event system based on queues, listeners, and generic messages here: https://github.com/VermillionAzure/Flexiglass You might get some insight from fellow newbie code.
I really suggest taking a look at Boost.Signals2 or Boost.Asio as well. Knowledge of signals/networking can often help when designing communication systems, even if the system is just between game components.
I've recently been working on an entity-component system in SFML and came across the same problem.
Instead of creating some sort of messaging system that allows components to communicate with each other I ended up adding 'System' objects to the mix instead. This is another popular method that is often used when implementing component systems and it's the most flexible one that I've used so far.
Entities are nothing more than collections of components
Components are POD structs and have no methods (e.g. a PositionComponent would have nothing more than X and Y values)
Systems update any entities that have the required components
For example, my 'MovementSystem' iterates through each of my entities and checks if they have a VelocityComponent and an InputComponent. If it does, it changes the velocity of the current entity according to the current key being pressed.
This removes the issue with components communicating with each other because now all you need to do is access/modify the data stored in the current entity's components.
There are a few different ways that you can work out whether or not the current entity has the required components - I'm using bitmasks. If you decide to do the same, I highly suggest you take a look at this post for a more thorough explanation of the method: https://gamedev.stackexchange.com/questions/31473/role-of-systems-in-entity-systems-architecture
I'm new to omnet++, and i need to write a simultaion of vehicle on a map.
i have a compund module called "Vehicle" which contains 2 simple module:
for movement (all the cars will move on a map)
for the communication between all the vehicle
Somebody know how to implement the movement part?
You could use the VEINS framework that provides all you need to simulate vehicular networks. Alternatively, the INETMANET framework also contains several mobility and wireless communication models.
Summary:
My 50% finished 2D sidescroller with Box2D as physics engine should have multiplayer support in the final version. However, the current code is just a singleplayer game.
What should I do now?
And more important, how should I implement multiplayer and combine it with singleplayer?
Is it a bad idea to code the singleplayer mode separated from multiplayer mode (like Notch did it with Minecraft)?
The performance in singleplayer should be as good as possible (Simulating physics with using a loopback server to implement singleplayer mode would be a problem there)
Full background / questions:
I'm working on a relatively large 2D game project in C++, with physics as a core element of it. (I use Box2D for that)
The finished game should have full multiplayer support, however I made the mistake that I didn't plan the networking part properly and basically worked on a singleplayer game until now.
I thought that multiplayer support could be added to the almost finished singleplayer game in a relatively easy and clear way, but apparently, from what I have read this is wrong.
I even read that a multiplayer game should be programmed as one from the beginning, with the singleplayer mode actually just consisting of hosting an invisible local server and connecting to it via loopback. (I found out that most FPS game engines do it that way, an example would be Source)
So here I am, with my half finished 2D sidescroller game, and I don't really know how to go on.
Simply continueing to work on the singleplayer / client seems useless to me now, as I'd have to recode and refactor even more later.
First, a general question to anybody who possibly found himself in a situation like this:
How should I proceed?
Then, the more specific one - I have been trying to find out how I can approach the networking part for my game:
Invisible / loopback server for singleplayer
This would have the advantage that there basically is no difference between singleplayer and multiplayer mode. Not much additional code would be needed.
A big disadvantage: Performance and other limitations in singleplayer. There would be two physics simulations running. One for the client and one for the loopback server.
Even if you work around by providing a direct path for the data from the loopback server, through direct communcation by the threads for example, the singleplayer would be limited.
This is a problem because people should be allowed to play around with masses of objects at once.
Separated singleplayer / Multiplayer mode
There would be no server involved in singleplayer mode.
I'm not really sure how this would work. But at least I think that there would be a lot of additional work, because all of the singleplayer features would have to be re-implemented or glued to multiplayer mode.
Multiplayer mode as a module for singleplayer
This is merely a quick thought I had. Multiplayer could consist of a singleplayer game, with an additional networking module loaded and connected to a server, which sends and receives data and updates the singleplayer world.
In the retrospective, I regret not having planned the multiplayer mode earlier. I'm really stuck at this point and I hope that somebody here is able to help me!
I think Notch is feeling the pain of developing SP and SMP separately. Especially since he told the Bukkit development team that he was planning to transition to the "local server for single player" approach (As you said, like the Source Engine.)
There is no reason you have to have multiple physics simulations running, the latency between the local server and the client would be negligible, the lag compensation could be completely disabled.
There are two basic models you could go off of at this point:
A dedicated server program which does all the brains of your game and lets clients connect.
A listen server where a game can basically act as a server or a client depending on the user setting. There is no separate server program.
The easiest way to make a client would be to add "dummy" flags to your objects so those dummies will be controlled directly by the server. Then, move into the interpolation. (Transmitting object updates at 60 Hz is unrealistic, so smoothing between points makes things still look nice. Source does this by adding a little artificial lag, if you've ever played GTA4 Multiplayer on a sub-par internet connection you can see the effect being overdone on fast cars.)
Also, recommended read:
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
You could use the dumb render terminal approach. The advantage is that it's relatively easy to integrate without designing it into your engine from the start. The disadvantage is that latency won't be compensated using prediction techniques, and if there are many visible objects the bandwidth might be high.
One idea is separating the game-state and its evolution from the graphic. So each frame you translate the game-state into a graphic representation (culling offscreen stuff). Then in single-player you render that directly, and in multiplayer you send that graphic representation over the network. And sent the input over the network to the server.
How well that works depends on the number of drawn objects and how complex their graphic description is. But that description is usually rather small for 2D games.
I expect this to work well in a LAN since that has good latency and bandwidth. No idea how well it works over the internet.
Here is a document describing how the unreal network code works. And in the introduction in describes several simpler approaches. You might want to implement one of those.
http://unreal.epicgames.com/Network.htm
I'm making a game engine in c++ and python. I'm using OGRE for 3D rendering, OpenAL for sound, ODE for physics, OIS for input, HawkNL for networking and boost.python for embedded python interpreter. Every subsystem (library) is wrapped by a class - manager and every manager is singleton. Now, I have a class - Object - this could be every visible object in game world. This is some kind of mix, object has graphics representation (entity) and representation in physics simulator (solid). These two are most important here. Class Object is just pure abstract base class - interface. I've decided to implement Object on client side as ObjectClientSide - this implementation has the entity, and on server side as ObjectServerSide - this implementation has the solid. Physics simulator runs only on server, and rendering is done only on client of course. The object can exist only when both implementations are working together. Every object has unique id and both instances of the same object on client and server side have the same id.
So, after this short background, my first question is: is this design good? How can I make it better? And the main question: how should I synchronize these objects?
Next, both implementations have the same interface, but part of it is implemented on server side and part on client side. So, for example, if player wants to move forward his character he should send a request to object on server. The server then makes changes to simulation and sends updated position to client. For that reason, I've created small messages framework. There is a Message class, Router, Rule and rules inherited from Rule. When message arrives, Router checks it against the rules and sends it to destination. So, when I call myObjectInstanceOnClientSide->setPosition(x,y,z) this object creates Message, its content is function and parameters and destination is object with the same id on server. When object with the same id on server side gets this message it calls this function with given arguments. So, when a function can't be implemented on one side it creates a message and sends it to object on the other side. I think this can be very useful in scripts. Scripts can be very clean, if script needs for example turn on animation on clients, I only need to call this function on server's local object - the rest is in background.
So, is this ok? Am I wrong about this? It this common solution?
It sounds like you would be sending a lot of tiny messages. The UDP and IP headers will add 28 bytes of overhead (20 bytes for the IPv4 header or 40 for IPv6 plus 8 bytes for the UDP header). So, I would suggest combining multiple messages to be dispatched together at a perioidic rate.
You may also want to read these other questions and answers:
Dealing with Latency in Networked Games
Real-time multiplayer game (concept question)
I added a bunch of useful links to the DevMaster.net Wiki years ago that are still relavent:
Networking for Games 101 FAQ
Multiplayer and Network Programming
Introduction to Multiplayer Game
Programming The Quake3 Networking Model
Unreal Networking Architecture
Networked Physics
Beej's Network Guide
I'd suggest starting to read Glenn Fiedler's blog. He's done some incredibly work with networked physics including the recent Mercenaries 2 release. He started a series of articles called Networking for Game Programmers.