Idea: Separate the GunZ lobby into a new client

[peaceofpi]

GunZ's combat interface leaves very little to complain about, but the lobby interface, while perfectly functional, is very dated. This idea popped into my head pretty recently: Make the GunZ client like that of League of Legends. Modify Gunz.exe to only be used for gameplay and develop an entirely new lobby client.
Note: I'm a programmer both by hobby and trade, but I don't know the GunZ codebase well enough to back up the idea that this is feasible. I'm just pretty sure it is and want to toss the idea out there for more capable brains to chew on.

One major advantage of this approach is that the lobby client can be written in something much more straightforward and maintainable than C++. Performance is a non-issue here! My dream client would be in C#/WPF Anyway, another cool thing would be that different servers could use different lobby clients; the only thing they really need to have in common is the ability to launch the game, which would presumably be standard procedure. Hell, you could probably fit the core functionality into a console app.

Thoughts?

 

[Solaire]

It can be done and it wouldn't be hard to do, at all. Just create a C# application (there's several C# emulators available if you look around, most of them were written in 2010-2012 I think, use them as a base to learn about the protocol) and set-up a connection to the MatchServer with this C# application, enabling lobby use only (character selection can be a setting of some kind). Then modify the game client so it can auto-login, auto-select character, auto-select channel, auto-select stage / clan-war and you're good to go (do it based on application arguments or something so you can still use the client without having to use the C# application, forcing people to use 2 clients is definitely not going to work for everyone).

It's basically:

- Start Gunz.exe from within your application, pushing the stage MUID, credentials and other stuff (take note of encryption!)
- Gunz.exe detects the parameters and decides to not launch in regular mode but quick-join mode or whatever you name it
- Wait for the loading to complete, then auto-login (ZPostLogin)
- Auto-select char (ZPostRequestSelectChar?)
- Auto-select channel (ZPostRequestJoinChannel?)
- Auto-select stage (ZPostRequestJoinStage?)
- Mark stage ready and/or join game if already in progress

 

[iFinn]

I've had the same thought, however, gunz reads all the Models at once, as opposed to League of Legends that reads the model that will be used in each game,
In Gunz, you will have to wait one minute or more to go into battle by having to carry all the models, I know of ways to do this, more would be a lot of waste of time, players would complain too much, the way it is the gunz carries everything once

 

[Keristrasza]

Totally pointless z-z

 

[Chiquita]

Try to create more device for gunz, like Linux, MAC OSX, Android version or others.

 

[Hashed]

something similiar to this idea was achieved by Snails years ago, his project was called 'pan' I think? do as wizkid said, understand the protocol, then put it to work. seperating isnt a good idea imo, but a 'clientless' gunz client would work nicely..

 

[iFinn]

a lot of things is possible, so that in my server, my login is made by the launcher, I thought about making the character selection in the launcher also, for I would have to do the c # read mesh, thing I do not know

 

[grandao]

I think Solaire gave all the steps you must follow to implement it.
Just adding to the idea, I don't think it is useless, you could add a "micro server" (database less) to the laucher so that you could play on LAN with your friends without the need to find a pserver.
Further if it really gets implemented we could have a unique domain (site) where you can "register" your local server so that others could join it via WAN. Therefore one eliminates the need for pservers, people would be able to play as long as there were some one wanting to play, and one would be able to gather all players in a single domain. Also if one doesn't want to "host" (the host would be a single room) it locally, this microserver could be hosted on a cheap vps.
Also as it is a "distributed server" one reduces the need of a high performance server implementation, and reduces the surface for DDoS, like we see in almost all pservers.

I really liked this idea, if i find some free time I'll work on the client to parse a cmd line and automatically join a room.

BTW, I time ago I was writing a database less microserver in lua (using luvit, runs on linux, uses less than 10MB ram) where it accepts any login/pwd and sets up a character with the login you used, and it was able to handle DM game mode (currently I stoped working on it).

 

[peaceofpi]

Thanks Solaire for your advice and thanks everyone else for the (useful) inputs!

I'm very interested to hear what all of the experienced people have to say about this idea. I certainly hadn't thought about iFinn's point before.

 

[medotarek]

i think no need for it ?

 

[Solaire]

I've had the same thought, however, gunz reads all the Models at once, as opposed to League of Legends that reads the model that will be used in each game,
In Gunz, you will have to wait one minute or more to go into battle by having to carry all the models, I know of ways to do this, more would be a lot of waste of time, players would complain too much, the way it is the gunz carries everything once

Depends, most computers nowadays can load the entire mesh in under 5 seconds. GunZ was developed in 2005, we have much more processing power than we did back then.

But regardless of that, you could modify the client to only load the meshes required for the current game. Not sure how, I've never looked into it, but you could probably write an abstraction layer that gets the mesh out of a cache and loads it if not already in the cache.

a lot of things is possible, so that in my server, my login is made by the launcher, I thought about making the character selection in the launcher also, for I would have to do the c # read mesh, thing I do not know

Why's that? You could select a character based on name, you don't need to have the meshes for that. You could even list the names of the equipped items (just grab them from zitem.xml, you can easily parse XML in C#).

 

[iFinn]

Depends, most computers nowadays can load the entire mesh in under 5 seconds. GunZ was developed in 2005, we have much more processing power than we did back then.But regardless of that, you could modify the client to only load the meshes required for the current game. Not sure how, I've never looked into it, but you could probably write an abstraction layer that gets the mesh out of a cache and loads it if not already in the cache.

This is true, but not many players have good computersAbout storage only what is used in battle, will be some bug when a player is entering the battle and you do not have the loaded model, or when a player leaves to change item and re-enter the battle, so each time you get in any battle, there would need to carry all models, even unusable.

Why's that? You could select a character based on name, you don't need to have the meshes for that. You could even list the names of the equipped items (just grab them from zitem.xml, you can easily parse XML in C#).

I know that, but what would grace the player only see the name of the items equipped rather than visualize the complete character?

 

[Solaire]

This is true, but not many players have good computersAbout storage only what is used in battle, will be some bug when a player is entering the battle and you do not have the loaded model, or when a player leaves to change item and re-enter the battle, so each time you get in any battle, there would need to carry all models, even unusable.

Yeah but you can just load the additional models when a player enters the room, right?

I know that, but what would grace the player only see the name of the items equipped rather than visualize the complete character?

It's a light-weight lobby client. I don't think players would care that much about the appearance of their character in this client.

 

[jetman82]

If you think the interface is dated, why not just replace mint with something like scaleform?

 

[Hexooo]

This is something I've toyed around with recently. It's a really neat idea with a lot of possibilities. Personally I'm not a huge fan of C#, and I feel like in terms of maintainability and ease of design, there are a few better alternatives.