Speedy Blupi for Windows
The support of future versions of Windows (maybe Windows 12, 13, 14, ...) to run Speedy Blupi I/II is uncertain.
It should be the key goal for us to constantly ensure, that:
- The latest version of Wine project will still support the run of Speedy Blupi I/II - at least until the moment, the complete specification of Speedy Blupi I/II will be completed. This complete specification is necessary to develop Open Eggbert - the free and open source recreation of Speedy Blupi I/II. There should be recorded as much as possible or gameplay videos for various situations in the game. It would be also good to record on the screen some visualization of the pressed keys.
Wine is developed in the C programming language.
Fortunately, there is ongoing work on the decompilation of Speedy Eggbert II. This can later be used as the engine for all the desktop versions of the game. GitHub repository: https://github.com/jummy0/sb2-decomp
Speedy Blupi for Windows Phone
Regarding Speedy Blupi (Windows Phone), it is now not possible to run Windows Phone XAP executable files on Linux.
- It seems, that no such support will exist in the future, as the Windows Phone is a discontinued platform.
It should be the goal for us to document new features and differences (to desktop version) of Speedy Blupi (Windows Phone), but also record videos of playing Speedy Blupi (Windows Phone) via "Project My Screen App for Windows Phone" [1]
It seems, that Speedy Blupi for Windows Phone (the XAP file), can be decompiled using the ILSpy C# decompiler. An alternative implementation of the XNA Framework can be used. Summary: Speedy Blupi for Windows Phone can be probably modified to run on Android, Desktop, iOS or other platforms in the future.
What programming languages and libraries to use for the next decades
Good candidates: Java, C#, C++
Bad candidates: Node.js.
Our goal is to make both Speedy Blupi for Windows and Windows Phone sustainable and easy to run (even in the future)
We should focus on technologies that have a large community and are open, with well-documented tools. Both options, C++ with SDL2 and Java with LibGDX, have their advantages, but here are a few factors that can help us decide.
As few dependencies on specific libraries as possible should be used.
Dependencies, that could become obsolete over time, should be minimized.
Node.js and other not stable programming langugaes
Node.js is not stable, its syntax and rules change very often, there is no backward compatibility, a game written for Node.js will not work even 20 years in the future. Node.js is not suitable for long-term software.
Node.js makes possible to quickly develop software, but then its maintenance is hard.
Flexible Architecture with Multiple Backends for 2D Platformer Game
Your approach of creating a subset of LibGDX enriched with new features and a flexible architecture for multiple backends offers several advantages for long-term sustainability and adaptability.
Advantages of this architecture
1. Flexibility with Multiple Backends
Using different backends (LibGDX, Java2D/JavaFX, LWJGL, OpenGL, Vulkan, WebGPU) allows you to target different platforms and devices. This approach enables the creation of a robust and portable solution for various hardware types and use cases.
2. Compatibility and Future Extensibility
By using Java interfaces to define abstractions between the application and the graphic backends, you ensure that adding or swapping backends in the future is easy. If any older backend becomes incompatible or unsupported, a new one can be added without major changes to the core game logic.
3. Long-term Sustainability
By using well-established technologies (e.g., LibGDX for Java, OpenGL/Vulkan for graphics), the architecture ensures that your game can remain functional and maintainable even as new technologies emerge. Regular updates to the backend libraries will allow you to support current standards.
4. Platform Independence
Supporting multiple backends allows your game to run on a variety of platforms, such as desktops, mobile devices, browsers, and potentially even emerging platforms. This multiplatform support helps ensure that your game remains accessible in the future.
Potential Challenges
1. Complexity
Designing a flexible architecture to support multiple backends means you’ll be adding layers of abstraction. This complexity can make the initial implementation and maintenance more challenging. You will need to carefully design interfaces to ensure efficient switching between different backends.
2. Maintenance of Multiple Backends
Supporting different graphics APIs and backends (OpenGL, Vulkan, WebGPU, etc.) will require ongoing maintenance. Each backend may have different requirements for updates, compatibility, and performance tuning. This could increase the effort needed to keep the game running smoothly across all platforms.
3. Performance and Optimization
Performance tuning across multiple backends could be a challenge, as each graphics API may handle rendering differently. Optimizing the game to run efficiently on all backends requires careful performance monitoring and testing to ensure consistency across platforms.
4. Future Compatibility
It’s important to ensure that all technologies used (e.g., OpenGL, Vulkan, WebGPU) will continue to be supported and available. Keeping track of industry trends and changes in graphics technologies will be essential to ensure the game remains viable in the long term.
Conclusion
If you're prepared to invest time in designing and implementing this flexible architecture, it could be a very powerful approach. The flexibility and multiplatform capabilities of this design provide significant long-term advantages, but the increased complexity and ongoing maintenance should not be overlooked. By following good design principles and performing thorough testing, this approach can allow you to build a game that is functional, maintainable, and adaptable well into the future.