Thx for the feedback, here is some more info:
I began this project some months ago because i wanted to experiment with WPFs 3D capabilities. As i'm a big fan of ZK (the technical background, the community, the way it's played, how it looks - everything rough on the edges but quite compelling when you get into it) i thought about using something game related as sample data.
I found it in the map resources which are nicely provided by spring/zk infrastructure. The idea was to generate a 3D meash from the heightmap, merge maptexture and metalmap and project it on the mesh. The result can be seen
here. The map viewer can be rotated, zoomed and panned.
This view is merely a mockup, it currently uses the 3 images as input but can be bound to arbitrary images. Using a tip from enetheru in the spring forums it might be possible to add the water plane, too.
After playing with the 3D stuff i thought this would look cool in ZKL. I explored its code and read about the spring lobby protocol. I never wrote code for server-client software based on a custom protocol, so i went on...
Ok, what is it now, actually?
You can see it as a prototype or spike solution to a lobby client for spring games for Windows. The only 'real' functionality (protocol commands) is
-
connecting to server
-
logging in, exiting
-
listing users, reacting to incomming/exiting users
-
listing channels
-
joining, leaving channel, reacting to joining/leaving clients
Additionally there a commander setup view and a stats comparison view. Both are aimed to provide access to ZK-specific content.
The
comm setup mirrors the websites functionality with some extras. The modules are selected using drag&drop. Incompatible modules (weapon boosters/conversions) indicate incompatibility. Changes in setup instantly adjust the visible stats of chassis and weapons. Selection a morph level shows the matching model (Its nice to see it grow next to the glaive for size comparison. I imported the bombard comms level models in Wings3D, placed them in a row, screenshotted them in orthogonal view and pixelpolished that a bit).
The
stats view is intended to let you compare your comm setup with other units. its uses the calculated stats of your selected loadout and the stats of all zk units (parsed luas from zk repo, parser is part of the project and could in theory work automatically). The units can be selected by fac (see buttons above chart) or individually (using the popout shown in th screen).
There are only two stats categories (healt and cost) but thats extendable (i'll be more specific on that part shortly). The idea of this is, to make it easier for players to estimate a comms effectiveness and get a better feeling for its value. Also it could be a nice reference for unit-X-is-soo-OP forum threads.
So, that's what you can see for now. Beneath that, there is a client software which is designed to be heavily extensible. At the core of it sits an
IoC container (well, kind of - its MEF) which allows extension at almost every level of the software (simply by putting a dll containing extensions in the apps bin folder). The following things are currently extensions:
-
sections ('you', 'play',...)
-
subsections (each section can define its own kind of subsections witch special behavior)
-
lobby protocol commands
-
comm setup modules (weapons, special weapons, stackable, ...)
-
com comparison stats pages
As you see, theese are things at very different levels of abstractions. Developing stuff like this makes it more easy for other people to extend the software, especially if they only care for a specific topic and don't want to learn about every detail.
The internal lobby protocol client is a tcp client using .NET 4.5 async/await features. It provides all events as observable event streams using
ReactiveExtensions. RX is a great technology for building complex event-driven architectures. Think of it as SQL on events or continuosly changing data.
The protocol client is used by some services (providing channels, users, ...) which in turn can be used by the ui to create views.
The UI is completely WPF, relying heavily on external libraries such as
ModernUI and
Helix Toolkit. It follows strictly the MVVM pattern (dividing UI behavior from appearance). All chrome is defined in theme resources which makes the application extremely skinnable (for some examples see
ModernUI docs). The window can be configured to be fullscreen (no task bar). When switching sections or subsections, a transitions runs (new section slides in).
As you see, this thing has grown from a-little-hacking to something bigger. So big, that i don't know what i should do with it now. When working on it i envisioned many things, but the question is what reality has got in mind.
I think, it can grow into a full-fledged lobby which gives the user a nicer entry to the game(s). It can look very different to SpringLobby or ZKL and provide a more game-like frontend. Using full screen (and maybe even match the style of ZK's loading screens sometime) could give users a seamles transition between lobby and game (it would look like one software, no need for a lua lobby). I'm thinking about luring new users into the game by giving them a nice first impession.
Also, this isn't ZK-only. Using a subset (or completely different set) of extensions this thing can be applied to every spring based game.
One point which will bother many of you is the problem of linux compatibility. I'm very sorry that the stack i'm relying on to build software is like that. Running Mono Migration Analyzer on the project shows very sad results (WPF, many .NET 4+ features), so i see no feasible path there. In theory the projects including the view models could be made Mono-compatible but it would take some experienced coder to recreate the views on qt or whatever mono provides as ui layer.
So, finally: is this interesting for the devs and the community? Would anyone want put work into this (coding, testing, design, feedback)? Should i release this?
