Engine and Networking

This devblog brings us back to the client. Since the last client devblog, there has been a significant amount of internal work done, both for gameplay and performance. These changes bring us closer to starting official testing, which will be discussed in more detail later on in this post. As it's been a while since the last client devblog, there's more information to cover. So without further ado, let's dive in. # Physics The physics system in any platformer is essential for defining the feel of the game. Because of this, one of the primary goals we have with the Selene client is to make it feel as authentic as possible. Not only will this make our client feel familiar, but it will also preserve the vast number of maps in the game, most notably jump quests. If you were to go back and watch all of the client videos we've shared up to this point, you'd find that all of the movement is limited to land, with the occasional ladder or rope. That was very intentional, as movement in water (swimming) wasn't implemented at all! Even land and climbing movement wasn't entirely accurate, but it's much harder to notice that without having the actual client in front of you. The recent client changes include a revamped physics system, bringing it much closer to matching the real client's behavior. As a quick overview, here's how the physics system is looking now: * Ladders and ropes are accurate (climbing and jumping off). * Swimming is accurate. * Flying is partially tested, but mostly accurate so far. * Walking and jumping on land are mostly accurate, both on normal land and snow/slippery land (the remaining accuracy issues are exclusively related to slopes). # Networking A handful of features shown in past client videos up to this point were only clientside, meaning they weren't sent to the server, and other players in the map wouldn't see them. With this recent batch of client changes, that is no longer the case for most of them, including mob movement, attacking, and skills. Skill effects, in general, were reworked significantly, and now more skill effects are working correctly, such as Genesis, Meteor Shower, Blizzard, and Savage Blow. Mob damage is also synchronized across clients, allowing players to see third-person dealt damage and mob death. Movement was also reworked a decent amount thanks to the recent physics changes. Third-person movement is entirely functional now, including walking, swimming, and climbing. The imposed movement delay of 500ms has also been lowered to 200ms for now, although this likely isn't final. For a game that's entirely PvE-based, like Maple, the movement delay doesn't have any effect on gameplay, so realistically it doesn't matter what the delay is. However, being able to lower the delay could be useful for future server features… Last but not least, ranged attacks involving projectiles (including some magic attacks) are now functional as well. With all that said, here's a video showcasing the current state of the client. There are a few visual issues present, such as mobs flashing occasionally, players on the wrong layer, and players sometimes bouncing slightly while standing still, but as usual, this is a dev build and bugs are still expected at this point. <iframe width="1280" height="720" src="https://www.youtube.com/embed/1lYXHh1RyLs" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> # Engine Changes This section focuses on some internal details about the client, and consequently will be more technical than usual. Feel free to skip this section if it's not relevant to you. As you probably already know, Selene uses a custom engine written in Rust. The engine is a standalone codebase that holds common abstractions for game state management and 2D rendering, among other things. At the most basic level, a game requires two parts for displaying the game to the player: a window and a method of rendering to it. This quickly becomes complicated when you need to support multiple platforms. For starters, creating a window is a very platform-specific task that requires platform-specific code (obviously). Not only do you have to worry about creating the window, but you also have to worry about handling events generated by the window, such as when the window is moved or resized, or when the window receives keyboard and mouse input. Doing all of that for every platform you wish to support ends up being a lot of work, and also leads to way more code to test and maintain. Instead of reinventing the wheel, the Selene engine initially used a Rust library called winit to handle all of this window creation and event handling nonsense. Overall, winit worked, but it wasn't quite as robust as I would have liked since it's a relatively immature project, especially compared to the well-known and stable C library [SDL2](https://www.libsdl.org/), which is what Selene is now using. Once you have a window, you have to render to it. One of the most common rendering APIs, OpenGL, is available on all of the platforms we plan to support, making it the obvious choice… right? While it is indeed available on all of the platforms we care about, it is no longer supported on macOS as of [two years ago when Apple decided to deprecate it](https://www.macrumors.com/2018/06/05/apple-deprecates-opengl-opencl-gaming/). This means that it will likely be removed at some unspecified point in the future, so we can't safely rely on it for the Mac version of Selene. However, thanks to the graphics abstraction layer in the Selene engine, this won't be a major issue. While it currently only supports OpenGL, there are plans to support the following (from highest to lowest priority): * Metal for Mac * OpenGL for Windows/Linux * DirectX for Windows * Vulkan for Windows/Linux (not confirmed, as it's probably overkill for a 2D mushroom game, but it's still a possibility nonetheless) The first additional graphics backend will most likely be Metal for Mac due to the deprecation of OpenGL. As a result, we aim to have both OpenGL and Metal builds of the client when alpha or beta testing begins to ensure that they're both thoroughly tested before full release. # The State of Selene Thanks to this batch of internal client work, more focus will start to be placed on implementing actual gameplay features. This means that future client devblogs will begin to become more frequent and involve more gameplay previews rather than technical stuff like this post. With that in mind, we're getting closer and closer to starting our internal pre-alpha testing, which will consist of the Selene team exclusively. Our pre-alpha stage aims to test the initial playable builds of the client in preparation for the closed, invite-only alpha, where we will send invites to non-team members. Note that we plan for alpha to last much longer than beta, as we intend to have the game feature-complete by the time we start the beta phase. We still don't have any public ETA available right now, but rest assured that good progress is being made! # Conclusion This was a very technical post compared to previous client devblogs, but it was also a lot of necessary (and extremely tedious) work that needed to be done in order to create a strong foundation for future client features. As mentioned previously, future client devblogs will start to focus more and more on gameplay, which should lead to more frequent and more exciting devblogs for the non-technical members of our community. Thanks for reading, and we'll see you in the next post! And as always, our [Discord](https://discord.playselene.com) is always available if you have any questions or comments.