Single Player or Multiplayer?
Blitz3D Forums/Blitz3D Programming/Single Player or Multiplayer?
| ||
| For those of you into indie games: do you think single player games are viable or would you only play online games? The kind of game I'm designing atm is a hybrid FPS/RTS... would you be interested in that type of game only if it has deathmatch capabilities? Moreover, would indie publishers only be into it if it's MP? |
| ||
| Personally, (and I really doubt how reporesentative my opinion is!) I think that solo games are perfectly viable today. I enjoy online games, but it is nice to play against an opponent that doesn't have to keep chatting American, writing in hieroglyphs or calling me a 'Something'-tard and making comments about my mother or references to homosexuality. The majority of games around are still single-player, despite an increase in online playability, only certain games are suited to the internet. Perhaps an Online Multiplayer version maybe a proposal for the future? As far as publishers go..... I wouldnt have a clue ;-) |
| ||
| IMHO, it would be advantageous to offer both Single Player, Multi-Player, and hybrids modes like Cooperative. |
| ||
| I agree with Frank, but for the sake of realistic thinking, single-player is your best option. Multiplayer assumes there's more than one person playing at a given time, and without tons of advertising or outstanding luck like Soldat saw, we're talking about making a game that will hardly ever have a server going and therefore render it unplayable to the user. So consider multiplayer an extension to your game with singleplayer at the core. It will most likely pay better in the end. |
| ||
| IMO, its easier to build on top of network core than to try to added one in later. I ran into this trouble with Project PLASMA FPS 2004. Now, im my new FPS Engine all I/O are processed via a network interface, to include BotAI. |
| ||
| That's a good point Frank, very sensible - I'd better start learning about net coding... how difficult is that stuff to learn? (with specific reference to B3D? I don't know any C++) I'm thinking for mine, it will be most likely 2-4 players, since it's more like an RTS in game mechanic - but each player will control a team of bots, so I imagine the amount of data going back and forth will still be huge. |
| ||
| Robin, Actually 2-4 players will keep the bandwidth pretty low by today's standards. But at any rate, do yourself a favor and code the multiplayer yourself. The DirectPlay commands in blitz should do the trick nicely. |
| ||
| @Chroma: low bandwidth, even given all the non-player characters? I know there are fewer PCs to send info between, but wouldn't the amount of info per PC be higher if each player is controlling not only him/herself but a number of AI squad members? Also, what's the preference between UDP and... er... what's the other one? (Is it DirectPlay as in your last post?) |
| ||
| or mrtricks you may want to look into rolling your own code! You can look at my BlitzPlay Lite code for a solid framework to build off of. Or there's always the feature-packed BP Pro, but that's up to you ;) You can see the docs for it here! BP Pro has been highly recommended by much of the Blitz community! As for your original question.. I personally think that any game can benefit from multiplayer functionality! In fact I find it *very* difficult to get into single player games these days.. and have had this problem basically ever since I got an internet connection. To each their own, of course! I just prefer the competitive aspect of playing against other real people :) |
| ||
| Mr. Tricks: I'm not sure what to tell you about UDP, but I know TCP is designed for reliable data transmission. It can guarantee that the message gets to its target, but would probably cost alot in speed, when packages start getting lost. UDP is more targeted for speed, where package loss isn't all that important, but speed is. Plus, I believe Blitz will actually pause your entire program to initiate a TCP connection. As for how DirectPlay works, I don't really know myself. |
| ||
| @mrtricky Imagine an internet FPS where player A sees player B run past him. Here's what would happen with each protocol in the case of lag. UDP: If a packet arrives late, it is discarded and the client waits for the next one. To Player A, player B will appear to stop suddenly and will be further down the hall in an instant. This is "warping" and doesn't slow down the game when a packet is missed. TCP: If a packet arrives late, the server is informed it's late and resends it. Obviously, this is a bit slower in low-bandwidth conditions, but player A will see player B stop suddenly and continue to run down the hall without teleporting. This can slow down gameplay, but it's a more reliable protocol than UDP. Basically, if you need information sent to player's computers as quickly as possible, go with UDP. If you need players to receive most, if not all, of the information sent, go with TCP. The reason both protocols are around is because one provides speed at the expense of reliability and the other provodes reliability at the expense of speed. Which one you need is up to you. |
| ||
| Cool, thanks for the heads up. What do you think to including both protocols and allowing the user to choose? Would the codebase for UDP and TCP be completely different throughout or would there be common code? Or maybe it's not worth it? |
| ||
| Designing Secure, Flexible, and High Performance Game Network Architectures Very good reading. |
| ||
| Thanks! |
| ||
| Hey, Gran Turismo 4 is released these days. They say the GFX are incredible and do you know what? Single Player only. |
| ||
| TCP would do the job. I believe it's what blizzard used for Warcraft II. And that game is still the bomb. RTS type games don't really require the super fast updates that FPS games do but they definitely require the reliability of TCP. The TCP commands are pretty straight forward. And again I HIGHLY recommend you code the multiplayer yourself. If you lose a packet with UDP then it would adversely affect the game. Blitzplay Lite and Pro use UDP which is geared more towards FPS type games where a lost packet doesn't mean too much. Don't be fooled, TCP is still EXTREMELY fast and can do the job for an RTS game with ease. |
| ||
| Remember: Halo was a big hit WAY before Xbox Live came out. |
| ||
| You could play halo online using xbconnect. That kept my playing it really :D I thought TCP in blitz paused the game sometimes whilst it recieved packets? I heard skcn[ac] talking about that a while ago... |
| ||
| Blitzplay Lite and Pro use UDP which is geared more towards FPS type games where a lost packet doesn't mean too much. I just wanted to point out that while judging by the UDP protocol alone, this is correct, it's not so with BlitzPlay Pro. BP Pro offers several messaging options.. including Reliable sends, and Ordered Reliable sends.. matching and even surpassing the functionality that TCP offers in such matters. This is why UDP is generally shunned, because you have to code your own protocol on top to deal with reliability; BlitzPlay has already done this. Oh and yes Blizzard originally used TCP for their Warcraft games, however in WC3 they finally realized the benefits of UDP and switched over their networking code to UDP in a patch soon after the game was released. I thought TCP in blitz paused the game sometimes whilst it recieved packets? I heard skcn[ac] talking about that a while ago... This is indeed a possible problem, although it can be reduced as long as you code carefully. One problem I ran into when I first tested TCP years ago was that I would use commands like 'readline' to attempt to read from the TCP stream. The problem of course being that if the full line had not been yet received, then blitz would delay while waiting on the data to be received. You can sort of get around it by using ReadAvail to find out if the entire message has been received, and then process it from there. There are other delays inherant in TCP which will not be so easily avoided, however.. and this is where UDP shines. TCP is perfect for what it's intended as, but real-time applications (games, data streaming for voice, etc) wasn't really the goal in it's design. A quote from this article (written by the developers of X-Wing vs. TIE Fighter): "Lesson two: TCP is evil. Don’t use TCP for a game. You would rather spend the rest of your life watching Titanic over and over in a theater full of 13 year old girls." I'm not saying you have to use UDP, and you have to use BlitzPlay, I'm just offering the pro's and cons of the available options. Namely TCP = not intended for realtime apps (turn based games should be ok), and UDP = sucky because you have to write your own message reliability code, but is overall much better for games. |
| ||
| For Anything Other than Arcade style games Id say it has to have Multi/online play. Bottom line is I feel that ppl now have their bar set really high in the AI Demand are of games, so if you do go single player then your single player AI will have to be able to holds its own.. I think people have realised thought that to get a good game you just cant beat Human AI. ie playing online. Thats just my view though. |
| ||
| TCP coupled with todays broadband internet really doesn't pose a problem. The guys making X-wing vs Tie-fighter were mostly dealing with phone modems and an internet of oh say several years ago. To make UDP reliable you'd have to send a packet and then be waiting for a confirmation from the receiver that the packet got there (doubling packet traffic). Let's say it didn't though. After xxx amount of time passes, the server resends the packet. Well now the receiver gets the packet and sends a confirmation packet but now THAT packet gets lost. Ok now the server is sending the packet for the 3rd time. /sigh It could be a horrendous snowballing effect. Chances of that actually happening are pretty slim but anything is possible. End result would be a VERY late packet. Hey but at least the chat got there right? My recommendation is TCP for RTS type games and UDP for FPS type games. Thats the easiest solution IMO. TCP is pretty easy to learn also. Just have to use what's best for the job. There are some excellent TCP/UDP examples in the archives. =) |
   |