You can find my site at www.gameoire.com
About this blog
It's hip to hate OO, Windows, and gotos.
Entries in this blog
You can find my site at www.gameoire.com
-- response --
If you like books, I'd recommend picking up a copy of "Programming Multiplayer Games", by Andrew Mulholland. It's a nice lightweight introduction to multiplayer network programming.
It covers basic TCP/IP networking, constructing a network library for use in a game, and how to construct some simple multiplayer games, including dealing with latency in games.
I also recommend the June 2001 issue of gdmag that has the article "Leveling the Playing Field: Implementing Lag Compensation to Improve the Online Multiplayer Experience"
by Yahn Bernier. This article has an excellent discussion on dealing with lag in FPS games. I didn't see an online copy of this. If I find one I'll post it here.
Another by Bernier is "Half-Life and Team Fortress Networking:
Closing the Loop on Scalable Network Gaming
Backend Services": http://www.gamasutra.com/features/20000511/bernier_01.htm
This requires free registration at Gamasutra.
Brian Hook also posted a nice description of the Quake3 networking model at: http://www.bookofhook.com/Article/GameDevelopment/TheQuake3NetworkingModel.html
A nice class based multiplayer network system is the Torque Network Library, which is reasonably documented and can be found at: http://www.opentnl.org/ There is a nominal charge to use it commercially however.
Unless you want to dance in rings of fire, you are really going to want to design the multiplayer capabilities into your game from the beginning. The other sad truth, is a lot of the gotchas are only going to be learned after the experience of doing it.
I've just finished up the first pass of the code for the article, complete with doxygen comments. I've got some optimization work to do as it's about three times slower than new (without fragmentation) at the moment and I'd like to speed it up so as to give people something they can actually use, rather than just a toy. Once the code is up to speed (this evening most likely), I'll start writing up the article that discusses all of the pieces listed above. I'll submit it to gamedev.net as either an article or sweet snippet, and get it onto my website as soon as possible. (Immediately, if gamedev doesn't want the article, and whenever they will allow me to cross post it on my personal site, which appears to be 30 days after publication on gamedev.net. I'm not sure if you can post it to your own personal site more quickly?).
I'll continue to post brief thoughts and ideas on this weblog as the main site will be for more "considered" thoughts. :)
I'll post an update once things get rolling.
One thing that can really give it to you in the game is when you have to reload in the middle of getting clawed or beaten on by wrenches. The rub is that you reload basically the same whether you are being attacked or not. I suspect if a demon from hell was clawing me to death, I might move a wee-bit faster.
Two interesting ways to handle this:
1) Show a faster reload animation signifying the marine trying to get things done faster. However, this would be coupled with a percent chance of dropping each portion of the reload. This would animate as the player dropping some shells. So you might only get 4 shells reloaded but use eight in doing so.
2) Allow a button that does a fast reload. This reload would take say 75% of the time a normal reload takes, but would only insert half the amount of reloaded ammunition. In the short term (if you only have to do this once), you might be better off, but if you are in a prolonged fire fight the longer reload might be better. This gives a new tactical (right word?) decision to the player that can make things interesting.
Just some thoughts. :)
I've been a game developer (specifically multiplayer at the moment), for a whole solid two months. While I have plenty of "hardcore" development experience, I am still in catch up mode to learn as much as possible about the companies source code bases, the architecture, and just "how things are done". This is translating into just shy of 50 hours a week of work. My guess is that this will last another four to six months until I'm pretty comfortable. Which should be just in time for, (drum roll) crunch mode!
I know its a cracker jack box fairy tale, but I'm kinda hoping my stuff will be pretty solid then and I won't have to work hours worthy of an epic tale, mythos, or full line of action figures. We'll see. :)
Just in case your wondering, I'm not complaining. I'm pleased as punch to be here doing this, and wouldn't have it any other way.
So, onto my first journal entry. Today was something of a first for me. I participated in an internal focus group for a game prototype that was developed at Volition. Obviously, I can't comment on the game and whatnot, but doing a focus group was very interesting. I certainly learned a lot about doing them simply by being a test subject. I look forward to being able to run some of my own on some personal projects. I would definitely recommend getting involved in one if you ever have the chance if nothing else but to focus your mind on thinking about games when playing one.
Ok, so that was a little vague, but I've got to get back to work anyway, so I'll try and write something a little deeper next time!