Dunno if this has been talked about, but im creating a simple game where i want players to be able to sign up, login, see a tracker or whatever and then create/join a game, would it be best to make the game first where you have your guy he can kill stuff such as turrets and stuff, then add the networking or is it simpler to do the networking first, or to do a little of each at a time so get a simple game frame and a chat going etc...

Ive never done networking before so it might be difficult but then again it might not and so i want to know the best way to go about this.

Im kind of in the same boat as you are. I decided to make the game first. I made it two player on the same machine and now am in the process adding networked play. Im not a pro or anything but i would think this would be much easier than trying to build the game while worrying about networked stuff. Get the gameplay down flawless and then start networking, that way if undesirable things happen you know its the network stuff and not the gameplay.

Well, I dunno. If you add networking later, you get the advantage of having all your game logic nailed down but you have to spend a lot of time refactoring code, and some of the approaches you had to your game will guaranteed need to be rewritten. You will also find a lot of bugs.

With the other method, your game will be very specifically designed for multi player but its actual gameplay can be poor and going in the wrong direction. If you make it single player first then you have a level of functionality that you can use as a goal for the multiplayer.

I work with some game industry veterans and the programming lead has always done the first option (what you're doing). However, as you write your game you should always be programming it with multi player in mind. Like if you have enemies chase after a player, for example, you would want to write an algorithm to have them chase the nearest player, even though in single player that will never make a difference. You can get your code a long ways towards multi player if you just keep everything in mind as you go.

I work with some game industry veterans and the programming lead has always done the first option (what you're doing). However, as you write your game you should always be programming it with multi player in mind. Like if you have enemies chase after a player, for example, you would want to write an algorithm to have them chase the nearest player, even though in single player that will never make a difference. You can get your code a long ways towards multi player if you just keep everything in mind as you go.

This is/was common amongst game developers who have little or no experience of network programming. It makes sense for highly experienced single-player programmers - do the bit they know first, because the project could get cancelled early if you struggle to make something playable.

In general, though, *nowadays* it's considered a foolish way of developing games, since we have the luxury of hindsight - there's been so many MP games developed that we can look back and say "Aha! Look what happens when you put networking last" without having to argue over whether its a "good" or "bad" approach - it's now just an observation.

Some obvious reasons for why its a bad idea: - putting your riskiest thing at the end massively increases the chances of a failed project - all game designs change during development; if you have no MP version until the end, your MP gameplay will (comparitively) suck, because its received much much less feedback and polish

...modulo: of course you can get a little lucky and make an awesome game no matter what order you do stuff . So dont let me put you off.

In general, it takes a lot of experience and knowledge of MP game design + architecture + implementation to be able to leave it till the end. I (personally) would strongly advise against it unless you've made quite a few MP games already.

thanks for the advice, i think im going to get the networking setup now that way i wont have to redo algorithms and such cause this will end up as a lot of code and later on would be a head ache trying to correct things to work with networking.

blahblahblah has a point, but is not necessarily right. The programming lead I work with was on the original Halo team, where they did it with the networking-later approach. If you can argue that Halo was poorly created, I'll give you a cookie.

In addition to what blah said about experience (trust him, he is da network man), when you are starting out that is what you lack. But don't let it fret you.

Since you seem to have the other stuff down solid, you could take a time away and dive into networking.From my humble experience, supporting networking in your game will also mold your game into a certain cast.You probably won't be able to do stuff you can with just a single player game.

Then make some prototypes that match the core concepts of your game.Be prepared to throw them away again.

In then end you might be able to work the networking into your game with only little effort (if so, then the force is strong with you ).Or you might not and have to rewrite your game. (which is perfectly ok, we all have been there... far to often)

No matter what, adding in networking is a highly valuable experience that will only make you a better game developer.

In closing (and a little OT) blah is also painfully correct when he mentions the network programming being pushed off to later.Sadly this seems to be the norm (even more in the 'professional' field) and in case of anything non GFX related even worse (AI, content f.i.).Today the first thing you will see from a new game is the Bling. And then when the development reaches the end they remember they also have to add in a game somewhere.Even stranger because by the time they actually reach the end of the development and have finally added in the useless 'game' feature no one wants anyway, they discover that their GFX are outdated.

So, like blah is saying, do not fall for the 'we'll do it later' trap. It could really come back to haunt you.The good can compensate, others fail.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org