...Crazy Miner (alternative) | Day 1
With the arrival of Godot Engine v3, I've switched all of my attention to this new shiny edition. Oh boy, being pleased with this arrival is an understatement!

The development environment feels fresh, snappy, but importantly, familiar! Things have been repositioned and garnished with new bells and whistles. Yet, I'm quickly able to locate old friends and features. The transition, from an editing view point, is will be trivial. Learning the new features, however, will require significantly more effort; given the sheer volume of new features.

The team

We, "the team", found each other via public forums last year, around April '17:

• A graphics and game designer from Iran
• A Sound Designer from Romania (living in Norway)
• A lead developer, from England (that'll be me)
• A support developer (an old friend of mine, from school, keen to learn to code)

Two Game Design Documents (GDD) were penned, artwork drawn and code written over the eight months of working together. Many dozens of prototypes as well as Alpha versions of the games were created and tested. Each improved on the last, but failed to deliver in some important way. A sample set of these reasons include:

Complexity
Lack of solid gameplay
Bugs

Despite these hurdles, we have almost created playable games; albeit, not ready to publish. We now find ourselves back on the mission, given the lead developer (me) is able to dedicate more time to the projects and group. Our intention is to revisit the two games and deliver them as soon as possible to multiple channels. Each game has potential, therefore are worth spending effort on, especially as the team are keen to progress.

However, given the release of v3.0 of Godot Engine, I needed a few days, if not a week, of familiarisation with it. I also had a need to assess portability of the existing code.

In order to do this, I set myself a new challenge.

I dislike the idea of chop and change; i'm a completer/finisher by nature, see the Belbin scale. In fact, this is why we've probably not got over the line with our existing creations! I've fought hard to avoid publishing something that is not full of quality, fun and polish.

...but on this occasion, I need to.

I've decided to take our existing GFX and SFX assets to create a different version of our Crazy Miner vision. I'm going to do this because I wanted to use v3 from scratch; thereby learning its good and bad bits. I will use my few days to migrate some of the existing resources, but implement them in a new game.

That game will be loosely based on a famous grid game, that you collect pills and avoid the monsters! However, I'm going to blend it with our new artwork, style and mining theme; who doesn't like explosions? What could possibly go wrong?

Crazy Miner (alternative) - Tile Map

I name this new game, Crazy Miner (alternative); it will be officially renamed at a future date, if it is ever to see the light of day.

My first challenge is to implement a tile based system for the map. Godot Engine has a brilliant system, built in (as seen on the left).

Clearly, it would be MOST sensible if I were to use it, HOWEVER, I made a conscious decision to develop our own, because the out-of-the-box flavour didn't fit our game need. Often, you will need to weigh up these decision points, ...and often make the wrong choice. The important tip is to learn from mistakes and choices.

I personally hope the inbuilt TileMap has been improved in v3.0, but I'm not going to expend time right now to find out, given my limited assessment period. I will re-evaluate it in the future, and will write a beginners Tutorial for it.

This, therefore brings me neatly onto the design of our TileMap.

TileMaps

TileMaps are simply a technique for placing defined sprites in a predefined pattern to form a map from smaller pieces. The pieces as well as map, may consist of rectangular, hexagonal or some other unorthodox shape; subject to the need of the game.

Tiles

The sprites displayed in the map often need further properties, such as whether they are destructable, or can be traversed; therefore they are built as Tiles.

Hence there is a relationship of: TileMap (one) <> (many) Tiles

Layers

TileMaps are usually formed with layers of tiles. These layers allow different meaning or purposes to be attributed to their use. Each layer will consist of a Tile type. For example, in the Crazy Miner (alternative) version, I need:

• Soil layer - set of passive background tiles, with the lowest position on the screen (z-position)
• Floor layer - set of empty containers, allowing other tiles, such as nuggets to be associated
• Cover layer - set of overlays of the Soil and Floor, which are 'diggable'; i.e. when dug will reveal the floor and soil
• Granite layer - set of active tiles which overlay everything else, acting act as impenetrable walls, restricting movement

Note, the Floor tile is an odd entity! It's purpose is to be a storage pot for the other Tiles; it will be invisible on the map.

The use of the Floor Tile will be discussed in more detail, in a future post, but for now, let us consider gold nuggets which will be placed on the map:

• They must be revealed, when dug, by the digging action of the miner.
• Once revealed, each nugget will be 'flown', as a particle, to the scoreboard.

The Floor tile will allow code to do it's job, by providing the list of objects to show or fly in that particular cell of the map. Alternatively, each nugget would have to be placed on the map and additional code would be required to locate all acting Tiles for the given Miner position. By providing a container, all nuggets in one cell are known, reducing the effort to find and use them.

Design

All good development starts with a little design. I've identified the actors above for the TileMap system, therefore I jotted down a simple inheritence diagram, to both show and remind me (at a later date), the class structure relationships (it is so easy to forget). Godot Engine provides instancing and extension of classes, therefore fits my thinking well.

• A Tile class will be extended by others, such as Soil, Floor etc; thereby providing standard functions and capabilities to all those that extend it.
• A TileMap class associates all Tiles to a Map. It's secondary purpose is to be the screen anchor for the entire TileMap. I.E. if it is hidden, so is the map. If it is placed at position (100, 100), then the first tile is positioned at (100, 100). All tiles added to the Map are physically added to this class (via add_child() method); therefore it owns the Tile for its lifetime.
• A Map class will store the Tiles. In this design, it is a simple Array of Dictionaries. Where the array address is a compressed 2 dimensional array (i.e. to address a cell, calculate [row * width of grid] + col. A dictionary is utilised in each cell because it allows different layers to be formed. Each tile will be given a type and that is used as the key into the dictionary at a particular cell.

---

Note: I have now published a Tutorial with a working sample

---

Bringing it all together

Coming back to the less technical, I built the class structure above and formed a simple TileMap

I've even added a spider! Which, in itself, is a Tile; as will the Miner, when implemented.

Next

The next plan of action is to add the Miner! I'll then give him and the Spider the ability to move.

In the next post, I'll explain why I deemed them to be Tiles too. I'll also discuss the decision of collision detection.

---

Thank you for your time

NOTE: Speedi Tech Ltd & Crazy Career Games reserve all copyright on artwork shown. You may not replicate it, without strict permission.

If you appreciate this post, please do upvote this post, as it important for my longevity here.
Don't forget to click follow on my home page.

If you have any questions or requests, please use the comment section below. I'd love to hear from you!