• 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.

Archived

This topic is now archived and is closed to further replies.

BeanDog

Many questions from a non-multiplayer programmer

5 posts in this topic

I have only vaguely tried to do Multiplayer before (years ago, in QB via serial cable) and I have a question. With an RTS I plan on doing multiplayer, do I have to transfer all the unit data each frame, or what? How did StarCraft handle the load? How would I sync the units on the computers? would I have to wait for a message to be sent back and forth that the computers are done with each frame before either goes onto the next? That would limit the frame rate to the slowest computer... ~BenDilts( void );
0

Share this post


Link to post
Share on other sites
I don''t know how starcraft was done but I believe warcraft II was done being syncing all players to a frame or set of frames (grouping say 1/4 of second worth frames as one). All players waited till there was a ping to go to the next set. Whenever units where ordered to move (or buildings build or etc) the order was first sent to all players, when all players have reponded the order is implemented the beginning of the next frame set. Since all players are running with the units recieiving the same orders at the same time the games (assuming there all the same version) will stay in sync. You could also add a sync check every 5 or 10 seconds that includes a check sum for all the units and values in the game. If any of the check sums don''t match the game is out of sync (due to lost player, packet or bug in the code) and that information must be placed back into sync.
0

Share this post


Link to post
Share on other sites
So, like 5 times a second I would pass information around all the players'' computers concerning what units have changed direction, what damage has been dealt, and such like that. But that could really quickly get out of sync, for instance if I passed an integer for which creature did something, and it died halfway through a frame, that would rearrange the #s, messing up all the computers. Hmmmmmmmm.......

0

Share this post


Link to post
Share on other sites
I think the most common method is to synchonize user events, such as moving and ordering units to do things. Random variables are synchonized when the game begins so all calls to rand() will result in the same random number. Breaking it down this way you can save on bandwidth as user events are not too large. You''ll need to synchonize or the least verfiy that everyone is alive, every update, though. This will result in the game running at the speed of the slowest computer + worst lag. Lag, latency and drop, will further reduce your update rate, not frame rate as you can use interperlation so everything atleast appears to be smooth.

There is another method you could use, its the server-client model. The above method is a peer to peer method and doesn''t scale well, however is very robust for small set of players. With peer to peer starcraft can synchonize games with over 200 characters moving on each side over a 56k modem in a 4 player game. Unless your planing on supporting over 16 players or your gameplay is very senestive to timming (in the 50ms range or less), you proably want to stick to peer to peer.

Good Luck

-ddn
0

Share this post


Link to post
Share on other sites
Remember, whoever posted that last message, that with client-server if the host of the game got disconnected (as often happens in sc) then that would be the end of the game. I guess there may be a way to make someone else act as the server if this happens... I do think that the client-server model is a very valid architecture for games though. It is a lot easier to stay in sync when everyone is pulling their data off of the same source. Distributed networking is cool too though...
I know that starcraft uses UDP. It seems that this would make it more difficult for the games to stay in sync. Things can get lost with udp and no one would ever know.

-BacksideSnap-
0

Share this post


Link to post
Share on other sites
I think I''ve got the concept down for client-client. Every, say, 1/5 of a second (or whatever) I would have every computer send messages out and then wait until it received enough messages to account for the other computers. The only messages I would really have to send would be small, indexed ones like

MSG_NewShot / MSG_MachineGun / MSG_Player1, or
MSG_NewUpgrade / MSG_Ammo / MSG_Napalm

You see, I only have to send info for when something is created or a user does something - all movement and collisions would be handled by each computer individually. The above examples would be used with, say, an __int64 flag variable, providing plenty of room. I could even have some MSG_''s overlap if I structured it right...

Also, of course, I would have to check each 1/5 of a second that each computer has the same # of each item - be it units or whatever. So in the end I would end up transferring only at most about 1K per second for a simple-type game, maybe as much as 10-15K per second in an RTS.

Only problem with that would be I would have to remove all queues that are emptied based on computer speed (pathfinding, etc.) to make sure that all the computers'' units are moving exactly the same way.

This could be a complicated beast.

~BenDilts( void );
0

Share this post


Link to post
Share on other sites