Author Topic: Engineering a lobby.  (Read 2524 times)

Coldfusionstorm

  • Golem
  • ******
  • Posts: 868
    • View Profile
Engineering a lobby.
« on: 24 August 2009, 11:34:04 »
yeah :D, so i will have a couple of thought here about the lobby.

currently we dont have a lobby?, why is this so?

and i would like to clarify what i mean by lobby.

1. a network listening part of the game wich enables you to see local clients on the network.

it is NOT.

2. a part of the game that shows what faction you are and what you will be playing in the game you are currently connected to.

in my mind this would be easy to implement.

now when you are to start a game in glest(a network game that is). you open a single slot, now this is pretty nice but has a bad bi-effect, that you close and open sockets relatively fast. if you change those settings.( i might have a solution for that tho)

so i was thinking mainly you have a "enable LAN" button. wich when enabled broadcasts on your network and thats pretty much that for hosting.

oh, and it will NEED a option to specify what network card the lobby listens on. i cant stand games wich dont do that, it makes it ass hard to use VPN connections like Hamachi. (wich is a great tool for playing over internet).

also, i would like to state a thing this lobby does NOT have the ability to see internet games it could have but im not sure that would be a smart thing. for long distance things you will still need a IP.

hmm, now that i think of it, the current method isnt THAT bad, a lobby dosnt really help on peoples patience.

for joining all you would have to is have a simple GUI and a network code wich listen for these broadcast packets.

PS. im a no programmer (yet/perhaps gonna be? for fun), im gonna do this myself if i learn c++, BUT i wanted to share my thoughts about this as well if any programmer was sitting and thinking damm how the hell do i do this.

This post will get updated with my progress on my lobby as im progressing in c++, this will be one of my first tasks.

so why dont we have a lobby yet(IF it is so easy) and does my idia work?. (i know its terrible simpifyed in the sense but i also do think that is should be so,broadcasting seems very simple to me) and all we need is a packet with a glest host IP in it). and then just use the normal glest join method

im also aware that daniel.santos is writeing new netcode is it tied to that? that you think we will need to rewrite the lobby?.
« Last Edit: 24 August 2009, 11:41:36 by Coldfusionstorm »
WiP Game developer.
I do danish translations.
"i break stuff"

wciow

  • Behemoth
  • *******
  • Posts: 968
    • View Profile
Re: Engineering a lobby.
« Reply #1 on: 24 August 2009, 12:52:28 »

so why dont we have a lobby yet(IF it is so easy)

I think you've answered your own question. Building a lobby is not easy. 

PS. im a no programmer (yet/perhaps gonna be? for fun), im gonna do this myself if i learn c++,

I think you are underestimating whats involved. At the very least you will need to learn basic C++, GUI programming, network code (hard stuff and possibly cross platform!) and then apply this to the Glest engine.

Whilst an experienced network programmer might knock out a test version in a few days, it spells years of work to go from complete novice to doing this sort of thing.

I don't wish to discourage you from trying to learn to code, but I see far too many posts from people stating that they are going to learn to code so that they can build their own game engine by next friday  :D
Check out my new Goblin faction - https://forum.megaglest.org/index.php?topic=9658.0

silnarm

  • Local Moderator
  • Behemoth
  • ********
  • Posts: 1,373
    • View Profile
Re: Engineering a lobby.
« Reply #2 on: 24 August 2009, 13:21:31 »
PS. im a no programmer (yet/perhaps gonna be? for fun)
Quick question, do you find mathematics fun? Logic?
If the answer is no, you're probably not going to find programming to be a very fun experience.

If you answered yes, then good luck, but be prepared for immeasurable frustration...

Whilst an experienced network programmer might knock out a test version in a few days, it spells years of work to go from complete novice to doing this sort of thing.
Just to clarify, that would be an experienced network programmer with an good grip on the Glest engine, not something you acquire overnight ;)
Glest Advanced Engine - Code Monkey

Timeline | Downloads

ElimiNator

  • Airship
  • ********
  • Posts: 3,391
  • The MegaGlest Moder.
    • View Profile
Re: Engineering a lobby.
« Reply #3 on: 24 August 2009, 14:10:02 »
PS. im a no programmer (yet/perhaps gonna be? for fun)
Did you ever do xml? make a tech? couse = programming is double to quadrupleingly way harder!
Get the Vbros': Packs 1, 2, 3, 4, and 5!

Coldfusionstorm

  • Golem
  • ******
  • Posts: 868
    • View Profile
Re: Engineering a lobby.
« Reply #4 on: 24 August 2009, 14:34:11 »
i dont get itimidated so easily, :D, math never really been my strong side, logic, im pretty good at that.

besides i deny that something can be extremly hard.

and btw, i never said it would come overnight.

wich also is why posted here, since my post above.

yes i did XMl's, i have a mod, (but its closed-alpha), mainly because it still sucks compared to full fleged mods, i have some pretty good stuff going on :D.

take years?, well, then im going to either break a record or fail extremly :D.

but im not really busy just yet im only 20.

now im off to IRC, and my c++ tuts examples and so forth, and silarm, i woulndt atually reqiure all that my hope is that i can hook my small code into glest.

i have NO intention of understanding the netcode, only the lobby part. wich is joining.

what i want to code is the ability to see "glest-broadcast packets" and then fecht the ip adress from that packet, and then just use glests method of joining with the fechted IP.

that sounds easy in my ears. but we'el see il come running crying for sure when i discover that it itsnt that easy  ;)
« Last Edit: 24 August 2009, 17:33:33 by Coldfusionstorm »
WiP Game developer.
I do danish translations.
"i break stuff"

silnarm

  • Local Moderator
  • Behemoth
  • ********
  • Posts: 1,373
    • View Profile
Re: Engineering a lobby.
« Reply #5 on: 25 August 2009, 09:24:19 »
now im off to IRC, and my c++ tuts examples and so forth, and silarm, i woulndt atually reqiure all that my hope is that i can hook my small code into glest.
This is true, it's a smallish hack that wouldn't require great knowledge of Glest's inner workings...

Quote
that sounds easy in my ears. but we'el see il come running crying for sure when i discover that it itsnt that easy  ;)
Well, I wouldn't want to see you in tears :) but I suspect it will be harder than you think.
Glest Advanced Engine - Code Monkey

Timeline | Downloads

hailstone

  • Local Moderator
  • Battle Machine
  • ********
  • Posts: 1,568
    • View Profile
Re: Engineering a lobby.
« Reply #6 on: 25 August 2009, 09:26:22 »
The biggest obstacle to a lobby (and other features) is having the right GUI components. Also if you are going to make a lobby you should have at least a basic understanding of networking.
Glest Advanced Engine - Admin/Programmer
https://sourceforge.net/projects/glestae/

wciow

  • Behemoth
  • *******
  • Posts: 968
    • View Profile
Re: Engineering a lobby.
« Reply #7 on: 25 August 2009, 11:32:51 »
From my basic experience of coding I actually found that GUI coding was not that big a step up. Once you have a grasp of OOP, classes, etc its pretty easy draw some pretty boxes on the screen and add a few buttons and text.

As a small time hobbyist, network coding would make me run a mile  :D
Check out my new Goblin faction - https://forum.megaglest.org/index.php?topic=9658.0

Coldfusionstorm

  • Golem
  • ******
  • Posts: 868
    • View Profile
Re: Engineering a lobby.
« Reply #8 on: 26 August 2009, 13:17:16 »
The biggest obstacle to a lobby (and other features) is having the right GUI components. Also if you are going to make a lobby you should have at least a basic understanding of networking.

oh i do, if your talking about packets, TCP/IP UDP and so on, i did take a hmm, we'el call it a course in these things :D, im really allround in computers.

UPDATE: well, consider this halted atm, i simply dont have enough time as it is atm, modding,textureing,concepting,work,food, ect, is all filling up my time, i simply dont have the time to learn c++ also...(the fact that it looks like a daunting task atm dosnt help much either)id rather use my time on the mod where i can see what i do right now :D

REEDIT: corrected ugly grammar.
« Last Edit: 10 September 2009, 10:23:09 by Coldfusionstorm »
WiP Game developer.
I do danish translations.
"i break stuff"

daniel.santos

  • Guest
Re: Engineering a lobby.
« Reply #9 on: 11 September 2009, 23:12:06 »
in my mind this would be easy to implement.
I'm not as nice as others on this board.  I think we need a "Forum Rules" sticky with the 1st rule being that if you say something will be easy to implement then you are banned or made the guest of honor at alt.flame for a month or something.  If it's easy to implement, then do it, don't say it.  Oh, you don't know C++? Then how can you make an assessment about difficulty?  You can't.

so i was thinking mainly you have a "enable LAN" button. wich when enabled broadcasts on your network and thats pretty much that for hosting.

oh, and it will NEED a option to specify what network card the lobby listens on. i cant stand games wich dont do that, it makes it ass hard to use VPN connections like Hamachi. (wich is a great tool for playing over internet).

I agree that it's a pain to have to mess with IP addresses in this day & age.  Glest currently binds to the default local IP address and this isn't always what you want when you are multi-homed.  Most people aren't, but some VPN software makes you appear multi-homed.  None the less, I think this would be a low priority unless there's a lot of people with this problem. In essence, it's the selection of the local IP address to bind to, which isn't terribly difficult in the code its self, but would need the infrastructure to manage it.  Perhaps a quick solution would be to add a NetLocalAddress option to the .ini file that defaults to empty, meaning the default.  This will allow people to explicitly specify an address.  I'm not for selecting by device because this varies widely from platform to platform.  The only way I would be for that is if we pull in some 3rd party library that manage the platform differences and translate that into a local IP address (can you do that in some part of SDL?).  In general, I can't recall any games that bother with this, although I imagine that there are a few that allow you to select the local IP address.

As far as broadcasting on a LAN, I'm not terribly crazy about that idea either.  What has clearly been lacking for some time (and often discussed) is a real meet-up place (currently IRC serves that function).  Somebody has proposed the Spring Lobby in the past and if I understand it correctly, it can be used for GAE, somebody just needs to configure a Spring Lobby server and come up with a client configuration.  Somebody (maybe Martino?) added the ability to launch a network game, on either the server or client, via command line options, and the last I heard, this is all that spring lobby would need.  As I understand it, the command-line options only specify to start in the "new game" (for the server) or "join a game" (for the clients) and doesn't not feed any game settings, which would still have to be selected from Glest/GAE by whomever is hosting the game.

As far as game settings in the lobby, I agree with you.  In the still-not-finished network rewrite, this was addressed.  I posted pretty pics here: https://forum.megaglest.org/index.php?topic=4015.msg24515#msg24515.  This allows all clients to see the game settings as the server changes them and argue about them before the game is started.  The network rewrite keeps things fairly encapsulated so it should be pretty friendly to use with any new GUI and I did not  spend an especially large amount of time (and wont be) on the UI beyond making it minimally functional.  Ideally, once we have the GUI re-write done, it can be "skinned" any way you want to see it.

But back to the LAN concept, I would prefer an easy to access Lobby and you can start the game from there.  Just because you are on a public lobby (like Spring Lobby) doesn't mean that you have to invite anybody that isn't local to your game.  However, I suppose this doesn't take into account VPN addresses (VPN as in non-routing, not secure tunneling that you were talking about earlier), which will be different than the externally exposed IP address.  I guess it isn't that hard to type in an IP address after all. =)

UPDATE: well, consider this halted atm, i simply dont have enough time as it is atm, modding,textureing,concepting,work,food, ect, is all filling up my time, i simply dont have the time to learn c++ also...(the fact that it looks like a daunting task atm dosnt help much either)id rather use my time on the mod where i can see what i do right now :D

IMO, you would need to be learning C++ and related technologies, concepts and methodologies for a good few years before being able to implement something like this well.  I think that since GAE started, the code has become more understandable as I have added a lot of documentation.  Even so, API documentation in GAE is still woefully lacking, so the programmer would have to do a lot of analysis to understand the code before even being able to begin.  I don't think an interest in games alone is enough to become an effective game programmer (I started programming when I was 13).

Omega

  • MegaGlest Team
  • Dragon
  • ********
  • Posts: 6,167
  • Professional bug writer
    • View Profile
    • Personal site
Re: Engineering a lobby.
« Reply #10 on: 12 September 2009, 04:56:14 »
Well stated Daniel!

Networking is hard. I can't even properly understand the principal behind it (care to explain) much less any code! :o

I have a stickied topic in General Discussion for that. Time to go and edit it! ;D

While I admit a lobby would be cool, I consider it too impractical (what's really wrong with the current?) and very difficult. I'd rather had functionality than multiplayer. Who are you planning to play with anyway? Everytime I check, the IRC has a few names on it, but after an hour or so, you leave frustrated, since no one can stay online all day to wait for someone. How would this not happen with a lobby to?!?

So I say forget about the lobby, work on functionality. Maybe in ten years when we have, like, 20 coders around here and a community in the thousands, we'll get on to a lobby (if anyone really wants to. Network codes looks dull!).
Edit the MegaGlest wiki: http://docs.megaglest.org/

My personal projects: http://github.com/KatrinaHoffert

Coldfusionstorm

  • Golem
  • ******
  • Posts: 868
    • View Profile
Re: Engineering a lobby.
« Reply #11 on: 12 September 2009, 15:23:31 »
Okay, perhaps i should clarify that, "in my mind(in my non-coder mind that is), it would be easy. now i say MY mind because it isnt sure it easy. it wasnt a statement that network codeing was easy. at all, :D.

and on to the other, i agree on pretty much everything you said, perhaps apart from the .alt flame thing :D

And just to make sure we're on the same wave-lenght.

I do NOT think that Network codeing is easy,and i think that you do a awsome job with the netcode.

all i said was IN MY HEAD!. then substract my c++ knowglede and that pretty much sums up my codeing abilitys. :D.

anyways, im off agien, modding away :D
WiP Game developer.
I do danish translations.
"i break stuff"

daniel.santos

  • Guest
Re: Engineering a lobby.
« Reply #12 on: 12 September 2009, 16:31:32 »
And just to add some perspective, you are most likely a superior modeler, skinner and animator than I!  It takes me a very long time to do a fairly simple model and I find that those talented in this can do it better in 1/20th the time (literally).  So we all have our strong and weak points.  I think that I'm pretty descent at game design, but the strengths that I bring to this project are definitely in the area of coding, analysis, architecture, (software) design, etc.