UI and Networking

Welcome to the second dev blog entry! Today, we will be talking briefly about the history of the custom client along with some initial UI and networking work. Additionally, we'll go over some of the recent changes to our server software, Sequoia. Most of the content of this post is related to the inner workings of the client and server, but it's also vital that we have a strong base to work with so we can deliver a more stable gameplay experience. # Client If you've seen the screenshots in the previous blog post, you may be asking "wait a minute, why isn't X implemented now even though it was shown in older screenshots?" The client has had two "versions" so far: the initial version, which was called "MetalStory" (what an original name, huh?), was a mess and wouldn't have supported some of our future plans, namely multiple rendering and networking backends. Because of this, the second version, which is what's being showcased now, was developed nearly from scratch (although realistically it was mostly just a bunch of heavy refactors of the MetalStory codebase in a new project). Thanks to that, the current client codebase is a lot cleaner and should be much more maintainable in the future. Theoretically, it should even be possible to add support for normal Maple versions, such as v62 or v83, which we will likely do before publishing the open source version of the client alongside Sequoia in the distant future. ## UI Since the last blog entry, one of the main focuses for the client has been the UI system. UI is an inherently complex problem, as there are countless details, both visual and behavior-related, to consider. If you're not careful, it can easily become a giant mess of spaghetti, which is obviously something that would be better to avoid. I've gone through around ten different prototypes for the UI system before finally settling on this one. ![](https://playselene.com/files/images/website/devblog2-1.png) **MetalStory UI-related git branches** One of the goals of our custom client is to support multiple screen resolutions rather than the locked 800x600 resolution of the real client. Because of this, the UI should be able to handle any resolution cleanly. To support this, the UI is dynamically laid out rather than having hardcoded positions in the code. In the screenshots below, you can see the HUD is centered and positioned at the bottom of the screen, regardless of the resolution. If the screen is wide enough, then the skill macro container will be displayed at the right side instead. ![](https://playselene.com/files/images/website/devblog2-2.png) **Base 800x600 resolution** ![](https://playselene.com/files/images/website/devblog2-3.png) **1080p resolution** Having this dynamic layout system may eventually open the door to things such as custom UI layouts (such as moving the HUD so it's anchored at the bottom left of the screen, for example) or possibly even custom "texture packs" to change the look of the UI entirely. ## Networking What good is a client for a multiplayer game that can't actually connect to a server? Initial work on networking has been worked on as well. So far, the client is capable of connecting to Sequoia, chatting (just sending messages, chat messages aren't actually displayed yet), and warping between maps via portals or the warp command. Since we have full control over the client, we are also designing our own packet protocol. This has a few notable benefits. First and foremost, it breaks every single packet editing based exploit out there (which are already ineffective since our server isn't Odin-based), as they have to be redesigned to work with our custom protocol. While it won't prevent packet editing attempts entirely, it will at least reduce the number of overall attempts (at least initially). That, along with the packet editing checks in our server, Sequoia, packet editing should be completely ineffective when the server is launched. Additionally, having a custom protocol allows us to only have the bare minimum number of packets required for the client to function since we can add them as necessary. Since we will also have them fully documented, errors such as "Error 38: Reached the end of file" will be nonexistent, increasing the overall stability of the client. The custom protocol also gives us the ability to have more control over the client, such as having the job name and maximum EXP defined in a packet rather than being hardcoded into the client: ![](https://playselene.com/files/images/website/devblog2-4.png) **Custom job name without client edits** ## Rendering There isn't a whole lot to say about rendering quite yet, as it's still a work in progress, but one recent major change was switching from the [glium Rust library](https://github.com/glium/glium) to OpenGL directly, which was paired with a redesign of the internal rendering system. Previously, on my computer (i7 6700 + GTX980), the client would get ~110fps in Henesys (in a development build, aka unoptimized), whereas now it gets 400fps or more. In release builds, it can easily reach 1000-2000fps, so things are already looking pretty good. Note that there will eventually be support for limiting the max framerate (along with toggling vsync on/off) so the client's CPU usage doesn't go wild. However, since the client is supposed to run on less powerful computers as well, more work will be done to ensure that it can run at least at 60fps on them. From my own tests previously, running on a 2014 Macbook Pro seems to easily reach that, so it should be an easy goal to achieve when the time comes to focus on client optimizations. ## Conclusion and Upcoming Work That's it for the client for this post. From here, the primary focus for the client will be implementing more UI elements (windows, chat input and history, etc.) along with UI details (mainly animation support). More networking work will be done as well, such as displaying other players in the map and handling movement packets. While this post may have focused heavily on internal features, it sets the groundwork for implementing actual game features on top of it, which should lead to more interesting devblogs from here on out. As a quick demonstration of the current state of the client, here's a quick video. Note that since chat input isn't actually implemented yet, a debug console is being used to enter server commands instead. (This debug console will only be present in dev builds, so don't expect to see it in our public release!) It's still obviously very much a work-in-progress, so many details, including the fade transition between map changes, aren't implemented yet. There's also numerous bugs, such as NPCs sometimes not appearing, being flipped incorrectly, or displaying on an incorrect platform. These will all be fixed as time goes on, but currently more work is being put into supporting new features rather than fixing bugs. <iframe width="1280" height="720" src="https://www.youtube.com/embed/b0Lq_N2sJCY" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> ---- # Server Sequoia has been undergoing numerous internal changes, mostly cleanup work to increase the overall stability of the server. Out of the box, Sequoia currently only supports WZ XML data, which is essentially just an XML dump of WZ data. In order to better support our custom client, Sequoia now supports registering custom asset sources (as alternatives to WZ data) along with custom protocols via "core plugins," which are Java JAR files that are loaded when the server starts up. ## Custom Asset Sources The Selene client uses a custom binary file format for its assets that we call "Eos". In order to be able to use Eos files directly in Sequoia (rather than having to dump them to XML first), we implemented an asset source implementation which takes advantage of these recent changes to Sequoia. Not only is it much faster than the XML backend, but it also tends to use less memory (which isn't that big of a deal, but is still nice to have). This is all done without having to modify any of the core server code, keeping it clean from our custom content. For those of you who may be interested in how it all works, the Sequoia API exposes an interface called "AssetSource," which is responsible for reading an asset file (such as Character.wz or Character.eos in this case). ![](https://playselene.com/files/images/website/devblog2-5.png) Our Eos source implements this interface and all of the related methods, and then gets registered upon server startup as a core plugin simply by placing the compiled JAR into the core-plugins directory in the server directory. ![](https://playselene.com/files/images/website/devblog2-6.png)![](https://playselene.com/files/images/website/devblog2-7.png) Now that the source is available, it can be configured in the server's configuration file, which will cause it to be used when the server is started. ![](https://playselene.com/files/images/website/devblog2-8.png)![](https://playselene.com/files/images/website/devblog2-9.png) ## Other Stuff Outside of that, Sequoia now also supports running multiple worlds. Additionally, Henesys PQ was implemented, which brings the missing PQ list down to: - ~~Amoria PQ~~ - Crimsonwood Keep PQ - Ellin PQ - Guild PQ - ~~Henesys PQ~~ - ~~Kerning PQ~~ - ~~Ludibrium PQ~~ - ~~Ludibrium Maze PQ~~ - Magatia PQ - Orbis PQ - Pirate PQ - ...plus even a custom PQ or two This isn't necessarily a comprehensive list of PQs, but rather the PQs we plan to have ready at launch (not all of them may be enabled at launch, as we also have plans to rebalance some of these to make them worth doing in the first place). ## Conclusion and Upcoming Work Sequoia, while mostly functional, is mostly undergoing a lot of cleanup work internally, which should increase the overall stability of it. We still have plans to improve performance and scalability, which we especially want to have so the server launch goes smoothly (unlike how Helios and most other server launches go…) On top of that, changes to better support the custom client are being made as necessary. The next blog post may feature more details as more networking work is done on the client. ---- That's all for this post, join [Selene's Discord](https://discord.playselene.com) if you haven't already!

Back