Network Games - Open Source the Server, Let Others Write Clients? 20
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 doubt it would work. (Score:5, Insightful)
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).
Some advice (Score:5, Insightful)
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.
Re:Some advice (Score:3, Insightful)
A fair amount of the architecture is complete (although it would have to be retasked for the new goal), but my question was really whether in the abstract sense people would be interested in writing clients -- given a fully functional server -- since if nobody would be interested there's no point in doing it.
Re:Some advice (Score:2, Insightful)
my question was really whether in the abstract sense people would be interested in writing clients -- given a fully functional server -- since if nobody would be interested there's no point in doing it.
My intuition is that people would be willing to work on it.
But the only way to know for certain is to release the client and see what happens. BTW, it doesn't have to be a fully-featured server, a minimal one will do to start with.
MUD Lessons (Score:2, Insightful)
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?