Online Persistent World Ambition
Posted: Fri Jul 30, 2010 6:43 pmHi! Sorry for the length.
My wife and I have been discussing our idea for an online game we would like to write for several years now. We have had a lot of conversations about our ideas and have a lot of enthusiasm. To be honest, part of me doesn't want to write the game, I just want to *play* it, but what we are looking for doesn't seem to exist yet, so I guess we either write it or we wait years and years.
She has been a C++ developer for over ten years. After college, I was a C coder for about a year, and then got into System Administration, so my coding skills are very very rusty. We both realize that we need to start small on "doable" projects first, and that "the game" that we always talk about is a pretty ambitious idea.
We want to create a 2D game client ("Gameplay, Not Graphics" is our mantra), a server architecture that allows processes to be able to relocate to different physical hosts for scalability so we can run on commodity priced hardware, with a SQL back end to make the game world persistent. We want to eliminate tedious and repetitive level-grinding--don't computers exist to automate tedious, repetitive tasks? And what's more tedious and repetitive than killing NPCs? We want to present the appearance of "zonelessness"--the real world doesn't have "edges". We want to make the game world as enjoyable to casual players as it is to people who spend hours every day there. We want to design against griefing, and to promote (but not dictate) cooperation. We want to model ecology in the game world more deeply that what we see in current commercial products. We want to design towards an economy that is robust and self-correcting, as it is in the real world. And we want to fly to the moon in a spaceship made of diamonds!
Yes these are ambitious (and perhaps unreachable) goals, but the one thing we do *not* want to do is write Yet Another Fantasy MMORPG where the primary game architectural directive is written by the marketing department and some CFO: to prolong average paying subscription time by means of forcing our customers into some stupid levelling metaphor.
And I know, the backend part of this is daunting. Dining Philosophers, race conditions and all sorts of complexities arise with this kind of design. Maybe we'll never get there. But I feel like, if I can at least, in my lifetime, create a simple multiplayer environment with some simple actions that persist in the game world across server restarts, then I may not be "Da Vinci" but at least I can go to my grave knowing I qualified as "House Painter". It would be something I could be proud of, even if I don't completely succeed... something beyond just "Work, Collect Paycheck, Pay Bills, Eat, Sleep, Repeat".
I am learning C++... object oriented programming hurts my brain. I'm an old school procedural coding guy, so I have a learning curve here, but that's ok, learning is fun. I realize that even with single player there are so many things to learn, and deciding *what* to learn is a big job in itself--Visual Studio? Ogre? DirectX? Java for the front end? And then to throw in networking is a big deal, and then to add the SQL persistence (robust, low-latency database read/write journaling queue manager process--argh!) is yet another complexity. So we're trying to figure out how to not reinvent the wheel as much as possible--to be as efficient as possible with our development time.
I found this which looks like it may be a promising networking framework: http://www.jenkinssoftware.com/raknet/manual/introduction.html so we won't have to write the whole networking infrastructure from scratch.
We want to run the server stuff on linux. I just can't bring myself to learn .NET, and C# is out of the question to me.
For the frontend game client, my first thought was Java for portability... write once, run everywhere. Looking through O'Reilly's "Killer Game Programming in Java" made me think this might be a good idea. But that is yet another learning curve for us, so the more I think about it, the more I think it would be better to stick to C++ for server AND client... I've known people who can effortlessly switch between C, C++, Python, Perl, can rattle off regular expressions fluently etc. but I have to recognize my own limitations. I don't think I'm one of those guys... before that first coffee in the morning, I can barely operate home appliances.
So my question is (sorry for the length) is GE something that would lend itself to my project? It seems like I should be able to get GE and something like RAKNET to live harmoniously together without needing access to the GE source...? My concern is that I don't want to spend months learning something like GE only to find that there are some restrictions it imposes, and then have to start from scratch anyways--maybe better to start from scratch from the beginning?
Sorry if this is vague, I am just hoping that some of you out there (who from the forum posts I've looked at clearly are *way* more knowledgeable and experienced than I) might be able to give me some advice. And again, I understand that jumping into some big client-server project is not the way to start. We have outlined some first steps we need to take, and we plan to do many throwaway test projects strictly as exercises to get me up to basic competence. But we do want to keep our eyes on the final destination, and would really like to avoid running a long way down roads that end up leading us away from our goal... does that make sense?
Any thoughts or suggestions would be greatly appreciated! Thanks very much for your time.
My wife and I have been discussing our idea for an online game we would like to write for several years now. We have had a lot of conversations about our ideas and have a lot of enthusiasm. To be honest, part of me doesn't want to write the game, I just want to *play* it, but what we are looking for doesn't seem to exist yet, so I guess we either write it or we wait years and years.
She has been a C++ developer for over ten years. After college, I was a C coder for about a year, and then got into System Administration, so my coding skills are very very rusty. We both realize that we need to start small on "doable" projects first, and that "the game" that we always talk about is a pretty ambitious idea.
We want to create a 2D game client ("Gameplay, Not Graphics" is our mantra), a server architecture that allows processes to be able to relocate to different physical hosts for scalability so we can run on commodity priced hardware, with a SQL back end to make the game world persistent. We want to eliminate tedious and repetitive level-grinding--don't computers exist to automate tedious, repetitive tasks? And what's more tedious and repetitive than killing NPCs? We want to present the appearance of "zonelessness"--the real world doesn't have "edges". We want to make the game world as enjoyable to casual players as it is to people who spend hours every day there. We want to design against griefing, and to promote (but not dictate) cooperation. We want to model ecology in the game world more deeply that what we see in current commercial products. We want to design towards an economy that is robust and self-correcting, as it is in the real world. And we want to fly to the moon in a spaceship made of diamonds!
Yes these are ambitious (and perhaps unreachable) goals, but the one thing we do *not* want to do is write Yet Another Fantasy MMORPG where the primary game architectural directive is written by the marketing department and some CFO: to prolong average paying subscription time by means of forcing our customers into some stupid levelling metaphor.And I know, the backend part of this is daunting. Dining Philosophers, race conditions and all sorts of complexities arise with this kind of design. Maybe we'll never get there. But I feel like, if I can at least, in my lifetime, create a simple multiplayer environment with some simple actions that persist in the game world across server restarts, then I may not be "Da Vinci" but at least I can go to my grave knowing I qualified as "House Painter".
It would be something I could be proud of, even if I don't completely succeed... something beyond just "Work, Collect Paycheck, Pay Bills, Eat, Sleep, Repeat". I am learning C++... object oriented programming hurts my brain.
I'm an old school procedural coding guy, so I have a learning curve here, but that's ok, learning is fun. I realize that even with single player there are so many things to learn, and deciding *what* to learn is a big job in itself--Visual Studio? Ogre? DirectX? Java for the front end? And then to throw in networking is a big deal, and then to add the SQL persistence (robust, low-latency database read/write journaling queue manager process--argh!) is yet another complexity. So we're trying to figure out how to not reinvent the wheel as much as possible--to be as efficient as possible with our development time.I found this which looks like it may be a promising networking framework: http://www.jenkinssoftware.com/raknet/manual/introduction.html so we won't have to write the whole networking infrastructure from scratch.
We want to run the server stuff on linux. I just can't bring myself to learn .NET, and C# is out of the question to me.
For the frontend game client, my first thought was Java for portability... write once, run everywhere. Looking through O'Reilly's "Killer Game Programming in Java" made me think this might be a good idea. But that is yet another learning curve for us, so the more I think about it, the more I think it would be better to stick to C++ for server AND client... I've known people who can effortlessly switch between C, C++, Python, Perl, can rattle off regular expressions fluently etc. but I have to recognize my own limitations. I don't think I'm one of those guys... before that first coffee in the morning, I can barely operate home appliances.
So my question is (sorry for the length) is GE something that would lend itself to my project? It seems like I should be able to get GE and something like RAKNET to live harmoniously together without needing access to the GE source...? My concern is that I don't want to spend months learning something like GE only to find that there are some restrictions it imposes, and then have to start from scratch anyways--maybe better to start from scratch from the beginning?
Sorry if this is vague, I am just hoping that some of you out there (who from the forum posts I've looked at clearly are *way* more knowledgeable and experienced than I) might be able to give me some advice. And again, I understand that jumping into some big client-server project is not the way to start. We have outlined some first steps we need to take, and we plan to do many throwaway test projects strictly as exercises to get me up to basic competence. But we do want to keep our eyes on the final destination, and would really like to avoid running a long way down roads that end up leading us away from our goal... does that make sense?
Any thoughts or suggestions would be greatly appreciated! Thanks very much for your time.
I'm very impressed by what I have seen here so far!