Tag Info

Hot answers tagged

15

From an API design perspective, when deciding whether to make multiple separate communicating programs or just one, the question is: can each program function meaningfully without the others? The answer will vary based on your project and preferences. If they can't, it's not worth thinking about. Clearly they're so heavily linked that they're not really ...


11

is it worthwhile to have a separate process that listens for connections and messages from clients and sends the data via local sockets or stdin to another process that runs the actual game server? To answer whether it is worthwhile, you had to first ask yourself, what is the problem you are trying to solve by adding a dedicated queuing service. If it ...


7

I'll try to answer to the best of my knowledge, with little knowledge about the specific case of UE4, but rather on the general technique. Graph based materials are as much programming as writing the code yourself. It just doesn't feel like it for people with no background on code, making it seemingly easier. So, when a designer links a "Add" node, he is ...


4

I agree with ratchet freak. As long as you have a single gameserver, it's not worth the trouble. However, this architecture might prove useful when you need to scale up horizontally. When one gameserver is no longer enough and you need to distribute your game on multiple gameservers for performance reasons, the "socket server" architecture could very easily ...


3

It probably isn't, most languages has asynchronous sockets that allow you to use multiple connections at a time without blocking while data is waiting. This shifts the "socket server" part to the OS/kernel. With an explicit socket server you will incur the cost of a few extra copies as you pass the data through the local socket; one thing that will kill ...


2

You can calculate snapshot delta (changes to its previous synced state) by keeping two snapshots instances: current one and last synced one. When client input arrives you modify current snapshot. Then when it's time to send delta to clients, you calculate last synced snapshot with current one field-by-field (recursively) and calculate and serialise delta. ...


2

I won't respond to each of your particular points, because I think that you're completely on track in your current thinking. You're right to be confused about how best to escape the couplings that you mention, but what you've got to realize is that, fundamentally, some couplings are inescapable. When module A depends on data from module B, we say that ...


2

This not claim to be a complete answer, but trust me I were in you, I tried to make a rendering engine with similiar choices etc. Decoupling is possible until you start incurring the cost of integrating togheter the decoupled components. If at logical level, there's coupling you just can't get rid of it in the code unless you can think a way to decouple it ...


2

In addition to the other answers about the extra work it presents, I will make two other points: As the game developer, you likely have control over the servers you're running. This means you can ensure your server meets the requirements necessary to run your game. Even if you let others run your server on their own machines, it's easy to say that they ...


2

If you shift the work to the clients, they have to do even more work than the server does. They will have to rewind the same way as each client sends their input to each clients and the rewinding will be done on double the latency (250ms (clientA->server) + 250ms (server->clientB)) as inputs are relayed over to the other clients through the server. The ...


2

You want the server doing lag compensation because that's its job. In a multiplayer environment, the client is in charge of graphics, and movement lag compensation (smoothness of movement). The server is in charge of physics, computations between players and objects, as well as lag compensation(assurance of accuracy). In the end, the server still has to ...


2

Yes, the standard approach is to have some kind of plugin API. The details of this approach will vary based mainly on the implementation of your overall toolset and the needs of your game and its tools. What you've described here is a reasonable first start at a plugin system for your own tools. It sounds like it works for you, so you should keep exploring ...


1

A design pattern I've enjoyed using has two types of things: task management and task execution. Task management asks the question "What should I be doing right now?" And task execution asks, "How do I complete the current task?" Task Managers The job of the task manager is to constantly look at the AI's internal state (read-only) to determine whether new ...


1

Just save the changes as the user plays? Am I missing something here? Either instantly (faster as you aren't saving the whole game at once, but the data adds up) or just regularly enough that you only lose a couple of minutes worth of data at a time (slower, as you have to save the entire game regularly, but uses less space) Or best-case, combine both - ...


1

The typical ECS way to handle this is to abstract a level in your systems layering. Your design looks something like this: render <--> transform <--> physics | / | / gameplay logic Anything that needs to know where entities are at will pull that information from the transform ...


1

If you only have a single SDL_Renderer, it should be managed outside of the ECS code and just passed to the rendering system when you call it to render the visual data for each entity. In this way it's like you are associating your single SDL_Renderer with all renderable entities. If for some reason you had multiple, differently configured SDL_Renderer ...


1

First you need to know how to represent your relevant data in a protocol compliant manner. This depends on the data relevant to the game. I will use an RTS game as an example. For networking purposes, all entities in the game are enumerated (e.g. pickups, units, buildings, natural resources, destructibles). The players need to have the data relevant to ...


1

It's primarily a technical issue that most companies won't use pure vector art in their games. I know many artists who make their creations in Flash or Illustrator, only to pump out a rasterized image that gets slapped on a polygon sprite. It's just a technical hurdle that most large companies aren't too keen on trying to figure out. Below is an example ...



Only top voted, non community-wiki answers of a minimum length are eligible