Fixed a bug where chunks in cache-range were not lightened as expected.

Added cache-range checks.

Improved Chunk’s and Block’s string representation.

Fixed issue #18 where view-range value was incorrectly used when calculating cache width and height. Instead cache-range had to be used and fixed so.

Fixed Chunk.FastSetBlockAt() so that minus world coordinates also work. ChunkCache.GetChunk is also fixed for minus values. Player is now spawned at 0,0.

Moved chunk statistics calculation to ChunkCache.Draw() – finally the values are preserved, which eventually fixes the chunk debug graph bugs.

Added chunk removal queue debug-graph.

Fixed a tiny capture mouse & mouse visibility bug.

Moved ini-file based config-classes from Engine to Client project. Engine is now free of both Nini reference and the ini file itself. The actual game can do what-ever he wants when he supplies parameters to EngineConfig.

The Engine ctor() will now throw an exception when additional instances created (Discussed in issue #43).

Though being a major step with new functionality, I decided to abandon the code base and moved it to /contrib.

But why?

Because it just started as a hack & slash project as mooege, growth unintentionally.

It was primarily a hack to learn to cook block based games. So did I. But the code growth every day with every feature I tried out and eventually become bloatware.

I started to develop it with XNA and then ported major parts to MonoGame. Still it’s quite hard to maintain both of them together. I’ll be just targeting MonoGame from now on as XNA is already dead.

I invented some freakingbugs which initially didn’t exist. I’m already too late to go backwards through commit history to hunt them. As the code uses every bit of available optimizations to improve the performance, you really need practice test driven development which current code base doesn’t.

So?

I already moved the old codebase to /contrib and got some clean space there. I’ll be slowly porting / re-implementing the old-code from scratch – this time with proper tests. So probably until a short time, I won’t be able to publish cool looking screenshots of new features but once I’m all done, I hope to have a clean block-engine code base which I hope that people will find interesting & start contributing. And yes, I’m eager to port it to every platform that MonoGame supports, including Ouya!

So MonoGame is a great technology that allows us write common C# code and deploy our games to Windows-Desktop, Windows-Metro, Windows-Phone, MacOS, Linux, IOS, Android, Ouya and even more. Being able to write portable code is great for us indie developers, though still your code may need some platform specific parts.

With our latest game Frenzied (which can run on Windows, Windows-Metro, Windows Phone 7, Windows Phone 8, Android, MacOS and Linux atm), we introduced our in-house platform-managment concept which we decided to blog about, so that others can also utilize.

Here’s how we are managing multiple-platforms for Frenzied;

First of all we created per-platform solution files;

Each project defines it’s own conditional compilation symbols so we can distinguish them;

Then we defined some enums, the first one is Platforms;

Platforms enum

C#

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

/// <summary>

/// Platforms.

/// </summary>

publicenumPlatforms

{

Windows,

WindowsMetro,

WindowsPhone7,

WindowsPhone8,

Linux,

MacOS,

Android,

IOS,

PSP,

Ouya,

}

GraphicsAPI enum;

GraphicsAPI enum

C#

1

2

3

4

5

6

7

8

9

/// <summary>

/// Graphics API's.

/// </summary>

publicenumGraphicsAPI

{

DirectX9,

DirectX11,

OpenGL,

}

Frameworks enums;

C#

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

/// <summary>

/// .Net frameworks.

/// </summary>

publicenumNetFrameworks

{

DotNet,

Mono

}

/// <summary>

/// Game frameworks.

/// </summary>

publicenumGameFrameworks

{

XNA,

MonoGame

}

Then we implemented our static PlatformManager class, that will be responsible for identifying current platform and running appropriate code.

To get PlatformManager working we have to make two basic calls, the PlatformManager.Startup() and PlatformManager.Initialize(). Startup() call should be made from Program.cs for platforms that have a Main() entrance point where you run the game.

Sample Entrance Code

C#

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

usingFrenzied.Platforms;

namespaceFrenzied

{

/// <summary>

/// The main class.

/// </summary>

publicstaticclassProgram

{

/// <summary>

/// The main entry point for the application.

/// </summary>

staticvoidMain()

{

PlatformManager.Startup();

}

}

}

And in Game.cs (or what-ever you call the Game class) within Initialize() function you have to call PlatformManager.Initialize().

Sample Game Initialization Code

C#

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

namespaceFrenzied

{

/// <summary>

/// This is the main type for your game

/// </summary>

publicclassFrenziedGame:Game

{

/// <summary>

/// Allows the game to perform any initialization it needs to before starting to run.

/// This is where it can query for any required services and load any non-graphic

/// related content. Calling base.Initialize will enumerate through any components

/// and initialize them as well.

/// </summary>

protectedoverridevoidInitialize()

{

...

PlatformManager.Initialize(this._graphicsDeviceManager);

...

base.Initialize();

}

}

}

So PlatformManager will be doing all the hard-work for us. Note that how we handle it specific PlatformHandler and PlatformHelpers instances for each platform.

PlatformHandler is the base class that we can extend to implement our platform specific initialization code and so;