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 doubt it would work.

[Anonymous Coward]

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).

Re:I doubt it would work.

[xihr]

That's exactly what I'm trying to find out, hence the chicken and egg problem. You're not going to get people interested in writing clients unless there's a game there but the point of getting people interested in writing clients is avoiding doing the clients in the first place. Nasty spiral, that.

Re:I doubt it would work.

[WasterDave]

You mean like "a trivial text-based client primarily for a code example" say?

Dave

WorldForge?

[Chelloveck]

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?

[cabalamat2]

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

[cabalamat2]

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

[xihr]

I had no intention of starting down the road of recruiting client writers before having a fully-functional server, a fleshed-out (and implemented) protocol, sample client libraries, and a simple (though hopefully functional) sample baseline implementation that would be used for both demonstrating the system to potential client writers and for testing and debugging the server.

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

[cabalamat2]

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

[xihr]

This is true -- the only way to know for sure is to try it and see what happens. I was hoping to get a feel for what people thought of the idea first.

Re:Some advice

[Sheridan]

I'd agree. If the Internet Chess Servers are anything to go by, provided people can get interested enough (i.e. playing with a basic client such as the simple text based one mentioned in the article) then people will write clients.

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"

[mcelrath]

Having started several projects and watched several others, I can tell you this with confidince: In Open Source you cannot depend on other people to write pieces for you.

1. In early stages, everyone wants to start his own project. Nobody wants to be a small piece of a larger project. I have tried to corral people working on similar things as me into one project, but no one is willing to give up their ideas and control in order to be a third-tier contributor to a larger project.
2. People will generally not contribute at all unless the current product is usable, and sufficently compelling to make them want to improve it. A half-baked idea or a half-finished client will stagnate indefinitely. One only needs look on sourceforge for the 80% of unfinished projects there. You know, the ones with no code, or a little code but not yet working.
3. If other people do contribute, they're not going to implement your ideas. They will implement their ideas. Almost nobody joins a project, and picks something randomly from the TODO list. In my personal pet project [sourceforge.net], I don't think anyone has ever written something that I put on my TODO list. Though I have received several contributions that I didn't think of.

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

[CMiYC]

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.

MUD Lessons

[mvpll]

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

[markj02]

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.

The client is the game

[_wintermute]

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...

Re:

[account_deleted]

Comment removed based on user account deletion