Mobile Eggbert

Open Eggbert
Release date	25th November 2024
Github	https://github.com/openeggbert/mobile-eggbert
Github Android	https://github.com/openeggbert/mobile-eggbert-android
Programming language	C# 4
Game framework	MonoGame

Mobile Eggbert is a 2D platformer game based on Speedy Blupi for Windows Phone.

The ILSpy decompiler was used to get back the C# source code of Speedy Blupi for Windows Phone. The decompiled source code is not the same, as the original was. Comments and names of local variables are lost. See also: Category:C Sharp decompilers

The discontinued XNA 4 game framework is replaced by MonoGame game framework. MonoGame is almost a drop-in replacement for the XNA. There are several implementations of XNA 4.0 game framework (like FNA or others).

See also: Category:Alternative implementations of XNA

Work on Mobile Eggbert started on 23rd November 2024.

Already on 23rd November 2024 the game was successfully decompiled and made runnable without any errors on desktop (Windows and Linux). The support for mouse and keyboard was added.

On 25th November Mobile Eggbert was released for Windows and Linux: https://drive.openeggbert.com/Mobile_Eggbert/

• It works without any issues.

Why Mobile Eggbert was created

Mobile Eggbert was started, because:

1. Windows Phone is a discontinued closed-source proprietary mobile operating system (developed by Microsoft company for smart phones).
2. Devices with Windows Phones are no more produced. Windows Phone operating system cannot be installed on other modern devices.
3. Without physical device with Windows Phone installed the emulator is the only way to run Speedy Blupi (2013) nowdays. But the emulator probably will not work in the future, as it is a closed-source proprietary technology.
4. Because the source code of Speedy Blupi (2013) is not available, it is not possible to make improvements or bug fixes.

Current status

Mobile Eggbert works on Windows and Linux.

Mobile Eggbert starts on Android, but it is buggy: scaling is wrong, touch controls are not working correctly, worlds are not loading.

Issues and the future

Mobile Eggbert is buggy on Android and must be fixed.

Accelerometer support is not yet available. It will be added for the Android platform.

Local variables must be renamed to the correct names.

Comments must be added.

Some refactoring is planned.

Porting to FNA or an alternative XNA 4.0 is planned to be done.

If the C# version will be kept, then there will be probably 3 modules: mobile-eggbert-core, mobile-eggbert-desktop and mobile-eggbert-android.

Mobile Eggbert will be rewritten to Java. MonoGame will be replaced by JXNA.

• Or there will be created a transpiler from C# to Java: named OMJ

Why Mobile Eggbert should be migrated to Java

Java is stable with over 25 years of history. It is backwards compatible, which guarantees, that the Java code will work in the next 10 or 20 years

Java is multiplatform, because it runs on JVM

Java is the native programming language for Android

MonoGame versions are tightly dependent on concrete .NET versions.

C# is historically less robust on Linux or MacOS

Why Mobile Eggbert should not be migrated to Java

JVM is less optimized for high-performance applications and game. But this should not be problem for Mobile Eggbert, as it is a 2D game platformer.

LibGDX does not support consoles (Xbox, Playstation, Nintendo Switch).

XNA Game Studio 4.0

XNA Game Studio cannot be installed on Windows 10 or newer. This is the reason, why there was no attempt generate a new XAP file using the decompiled C# source code.

Including world{}.txt files in the build

MonoGame doesn’t automatically place non-content files like .txt files into the appropriate build output folder unless you configure it properly:

1. Set the Build Action for the .txt Files

You need to set the proper build action for these files so that they are copied to the output directory when the game is built.

   Right-click the world*.txt file(s) in the Solution Explorer.

   Select Properties.

   Set the Build Action to Content.

   Set the Copy to Output Directory to Copy if newer or Copy always.

This ensures that the files are included in the final build and can be found by TitleContainer.OpenStream.

2. Verify the File Path

When you call TitleContainer.OpenStream(worldFilename), you should be passing the correct relative path to the file. If the file is in the Content folder, you should use the file name relative to that folder.

For example:

Stream stream = TitleContainer.OpenStream("world1.txt");

If the files are in a subfolder inside the Content directory (e.g., Content/Worlds/), use the full path relative to Content:

Stream stream = TitleContainer.OpenStream("Worlds/world1.txt");

4. Debugging

If the file is still not found, check the following:

   Ensure that the file path is correct (check for typos or incorrect folder structure).

   Verify that the file exists in the correct directory after building the project. You can do this by inspecting the output directory (e.g., bin/Debug or bin/Release) after building the game.

You can also print out the file path to ensure it's being referenced correctly:

Console.WriteLine("Looking for file: " + worldFilename);

5. Consider Using ContentManager for Loading Content

If you are using MonoGame's ContentManager to load other content (like textures, sounds, etc.), you might want to load text files through the same system to ensure better integration. For loading text files with ContentManager, you could add them as "Text" content and load them like this:

var textContent = Content.Load<string>("world1");

In this case, you should:

   Set the file’s Build Action to Content.

   Set the Copy to Output Directory to Copy if newer.

   The file should be placed under the Content folder.

External links

https://docs.monogame.net/articles/getting_started/index.html

https://www.codeproject.com/Articles/754354/Port-a-2D-libgdx-game-to-MonoGame