magefree / mage

Magic Another Game Engine
http://xmage.today
MIT License
1.88k stars 770 forks source link

Code must be compatible for multiplatforms (example: Android) #4341

Closed rsypen closed 2 weeks ago

rsypen commented 6 years ago

Hello there,

For quite some time I'm working on new XMage client capable of targeting many platforms not only desktops. Currently I'm struggling with deploying my early alpha version on Android.

There are following reasons behind that which I discovered so far

  1. XMage is not developed in a way that should support other platforms then desktop. Some modules that should be platform-independent (like Mage.Common) contains dependencies to desktop specific libraries and/or classes (AWT, Swing).
  2. XMage uses Java 1.8 which is only partially supported by Android. To successfully include XMage modules in my Android project I had to rise min SDK version of Android API to 26 (Android 8.X) which I believe is less then 1% of all devices in Play store right now. So quite pointless to develop and maintain client for such small group of potential users.
  3. XMage uses some old/legacy libraries that were designed only to work with desktop Java. List of problematic libs includes:
    • JBoss remoting
    • H2
    • Log4j
    • ormlite
  4. XMage uses some packages/classes from Java SE not available in Android API.

To allow development of new clients targeting many platforms all of above points should be considered. Here are some of my suggestions that could be applied to make XMage Android client working.

  1. Move all dependencies to AWT/Swing libs from Mage.Common to relevant modules or create new common module for deskop clients that want to use AWT/Swing custom-made components. This step should be fairly easy to achieve.
  2. Downgrade Java version back to 1.7. This step is hard to consider for several reasons but it's like a trade off between losing couple of cool features (like lambdas, default methods, etc.) to targeting wide range of Android devices. I expect that downgrading to 1.7 would allow more then 50% of devices to run Android client without issues (at least one that I'm developing). More then 50% vs. less then 1% makes more sense.
  3. Replace old/legacy libs with new ones designed to run on many platforms not only desktop.
    • JBoss remoting -> any other modern Java/Scala framework I saw one attempt to replace JBoss with Netty (which is good) but branch is not developed for more then 2 years so I consider it as dead.
    • H2 -> SQlite should be fairly easy to implement drop-in replacement for H2 if XMage really needs RDBMS for storing cards/sets information.
    • Log4j -> Logback (it supports Android) - fairly easy to replace.
    • ormlite - not sure about this. Ormlite docs says that "It supports a number of SQL databases using JDBC and also supports Sqlite with native calls to Android OS database APIs", so maybe there is not point of replacing it.

I think that most of required effort is focused around replacing JBoss remoting to modern framework, others shouldn't be hard to change/apply.

I'd really appreciate to hear what XMage developers think about it. I can help making any necessary changes to XMage codebase.

r.

JayDi85 commented 6 years ago

No need to rewrite xmage client code (e.g. GUI). It's can use old libs. Server communication layer must be rewritten/replaced with new libs to support real time multiplatform communication. After that new clients and services may be done like global web chat, stats viewer, games viewer or notification service.

Replace JBoss remoting

Agree.

H2 -> SQlite

Client no need SQL database. It's can use any storage or nosql db.

rsypen commented 6 years ago

I agree, there is no need to rewrite existing XMage desktop client codebase. Did I mention that? 😄

JayDi85 commented 6 years ago

@LevelX2 old post about jboss -> netty:

Also there is still a branch (we need to merge the changes of the last monthes still) that replaces JBoss by netty created by BetaSteward last year. https://github.com/magefree/mage/tree/Network_Upgrade http://netty.io/

But as I used this (netty) version some month ago (2015-09) to install it on the public server, there were some severe problems after some hours. I had to restart the server to get it working again. Also there were happening disconnects, maybe some less than with the JBoss version (but I'm not sure about that). So I decided to return to the old code base with JBoss to have a more stable release.

But maybe it's worth to give it a new try.

An alternate way to go to improve the network situation could also be to find out and fix the reason(s) the reconnect after a disconnect does not work half of the time. This would aready improve the situation a lot. But it's very hard to get that problems clear. So we are always looking for developers that have knowledge about network protocols/handling, that can analyse / fix that problems.

JayDi85 commented 2 weeks ago

Multiplatform (desktop + mobile + web) will be supported by multi-platform game engine (godot as game engine and socket io as network layer). Current java client can be used for windows, mac and linux (including steam decks and other linux compatible hardware), but not for mobile or web.

It’s useless to replace or migrate to new libraries for keeping potentially shared code between different game clients. But it can be migrated as standard project refactor/refreshing (bugs fixing, stability improving, etc).