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).
Re:I doubt it would work. (Score:1)
Re:I doubt it would work. (Score:1)
Dave
WorldForge? (Score:4, Informative)
There's already a similar project, WorldForge [worldforge.org]. 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 [oreillynet.com] 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.
Re:WorldForge? (Score:1)
There's already a similar project, WorldForge
Not really, WorldForge is a real-time roleplaying game, whereas what's being proposed here is a turn-based empire-building game, similar to Master of Orion.
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.
Re:Some advice (Score:1)
Re:Some advice (Score:1)
There are loads of clients for (F)ICS and compatible servers out there, even though the original players had to use plaintext (telnet) sessions to play. Things started out with the likes of xics (now defunct, I think) and xboard, and have spread into other OSes (Winboard and others...), and into other languages (Java for example).
If the protocol is open, people will write clients for many reasons - an urge to use their pet programming language; a desire for features not available in other clients; just plain perversity or any combination thereof[1]
Good luck! I think provided you do get a simple example client that people can use to get hooked and give themselves ideas for what they'd like *their* interface to do, you should be alright.
Cheers,
Mark
[1] I wrote a meta-interface to ICS (ics.el [oakden.org]) for a combination of all three of the reasons given - to learn more emacs lisp; for better commandline editing, text colourisation and the perversity of doing yet one more thing from within Emacs
"Let others write" = "Let no one write" (Score:4, Interesting)
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 [sourceforge.net] seems to have given up on writing the be-all and end-all media player (a la mplayer [mplayerhq.hu]), 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
Netrek (Score:2)
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?
UIs aren't that hard (Score:3, Interesting)
The client is the game (Score:1)
Re: (Score:2)