Multiplayer Development of Glest

[AF]

Hey, I'm tom, known usually by my alias AF, I have spent quite a bit of time coding in open source game projects and I'm in my second year of a computer games tech degree in the UK.

Code: [Select]

[img]http://spring.clan-sy.com/res/logobar.jpg[/img]
As much as the whole business of competence is off topic, I believe either way it is tied to multi player whether you like it or not. I come from the spring community, another free RTS for windows and linux, however spring is GPL, and is open and community driven unlike glest. Spring took the opposite path to glest and implemented multiplayer before single player. Yes we had human versus human games a year before we had skirmish AIs.

So, at some point you guys are going to have to come up with a lobby system to manage games. A gamespy/msn zone/steam/xbox live of sorts.

You guys aren't alone here in this predicament. The TA3D engine is about 3-4 weeks behind you in implementing multi player and they're facing identical issues. They too have a free open source outset and value clean code, and they too took the same path as you guys. Sadly their developer pool was marginalized by the older spring community which directly competed with them.

Code: [Select]

[img]http://ta3d.darkstars.co.uk/ta3d.jpg[/img]
So eventually you're all going to get sick of passing around IPs and port numbers. And then there's the whole debacle of desync and Network address translation connection issues. And don't deny these will happen. It happened to spring. It happened to Total Annihilation in 1997, it even happened to certain Supreme Commander patches. Go ahead look at GPGNet changelogs (yah gpgnet is another lobby program).

So what did they do over at the spring project? How have they dealt with multiplayer games the previous 2 years?

I am a lobby developer at the spring engine. My client is called AFLobby, and there are other clients too. TASClient, and Spring Lobby. My client and springlobby have been verified running and building on windows XP/Vista and under various linux distributions. I've even been told my own client runs under Mac OS X (a ppc machine nonetheless).

Code: [Select]

[img]http://www.darkstars.co.uk/wp-content/uploads/2007/10/lobbies.jpg[/img]
I sent an email to the glest team about this and got no reply. I sent several emails actually to various email addresses as I was confused as to where to send them. The main website said one thing, something else said another was it contact'@'glest.org? contact_game'@'glest.org?

This did remind me of when I came over here asking about spring AIs and glest support and just got a few replies from the fan base.

But the point is, spring has 3 lobby clients and a vast array of bots and auto hosts, and they're all independent projects. Our lead programmer cannot shut us down or lecture us on what we can and can't do. We manage our own code bases, and you're going to be stuck with the same predicament too.

You the glest team could put a padlock on your lobby setup and force glest users to use an internal setup, but that's easily fiddled out. I know for certain I could then waltz in and patch it up in 5 minutes and open a world of pain as your time strapped development of an internal lobby is laid waste by 2 years of heavy external client development in 3 projects with the backing support of 2 external RTS engines and possibly a sizeable army of disgruntled glest fans.

So I would suggest you start co-operating. Early in springs history a guy called betalord threw up the first of our 3 lobby systems along with his own server implementation, and tried to rule over the spring lobby system with his monopoly. Suffice to say his days are now numbered, and he's had to relinquish his role of maintainer over TASClient to another developer. I don't think you where there when the national lottery did their UK opening advert campaign but "IT COULD BE YOU!!!!"

As an outsider looking in, I see an engine development process that's stalling and creeping along. I cannot see evidence of progress save major announcements such as this news item. The website is pretty much identical, and the threads that do seem to grab my attention appear to be angst generated by issues with glest developers. I myself have been contacted several times by various people if I want to work on glest related projects (NTai seems to have gotten me kudos somehow =s), and I'm not impressed.

Darkstars, My Website + AFLobby:
http://www.darkstars.co.uk

Spring engine:
http://spring.clan-sy.com

TA3D engine:

Code: [Select]

[url=http://ta3d.darkstars.co.uk]http://ta3d.darkstars.co.uk[/url]
Spring Lobby:
http://www.springlobby.info

I wish you good luck in your multiplayer effort.

[enveloop]

Hi Tom, I moved your post from the multiplayer announcement since I believed it deserved its own space.

So I would suggest you start co-operating.

Thanks for your suggestion.

[AF]

Thank you for the sticky.

At minimum there'll need to be a way to automatically start a glest multiplayer game via a command line or library, preferably the former. Eg. glest.exe 127.0.0.1. I have yet to take an in depth look at your svn so this may already be in place.

Seeming as you already have some sort of internal battle interface, a glest version of the spring lobbies could be much easier to make, and half the protocol commands could be ignored. The same would be true of TA3D.

So this is the only thing needed on the glest side at the moment, all the rest of the work would be on the lobby side.

[martiño]

AF,

I really respect the other two projects and I wish them luck, I don´t see them as competitors, since none of us is going to make any money from this.

It is not fair that you guys flame our board trying to impose your way of doing things, especially when our project is one of the most polished open source games available for any platform.

I have read your email, I have considered it, and I don´t think we would like to accept your suggestion, especially because I have downloaded Spring and I don´t think that the lobby is especially user friendly, and our main target is the mainstream user.

Regards.

Martiño.

[AF]

I don't think its wise to judge all the lobbies based on satiriks TASClient.

TASClient != AFLobby
TASClient != Spring Lobby

Spring bundles TASClient with it. AFlobby and spring lobby are very different programs. Springs lobby setup is not fully represented by that single program.

It is not fair that you guys flame our board trying to impose your way of doing things, especially when our project is one of the most polished open source games available for any platform.

Just because you disagree doesn't make it a flame. Infact one of your team (you maybe not sure) insulted the entire open source community by implying that openness == sloppyness. But I really don't see why you should start on about that here rather than splitting the thread as was done originally.

So if you downloaded Spring and ran TASClient and didnt like it,
why am I even here suggesting anything?

Because you went looking for X and found Y and judged X based on Y. I would never suggest that glest use TASClient, namely because its such a pain to compile the delphi source that I can only list about 6 people who've ever managed it, and the two alternatives that're seperate downloads are just sooo much better.

For an example of a half decent spring lobby:

SpringLobby
www.springlobby.info

C++ WxWidget based lobby. A cross platform lobby client with 2-6 active developers at any one time.

Code: [Select]

[img]http://img108.imageshack.us/img108/9538/screenchatwb6.png[/img]






Oh and another reason why you shouldn't look at tasclient, tasclient only supports latin characters, whereas all the other lobbies have UTF-8/unicode support:


And that's before I even start on aflobby.

For those who've never seen and are wondering what made martinho scream with agony:

TASClient
A delphi 7 program, windows only. Created by Betalord, recently taken over by Satirik



That picture was taken under Vista too with all the aero effects turned on and they had no effect on tasclient. Heck when PC Zone rviewed the star wars spring mod they warned people off it as 'rough around the edges' because of the impression tasclient gave them.

As it currently stands glest support is something satirik would never even consider for tasclient. I and the spring lobby people would be happy to support it however.

And all it requires on your side is a command line parameter for the HostIP address, and a parameter to host a game

I'm not asking that you actively participate in our lobby projects and distribute them. That's your choice to make. What I'm asking is that your community has a choice in how they use your engine, or even to create unofficial lobbies of their own. We're offering you a helping hand while your still messing around with the basic of multi-player. You won't have to rush development of your own lobby system if you have one planned as you'll have our projects as an intermediary (and command line parameters can be very useful).

[BrainDamage]

hello, i am one of the SpringLobby devs, i wanted to inform you that while our short term goals are to fully support the spring engine, we're open for support for other games as well, we are completely unrelated to tasclient besides supporting the same game engine and the protocol.

Our code is GPL'ed, so feel free to rip off anything that you can find it useful, even if you're not intrested in our project and want to write your own lobby, you might be able to reuse some of our abstraction code.

atm the parts wich ties the lobby to spring are the unitsync  and tasserver classes, we're moving to a more generic mod & map handler settings system, also we're gonna move to the wxwidgets even based system wich will make the ui class even less spring-related

if you're interested in our project, and want a direct communication channel, you can contact the developers in the irc channel #springlobby@freenode (we got a bot relaying chat so you'll be communicating with more people than you see) or open SpringLobby itself and you will join automatically the channel where devs idles

in any case good luck with your project

POSTEDIT: SpringLobby's website can be found on http://trac.springlobby.info/ and some of the screenshots that AF posted that are in the wiki are outdated, expecially the windows images

[myles]

Thank you Brain & AF but I think that th Glest team want to keep things their way and rightly so, it is their game any how. I think it is a foolish choice on their part, but as Glest is very open to the community and full support from mod developers such as myself I can not see why you don't make your Lobby application for Glest with or without the Glest teams permission as you want, but do not expect the Glest team to make changes to their game.

I do personally fully agree with what you are saying, but the Glest team are simply not interested in changing their way of working, im sure in due time the Glest team will make their own in-game lobby.

Also I would like to say that Glest may not have the same capabilities as Spring or TA3D but it has a great development community and is easy enough for a 10 year old to mod.

Yes I have modded Spring before and found it a very powerful application, but they are both two very different games and engines.

[hailstone]

Very well said Myles. I completely agree.

[AF]

Indeed it seems glests dev team doesn't want to take up my offer. It saddens me however that the decision had nothing to do with my offer though, but rather the merits of my project and one ffo my rival projects where based on an older and inferior project by someone else.

But, the details for how glest would be supported are all worked out in theory, and simply need implementing. I hope I have demonstrated that the task of doing this is much smaller than the task of a home grown lobby program.

Anyone who does wish to help in an unnofficial effort for support need only say so and I'd be glad to help. I would say that someone who knows what they're doing and knows their way around the source could get a glest+aflobby or a glest+spring lobby combo written up and ready for testing in half a day maximum. I sadly am not familiar enough with the internals of glest to be able to do this on my own.

The TA3D people are in a similar setup, however they have decided that they wish to be as open as possible, and provide options for home grown and external and 3rd party internal lobbies by providing the necessary interfaces as and when they can.

They however do not have multi player and are just starting to implement their multi player support whereas you have just finished your first alpha. I can only wish that things change here at glest once an example is made demonstrating a working external lobby program capable of running and starting glest cleanly.

The lobby side implementation has already been tested and put into practice for our implementation of ladder games. All that's needed is for someone on the glest end to start building their half of the bridge.

[weedkiller]

Sorry, but i don't see your problem.
Why are you so angry just because the glest team doesn't want to put all effort in a project that would be very difficult to combine with glest.

If you tracked the developement of glest you will see that the glest team has very little time for their game because they possibly have to do other things in real life. The multiplayer path is the first sign of further developement after a long time of silence. You cannot expect that they have so much time for this cooperative part.
How could they promise to work with you if they haven't the time for it. What would you feel if the tell they help you and then they run out of time?

On the other hand i don't think tha its so easy to change glest to multiplayer. There has been a huge discussion how to implement the multiplayer code and there has been no "golden version" so far. To be concrete, one problem is how to implement the ai. Does only one machine calculate their action and gives just move and build orders to the others? That leads to a bandwide-problem. If it calculates on every machine simultaneously you've got a syncronisation-problem.

So the technical problem is even bigger than how to establish the connection. Of course your code can be very usefull but i think there are only few people who have the time and knowledge to build this to a working part together.

But nevertheless,
my best hopes and wishes to you that you can achieve your aim.

Enough blabla from be, weedkiller

[AF]

Sorry, but i don't see your problem.
Why are you so angry

Because I'm not angry, dismayed that my project was unfairly represented, but I'm definately not angry, you know like when you go to eat a chocolate biscuit and youve forgotten you already ate them the day before?

That and I like to make use of formatting after a post reaches a certain size so it looks 'prettier'

just because the glest team doesn't want to put all effort in a project that would be very difficult to combine with glest.

I've already shown that this is nonsense. the effort and tiem needed to do this is tiny compared to the time needed to build an entire home grown lobby. And I'm not alone in this opinion, and I do have the experience to back it up as a lobby developer myself.

If you tracked the developement of glest you will see that the glest team has very little time for their game because they possibly have to do other things in real life.

All the more reason to offload the lobby process onto another project while they're doing their own thing.

The multiplayer path is the first sign of further developement after a long time of silence. You cannot expect that they have so much time for this cooperative part.

I didn't, otherwise I doubt I'd be here offering them a much needed helping hand.

How could they promise to work with you if they haven't the time for it. What would you feel if the tell they help you and then they run out of time?

Because I only need a one off thing to be able to add support. After that the glest developers can forget about it and get on with their own work and any maintenance would be my responsibility.

On the other hand i don't think tha its so easy to change glest to multiplayer. There has been a huge discussion how to implement the multiplayer code and there has been no "golden version" so far. To be concrete, one problem is how to implement the ai. Does only one machine calculate their action and gives just move and build orders to the others? That leads to a bandwide-problem. If it calculates on every machine simultaneously you've got a syncronisation-problem.

Did I mention I am also an AI programmer over at the spring project? Over at spring we were handed a source code package all ready and done with multiplayer finished by the SYs when they opensourced everything. Since then it's been refactored repeatedly and improved, we've had other people with their own smaller engines with experience in different types of multiplayer design come forth and offer their wisdom.

I'm sure the same will happen here if you let it, but I fail to see how this has any bearing on this thread once you realize that this would not require active maintenance and feature growth from the glest team unless they wanted to add features themselves.

AIs are easy. An AI would be hosted by a player and thus only be loaded and ran on that players machine. It would then be represented as a player on the network and thus an end machine would handle it just the same as a player, only it would have extra information in the GUI saying that player xyz is an AI.

So the technical problem is even bigger than how to establish the connection. Of course your code can be very usefull but i think there are only few people who have the time and knowledge to build this to a working part together.

But we already have a working part sitting over on my website being actively used. It even had a minor update release yesterday. An entire server and lobby environment ready made for you with minimal responsibility and effort involved. At the very least as a stopgap untill you can build your own lobby this is a golden opportunity.

But nevertheless,
my best hopes and wishes to you that you can achieve your aim.

Enough blabla from be, weedkiller

[jbr]

Ha, at first glance that entire post looks like a giant quote.

Look, I'm sure that your lobby system could work, but the developers just don't want to rely on or accomidate someone else's code. That's just not the way they do things. The only thing I can see happening is that they may create some sort of flexible system that can take in ip data from another program or something so that you can set a file path in the xml and call up a compatible lobby executable whenever you want.

Just be glad that they are willing to make it free; they have a right to manage the project the way they want, you didn't pay anything for it.

[AF]

The only thing I can see happening is that they may create some sort of flexible system that can take in ip data from another program

That's exactly hat i asked for. It's the only thing the glest devs would have to do. No future responsibilities. Once that feature is implemented that's it, they don't have to bother looking at the lobby system again it's all taken care of.

Look, I'm sure that your lobby system could work, but the developers just don't want to rely on or accommodate someone else's code.

Once again, once that feature is complete there will be no need for accomodation. And they do not have to rely on me or anyone else either, they can continue with their own plans for a homegrown lobby, it's all upto them.

The glest team don't even have to implement the feature if someone can write a patch that does it, even if that then results in it being in some unnofficial glest.

[jbr]

So basically at this point you're either waiting for a niche for a lobby to show up or forking a lobby enabled version. Of course, it does sound pretty easy, all we would need is support for scenarios that include network players. That's probably coming anyway. Just have a lobby system that generates a temporary xml file for the network game set up by the host, and start up glest automatically loading the xml. But if we could do that, we wouldn't even need a lobby program, we could just post the xmls or even email them.

[AF]

Indeed spring has script files the lobby generates, so spring users could do that, but they don't, namely because it's easier to use the lobby then to edit an xml/tdf file and send it out. It's the same with sending out IP addresses.

On top of which some users are insecure about sending IPs due to security, and the idea of a lobby acting on their behalf covering up all the internals for them is comforting.

I would recommend you use a lobby either way as the benefits can be enormous. For example TA originally had intergalactic war games where players in the community picked a faction and then played battles over planets. Then there's the ladder and tournament stuff, and the auto balancing of teams based on ranks and so on. The channels also act as a central place for modders to talk and for users to see progress happening.

[spoilt]

Glest is awesome!!!! Sadly, I've discovered glest only a month ago. I must say it's quite addictive. Can't wait for the multiplayer mode!!!! Well done guys! Note: Glest is available at Fedora's repo as well!

I've got a little wishlist for the new upcoming version:
- I would like to see more maps in the game - installed by default ( why don't you include the 3rd party maps from

Code: [Select]

[url=http://www.glest.org/files/contrib/maps/]http://www.glest.org/files/contrib/maps/[/url] ? )
- A couple of new scenarios.
- In the multiplayer mode, when the user that hosts the game is using a 3rd party map, the other users should be able to download the new map automatically.
- I would love to see some battleships in the next releases (there are some ocean maps available! )

Keep up the good work guys! Congrats for your efforts. Glest is the best linux game ever!!!

[daniel.santos]

spoit,
You're on the wrong thread.

weedkiller & jbr,
Your closed-minded attitudes are saddening.  It's as if you didn't even read AF's posts, you just jumped straight into familiar thought patterns.  I can probably implement the command-line interface AF mentioned in less than 2 hours (and I'm still very new to the glest code).  One of the most annoying dynamics that I witness from people is the transition from unhappiness, to a call for action, to positive change, followed by comfort and settling back into the same types of thinking that caused the original unhappiness.  The concept of free software sprung from an climate where companies were moving towards proprietary, closed systems, a.k.a., "lock down."  Such behavior stifles innovation, academia and productivity and harms the consumer; it almost killed IBM.  Glest is made possible by open standards and free (as in freedom) software.  So why you would be behave in such a phobic manner towards open standards could only lie somewhere between bizarre and inane.

AF was accused of being angry and flaming by devs and others alike.  I read his post and I certainly don't see it.  Criticism is not the same as a flame.  If you can't take constructive criticism, you will stagnate.  I have seen this time and again in numerous community projects that were handled similarly.  Ego + closed-mindedness is a bad combo.  We all have room to learn, grow and expand, but can only do so when we have humility and open-mindedness.  Whatever gems have been gleaned from the Glest project are insignificant compared to the power of the dark side, err, I mean the possibilities of what Glest has yet to become.  Why settle for a really cool game when you can flip the gaming industry on it's head?  Openness encourages creativity and enthusiasm -- just like all of the enthusiasm from being able to mod Glest so easily (a very open aspect of the game).

AF,
I'm planning on bumping the Gentoo ebuild for beta1 as soon as I find a revision I like (I haven't gotten to play with the latest revision enough yet).  I can add use flags (with associated patches) that will enable an interface for either of these lobbies, but I could use a little bit of starting pointers from you.  This method has the tendency to stay relatively clean across revisions of the code as long as it doesn't change too drastically, and can still do a good fuzzy patch.

Sorry for my long shpiel, I'm practicing to become a motivational speaker.  If that fails, I'm going to try preaching or politics.

[martiño]

Hi,

We don't mind constructive criticism. However we made a conscious decision on running the project the way we do it, and we are unlikely to change it .

Kind regards.

Martiño.

[Boirunner]

I'm just popping over from Spring to let you know that we aren't all like AF.

In fact, he is a very poor representative of our community. He is generally found to be hard to get along with on the forums, and of the 100 to 250 people online at any given time, anywhere between zero and two are using his lobby program, AFLobby.

I completely understand your wish to remain independent concerning a multi-player matchmaking program, and even if you at some point would decide to cooperate with the Spring project and work on a joint program, AF very probably isn't the ideal person to work with.

Sorry for bringing drama over here, but I thought you should get some perspective on who made this thread.

[daniel.santos]

Martiño, I have no problem with the way you guys have decided to run your project, something is obviously working.  I think that some interface (like the command-line idea) could really help in the short run.  But I wish there was some unified "lobby program" (as I see it's called) in the open source community (forgive me if I'm wrong, I haven't looked into it much).  A long time ago, I used a windows app that did this, but primarily because it would run your games and tunnel the IPX packets through UDP, since most games back then only supported multiplayer via IPX.  But it was cool because you could log in and chat and stuff, and then offer to play any game that you commonly owned with one or more users.  Once one of the accepts, the game launches on both ends.  I wish I could remember what it was called, it's name escapes me at the moment.

Either way, thank you for considering my comments.  I enjoy this game very much and I"m looking forward to participating in expanding upon it (we're talking about an expansion to magitech mod in community development forum).

[AF]

I'm just popping over from Spring to let you know that we aren't all like AF.

In fact, he is a very poor representative of our community. He is generally found to be hard to get along with on the forums, and of the 100 to 250 people online at any given time, anywhere between zero and two are using his lobby program, AFLobby.

I completely understand your wish to remain independent concerning a multi-player matchmaking program, and even if you at some point would decide to cooperate with the Spring project and work on a joint program, AF very probably isn't the ideal person to work with.

Sorry for bringing drama over here, but I thought you should get some perspective on who made this thread.

While I admit I was hardly the ideal citizen when I arrived on the spring forums back in 2005, I have improved vastly since then.

As for the popularity of my lobby, it is somewhat of a moot point at the moment as it isn't bundled with the installer and there is currently no official release that works with the current server, although people on the FGJL forums have had access to a working version for almost a week, and anyone who asked would have gotten a copy earlier too.

Such are the labours of university and coursework deadlines. However everyone who has ran it lately has given me praise over its execution speed in comparison to the competition, and there are those who are eagerly waiting for the next release. It may also be of note that most AFLobby users don't want to join the #aflobby channel, or that they wont be using aflobby right now because protocol changes broke it.

This project is at a critical stage and does not need someone barging in with a handful of jokes that could very easily set off fireworks.

When discussing the required changes the following command line parameters where proposed and implemented in aflobby:

Hosting:

glest -h

Joining:

glest -j <IP> -p <port>
glest -j 192.168.1.1 -p 123