🔒 Locked

Diving into game programming....head first

Started by DreamCPP Sep 13, 2010 at 3:39 AM 8 replies 2.1k views

Original Post

Sep 13, 2010 at 3:39 AM

Hello, its been a while since I have done any real programming. Especially dealing with games. The last attempt was console apps in c++ which turned out nicely but that was years ago. Lately Ive been disappointed with the games Ive been playing and thus sparked the research Ive been doing in recent weeks. I have fundamental ideas as to what is involved in a full featured multiplayer game. Heres where Im technically at a loss. I know there are various...for lack of a better term...components of a game that I will need to tackle but for me its like having a bunch of puzzle pieces without knowing how they fit together or even if I have them all. So here goes.
Graphics
Networking
Physics
Input
AI

These are the obvious and basic ones I can think of. Ive been working with the Irrlicht graphics engine which is user friendly and nice. Raknet is my choice for networking although it will take a bit more learning. Physics will have to wait until I understand how the data will be pipelined through the engine. I know this may not be the most approved way of learning theory but for me I need to learn by doing. Little sample apps and tutorials are handy when learning various aspects of the various components, but without seeing how the pieces fit together the information is lost in the bookshelf that is my brain. Anyway. When it comes to game data. For instance, lets use World of Warcraft since most people are familiar with it at least to some extent. A game of that nature has a lot of data that needs to be stored. I dont mean player data, I mean the quests, monsters stats, item stats, etc. This is where Im drawing a blank. Ive fiddled with sql, thought about simple text files, but then thought about excel databases. My question is what would be a user/developer friendly way to create such a large database of various game data that is static at load time, but subject to chance during game play (ie. each instance of a monster may have different health values at different times, although a static starting value)?

Additionally, for a multiplayer game, this static information would be on the server side if Im not mistaken, though the models and skins and such would be client side. Logically for me this makes sense but need some professional confirmation.

Basically Im trying to get the idea straight in my head of how the various pieces fit in the big picture and get pointers on how to proceed. Be gentle please. Im working in c++ and prefer to stay as object oriented as possible. Any help and/or suggestions are greatly appreciated.

Hannu Balk

Sep 13, 2010 at 6:13 AM

Hey,

Games are realtime programs which basically means that you want to run them fast as possible. This is major difference from ie. office applications which most of the time waits user input. So we get out first basic function:

void gameloop(){  while(playing)    {...}}

In game loop you need to check millions of things depending how you have your game constructed. If you have multiplayer game you probably do AI and Physics (if objects interact other players) in server side and Gfx/Sound/Input in client side. Client side game loop would first query server for new data to get updated object positions, other players actions. Then it would process players input and send those actions to server. After that I would render scene and play sounds, etc.

For server side, you calculate AI, physics and player positions and send that data to the clients. For data storage, what you should use depends on many things. Does data have to remain between server software reboots or is it generated every time server starts? If you want preserve your data, then I prefer database (why invent wheel again?), otherwise you can pick text files, etc. Probably you end up using mix of them (player statistics in SQL server, levels and unit descriptions in data files). about excel files, don't even think about them :). Although you can export your excel files to scv format which is way easier to parse.

These are just general toughs how game / multiplayer game is constructed. There is no absolute right or correct way to do things.

DreamCPP

Sep 13, 2010 at 9:13 PM

I grasp the concept behind game loops and such. Although multiplayer games add a new area of processing during the loops. So that much is helpful. Now the question remains, when doing any multiplayer project solo, regardless of size, where do you start? Should I start by getting a working server running, then build the client, or should I start with a non connecting client, then work on the server and finally add networking to the client? Or should I build them both simultaneously, possibly in the same solution but separate projects?

Rycross

Sep 13, 2010 at 9:19 PM

Quote:
Original post by Hannu Balk
Games are realtime programs which basically means that you want to run them fast as possible.

That's not what real-time means, and games are only quasi real-time. Real-time means that you can guarantee how long a certain software job will run.

Games seem real-time because you typically design the game logic such that it will run in a certain amount of time (16 ms, which is 60 fps, for example) in most cases. However you cannot make guarantees about the runtime, so its not really real-time.

Real-time programming

demonkoryu

Sep 14, 2010 at 1:35 AM

Quote:
Original post by Rycross
That's not what real-time means, and games are only quasi real-time. Real-time means that you can guarantee how long a certain software job will run.

Games seem real-time because you typically design the game logic such that it will run in a certain amount of time (16 ms, which is 60 fps, for example) in most cases. However you cannot make guarantees about the runtime, so its not really real-time.

Real-time programming

Quote:
Original post by Wikipedia
A soft real-time system on the other hand will tolerate such lateness, and may respond with decreased service quality (e.g., omitting frames while displaying a video).

So that makes most games a soft-realtime system (because your users patience to wait for individual frames is still limited).

Hannu Balk

Sep 14, 2010 at 2:03 AM

Quote:
Original post by DreamCPP
I grasp the concept behind game loops and such. Although multiplayer games add a new area of processing during the loops. So that much is helpful. Now the question remains, when doing any multiplayer project solo, regardless of size, where do you start? Should I start by getting a working server running, then build the client, or should I start with a non connecting client, then work on the server and finally add networking to the client? Or should I build them both simultaneously, possibly in the same solution but separate projects?

I would do them in same solution / separate projects. And I would do them same time since i like to see progress and test things. Negative side is that some times you could end up writing lot of code again. But I don't see that as a big problem.

I did one client / server program (not a game) little while a back and I found it convenient to add features to both sides instead of doing client or server side first.

Hannu Balk

Sep 14, 2010 at 3:04 AM

Quote:
Original post by Rycross
Quote:
Original post by Hannu Balk
Games are realtime programs which basically means that you want to run them fast as possible.

That's not what real-time means, and games are only quasi real-time. Real-time means that you can guarantee how long a certain software job will run.

Games seem real-time because you typically design the game logic such that it will run in a certain amount of time (16 ms, which is 60 fps, for example) in most cases. However you cannot make guarantees about the runtime, so its not really real-time.

Real-time programming

Games are generally rated as real-time programs since modern desktop operating systems are not capable of running real real-time programs because of multitasking.

As the Wikipedia said, correct word is "soft real-time" or "quasi real-time". For comparison to desktop applications, I just prefer shorter version "real-time".

DreamCPP

Sep 14, 2010 at 3:44 AM

A) Lets leave the real-time /quasi real-time talk out of this post since it has nothing to do with the question Im asking for information on.

B) I figured that writing both server and client code simultaneously was the most logical course of action. However seeing as I have never been involved with a large scale project I wanted feedback, so thanks.

Now a question regarding the server. I know a server can be a simple console app using cout statements and such to print info, but what if I wanted to be able to add features/commands that a server admin can perform, such as kicking/banning a player, restarting the server, changing settings etc? I can think of 2 ways to do this, first being to add a gui to the server using irrlicht since thats what my graphics will be written with. The other could be callback functions in Raknet that are called when an admin account sends the correct packets to said server. My question is which to use. I feel like callbacks and admin accounts could be used but that leaves vulnerabilities for hackers to take control of the server, whereas if I make them hardcoded in the server with a gui then I would be safer since you have to have access to the actual server in order to call these commands. Thoughts?

Hannu Balk

Sep 14, 2010 at 4:51 AM

Quote:
Original post by DreamCPP
Now a question regarding the server. I know a server can be a simple console app using cout statements and such to print info, but what if I wanted to be able to add features/commands that a server admin can perform, such as kicking/banning a player, restarting the server, changing settings etc? I can think of 2 ways to do this, first being to add a gui to the server using irrlicht since thats what my graphics will be written with. The other could be callback functions in Raknet that are called when an admin account sends the correct packets to said server. My question is which to use. I feel like callbacks and admin accounts could be used but that leaves vulnerabilities for hackers to take control of the server, whereas if I make them hardcoded in the server with a gui then I would be safer since you have to have access to the actual server in order to call these commands. Thoughts?

Are you going to distribute server to others or are you going to use it all by your self? How about server OS? Is going to be Linux? You can get real cheap Linux virtual servers with ssh connection. Virtualized or dedicated windows server with terminal services connections costs roughly double than Linux servers (these are roughly the prices currently in Finland: Linux 25-50Eur/m, Windows 50-100Eur/m).

You can make web, telnet, local console or Windows app based admin interface. I probably would make simple admin console first where you can kick/ban or other wise alter the server. Its useful as testing too. Just add commands to spawn monsters or stuff to test things out.

And your on right track when making any network related programming: Always think security first!

DreamCPP

Sep 14, 2010 at 5:16 AM

For now the game server would run on my xp system. But for long term distribution, it would depend on the project. The one I have in mind for this go round would be dedicated server not distributed with the client. Clients connect to a chat style server where they can search for matches, purchase avatar upgrades and such. When in a game, Ive not decided whether players will host each game peer 2 peer style or if the main server app would start another game server for each match. Im leaning towards the latter just to keep development a bit more simplified and for security. But at what cost to server specs? Essentially this is a 0 budget project meant for learning but Im hopeful for the future :)

As for final server selection, raknet and irrlicht both claim multiplatform capabilities but I would really need to be careful what other libs I use in order to maintain that adaptability. So for now Ill program for windows and if need be later port to whichever OS is affordable/available.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.