• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
ProtectedMode

Preventing code duplication

7 posts in this topic

I'm working on a multiplayer game using C++. I've also worked on multiplayer games in the past, but one of the thinks I like to prevent is code duplication... But it seems that I still haven't found a good approach for that and I couldn't find much about it on the internet. As the server I'm writing is fully-authorative but the clients still need to interpolate, they both need most of the data. Except for the drawing obviously; the server should not have vertex data or textures in memory, and even better would be not to even have a draw method at all on the server.

 

One of the possibilities I could think of was just creating similar but different classes on the server and client. There is however much code duplication involved here. The other possibility I could think of was using the same classes but using macro's to disable the drawing-related code on the server. This may even be a worse approach because it's hacky, ugly, hard to maintain and a lot of other things.

 

I'm interested in how more experienced people would tackle this problem, or is it just an ugly part of network programming?

0

Share this post


Link to post
Share on other sites
The short (i.e. rude) answer is to keep practicing OO ideas, such as SOLID, as this would mean the logic and drawing code would be more easily separated ;-)

How is your drawing and update logic currently handled? How do they communicate? Do you have something like the classic -
class Entity { void Update(); void Draw(); }; ?

Are there any cases where you need some of the graphics data on the server, such as animated skeletons with bounding/hit boxes or attahment points?
1

Share this post


Link to post
Share on other sites

The short (i.e. rude) answer is to keep practicing OO ideas, such as SOLID, as this would mean the logic and drawing code would be more easily separated ;-)

How is your drawing and update logic currently handled? How do they communicate? Do you have something like the classic -
class Entity { void Update(); void Draw(); }; ?

I'm currently doing something like that, mainly because I prefer keeping it simple and because the players are the only dynamic entities for now. Do you have any concrete ideas about separating the update and drawing code here? I thought of ECS but isn't that a bit overkill or is that the way to go in this scenario? Does anyone know another preferbly OO way of dealing with this problem?

Are there any cases where you need some of the graphics data on the server, such as animated skeletons with bounding/hit boxes or attahment points?

No, I don't need any of the graphics data like that on the server.

Edited by ProtectedMode
0

Share this post


Link to post
Share on other sites
Actually, OO in itself is not always the right solution. You could just as well express the same functionality as free functions working on typed data structures, and if you do that, the linker is better at stripping out the parts you don't use.

If you have to use object oriented classes, then you can decompose your objects into multiple smaller classes, and use aggregation to include the "bits and pieces" that you need on server versus client. Thus, you'd have separate "entity factories" on client and server, where the client-side factory created the player object with user-derived input, and created all objects with rendering components, and created all non-player objects with network-derived input. On the server, all objects are created with network-received input, no rendering, and authoritative data output over the network.

In general, if you stick to OO, an object/component structure will let you re-use the parts that make sense between client and server, while attaching other bits and pieces that only make sense on one or the other. As long as you keep a strict interface (pure abstract base class) between the objects/components and their dependencies, this will work out well.

I'd highly recommend the libraries-with-data-structures approach, though. This lets you still re-use code, by calling the appropriate functions on the appropriate data in the appropriate context.
1

Share this post


Link to post
Share on other sites

You could just as well express the same functionality as free functions working on typed data structures, and if you do that, the linker is better at stripping out the parts you don't use.

By the time it gets to the linker, it's exactly the same either way (assuming the equivalent code is written in both styles)...

Yeah there's some counter-examples, such as if you use virtual functions, they'll not be discarded... but this is a straw-man, because the same would occur with free functions if you wrote the equivalent code that manually created a table of pointers to functions (i.e. the function's who's addresses you capture will also no longer be discarded).

I thought of ECS but isn't that a bit overkill or is that the way to go in this scenario? Does anyone know another preferbly OO way of dealing with this problem?

The core of ECS is "composition" -- the core of OO is also "composition" (if you look up "inheritance vs composition" you'll find that OO teaches that you should default to using composition, and only use inheritance where necessary, which is not often). Under both those paradigms, you break your code up into small pieces which each only solve a single problem at a time, and then build complex parts by composing simple parts together.
 
Many ECS articles compare themselves against the "incorrect" OO styles, usually "deep inheritance" entity hierarchies, where inheritance has been completely over-used, and then offer ECS as a solution to that problem. I've never seen an ECS article that compares ECS against proper composition-based OO though laugh.png

Do you have any concrete ideas about separating the update and drawing code here?

This is pretty vague, but move all the drawing code out into classes that only do drawing stuff. Don't have game logic and graphics structures intertwined.
You can actually have two completely different worlds/scenes/collections of objects -- one list of game objects, and another list of graphics objects. The update part of your game loop can do stuff to the first list, and the draw part of your game loop can do stuff to the second list. The server can just not create or use the second list. On the client, the game objects obviously need to do stuff to the graphics objects (such as move them around, etc), so the items in the first list can contain pointers into their 'partners' in the second list, but on the server these pointers can just be NULL.

2

Share this post


Link to post
Share on other sites

Thank you both for your answers! I think I will go with the ECS because of how dynamic it is, but I am aware that it's actually some kind of dynamic composition.

0

Share this post


Link to post
Share on other sites

the same would occur with free functions if you wrote the equivalent code that manually created a table of pointers to functions


The point is that, in most languages, the resistance to creating arrays-of-function-pointers is high, but the resistance to creating a virtual member function is low, so the different styles tend to lead to different outcomes in practice. I kind-of like the idea of Haskell here: If you use something polymorphically, the compiler will figure it out and make it that way for you. If you don't, it won't :-)

I've never seen an ECS article that compares ECS against proper composition-based OO though


Another way to slice that: An ECS is one way of properly decomposing an OO design.

Something I've found with components is that each kind of component has its own little "world" or "scene graph." The physics components end up going into the physics system; the graphics components end up going into the graphics system; the networking components end up going in the networking system; etc. This means that you'll likely have multiple spatial indices in your game, because the kind of kd-tree/octree/cell-portal-graph/quadtree/boundary-metric-tree/hash-grid used for one of those use cases is often not well tuned for the other use cases.

In the end, an "entity" just becomes a loose bundle of separate "components" that each belong to a separate subsystem, and only some very basic information is promoted to the entity level (object id, world position, set of components.)
0

Share this post


Link to post
Share on other sites

You have to estimate how much the code really overlaps, how intertwined it would be with non-overlapping code.

Add to that the likelyhood of it (code) having to be later modified.

 

I found that for the type of game operations I worked on  the overlap often was relatively minor/simple (even the collision stuff)  and could be procedurized into a common library file (#include files), or was just inlined and commented to make it obvious it had a similar functional block on the other program (client vs frontend server vs AI node) .  Trying to do tricks with mutating code in the same file (via #ifdef macros) just obscures/complicates things

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0