Slashdot Mirror
Network Games - Open Source the Server, Let Others Write Clients?
xihr asks: "I'm the developer of Interstelen, initially a turn-based, strategic Web game of interstellar conquest. As time has progressed, I've found that it hasn't gone much beyond the barely-usable, early-alpha phase, primarily because, as with most people, I don't enjoy making user interfaces. It's clear at this point that it's not going to get done unless something changes. So my choices are to put the game on hold, or to change the architecture and goals. It occurred to me that this might be a better approach: Architect a server and public protocol, as well as client libraries for a few languages to help people along and a trivial text-based client primarily for a code example and debugging, and 'recruit' (hopefully, just 'let') people to write various clients." Seems like a reasonable strategy, especially if time is a limited commodity. I'm sure there are Slashdot readers who are working on (or have done) similar project. How did things turn out?
"This isn't too different from my ultimate goal, which was to eventually release the code under open source anyway and to eventually put together a public protocol so that other clients could be created. In a way this would be simply reversing the order in which things get done.
This would be win-win, since it would play to my strengths and people who like making user interfaces could make them in whatever language they wanted. But obviously it's not going to get anywhere unless people are actually interested in writing clients, so there's a chicken-and-egg problem lurking here.
Does this sound like a project that would be of interest to the open source community?"
I don't know anything about your game, but I have a hard time believing people would write clients for a game they couldn't play.
You'd need to write a shitty java client or something that shows the potential of the game, but sucks enough that people would want to write their own clients.
IOW, I think it sounds like a great idea, but I think you'd have a hard time getting anyone interested with nothing but a text client (that probably would be more or less completely unplayable).
There's already a similar project, WorldForge. If you're interested in this kind of thing, you might want to join that project rather than starting your own.
Although, if this article at O'Reilly's site is accurate, the idea hasn't exactly taken of like wildfire. All the more reason to throw your efforts in with them rather than dividing the development effort to start a new game.
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
I was once involved, many years ago, on a collaborative open source project to write a similar game. it was the first open source project I was involved with, and was a failure, mainly because there was no established codebase or leader before the project was opened up to collaboration. So I think I may be able to offer you some advise.
Some questions: how much of the game is coded now? In particular, how far are you with defining the file formats for orders and game positions?
I think you need to make it open source, if you want anyone to help you code it. If you want helpers, the file formats need to be defined, and a minimal server needs to be in place. Communication between the server can clients can be by ascii files, which can be sent over the net using TCP, or by using a web-based interface to the server. Multiple clients can be, and perhaps will be, written.
As an aside, I note you are coding it in Python, which is an excellent language and a good sign.
But it bears emphasizing: you won't get significant help from the free software community until the project has already progressed part a certain minimal size.
I also think you should make provision in your game system for computer opponents. These would, to the server, be clients like any other, but would be a progream making the decisions not a human. Then a player could play on his own PC instead of over the net. Also, you could have tournaments between different computer opponents.
So I say this to all open source developers: Look for and join another project, rather than starting your own! Open Source would go a lot farter, a lot faster, if so much effort wasn't wasted on projects that eventually dead-end. Imagine the effort that went into each of those projects went instead into larger a larger project!
On the other hand, writing a generic library is often exactly what is needed. In your case, a generic server and client library might be a good idea, but it must be sufficently generic and you'll have to give up on the idea of people implementing your kind of client. You might be surprised what it gets used for. (Software is funny that way) For instance, gstreamer seems to have given up on writing the be-all and end-all media player (a la mplayer), in favor of writing a component library for media playing. It remains to be seen whether they will be successful, but I think they will be. This route is difficult, and requires a lot of evangelism. Not everyone will agree with your design decisions, so not everyone will want to use it.
-- Bob
1^2=1; (-1)^2=1; 1^2=(-1)^2; 1=-1; 1=0.
This sounds a lot like Netrek. Orginially everyone was going to write their own clients. Ended up failing (more or less) because people were writing clients that could cheat. So in the end, only clients wrote by the maintainers get used anyway.
Take a look at mud clients, there are plenty of them. But I'm guessing the ratio of client writers to mud players would be very small, it is merely the overall number that makes it seem like an abundance of clients. The reason people write mud clients is not to just play them, they have telnet for that, but to play better/easier. If there is no "tactical" advantage to having a "fancy" client, very few people are going to take the time to do it.
As your project attracts developers, are they going to more interested in coding clients or creating "intelligent" computer opponents (or any other server side development)? Given that you are only likely to get a few (if any) to begin with, hoping to find one who is good with UIs and enjoys working on them may be a long shot.
I also don't really understand why you are having trouble with the UI, when you think of playing this game (that is why you are writing right?), what do you imagine seeing on the screen?
Writing user interfaces in C or C++ is an absolutely dreadful process (although C and C++ are good for other applications). But if you use the right languages and toolkits, it becomes a lot easier. I like Python with Tk or wxWindows. Smalltalk (Squeak) is also quite nice, but a bit hard to deliver. Java/Swing is almost as tedious as C++, but at least the toolkit is very complete and there are lots of third party libraries that help you and that all work together.
UM, the client is the game. Servers are fun to build, don't get me wrong, but most of the game is actually the client...
technoshamanic resistance within hyper-transgressive ontology
If you can develop rules that are generic enough (hack and slash) multiple people could connect to the same server, but play different games. Beat your friends at AOK while they get crushed in Warcraft. Good for kitsch value :).