This is the next post in my Fondusi’s Development Blog series. Click here to check out week 2 or start at the beginning.

Week 3 – August 15th – 21st

This week we added some extra mapping tools like the paint bucket, which fills an area with a certain tile, and the eye dropper, which allows you to select a tile from the map (so you don’t have to find it on the tilesets). We also set up “tile behaviours” which is going to be the focus of this post. We did some other things as well, some of which warrant (I think) their own posts. You can find them listed under “The Rest” below.

Tile Behaviours

In the old version of Fondusi’s, each tile had a type which was an enum that determined what that tile could do. The enum contained values like:

  • Sign — Send a message to the player when the tile is interacted with
  • Shop — Open a shop window when the tile is interacted with
  • Block — Stop a player before they enter the tile
  • Class Block — Stop a player before they enter the tile if they are a certain class
  • Warp — Warp a player somewhere when they enter a tile
  • Heal — Fully heal the player when they enter the tile
  • Etc. — There were about 20 entries in this enum overall

Now, this worked, but what if we wanted a tile that would warp someone somewhere but ONLY if they were a certain class? While you’re thinking about that, I also wanted to mention that each tile had three ints and three strings associated with it for storing data for some of these types. The thing to note is that more often than not (i.e. for the majority of tiles), those six variables took up space and were not even used!

Related Posts

» Fondusi’s Dev Blog – Week 6 – Part 1 – C# Sockets and Servers
» Fondusi’s Dev Blog – Week 5 – Lighting and Spatial Partitioning
» Fondusi’s Dev Blog – Week 4 – Lighting and Shaders
» Fondusi’s Dev Blog – Week 2 – Pixel Shaders and Moving Players
» Fondusi’s Dev Blog – Week 1 – Tile Engine and Map Structure

Have you figured out how to make a tile to warp someone only if they’re a certain class yet? Well, as I’m sure you’ve guessed: YOU CAN’T! With the old system, you’d have to set up a choke point (e.g. a door, hole, entrance, etc.) that had a class block tile on it and then put the warp on a tile behind that point. This wasn’t so bad. It was the way it had to be and we just worked around it. However, in writing the new engine, we wanted to make sure we weren’t wasting space and that we could maybe simplify things a little bit (or, I guess, make them more complex… 😛 I just mean we wanted to break down that huge enum).

Andrew and I started discussing this and we decided to take a bit of a behavioural, object-oriented approach. We noticed that there were three distinct “tile behaviours” that would cover all of the different tile types. If you were quick, maybe you noticed them in my list above. They are:

  • Interaction — Such as Sign or Shop
  • Approach (or “before entry”) — Such as Block and Class Block
  • Entry — Such as Warp or Heal

So we went from asking “What TYPE of tile is this?” to “What does this tile DO when {x} happens?” Now, this is a little more work to set up, but it encapsulates all code relating to a particular behaviour (i.e. Warp) into one class. We also encapsulate the saving and loading into each class which allows us to only save the necessary amount of information per tile. Great!

Since each tile has one of each of these behaviours, we can mix them together. So now, by adding a ClassBlock Approach behaviour to a tile that has a Warp Entry behaviour, we can actually have a warp tile that only works for a certain class! Woo hoo!

Note: If you’ve read my Week 1 post, it’s important to note that these behaviours are actually at the MapCellLayer level, not the Tile level. This is because tiles in that regard refer to the actual drawn tiles from the tileset. There were no “layers” in the original engine and Map Cell and Map Tile were synonymous, hence my use of the word “tile” above.

The Rest

Here’s a list of the other things we worked on this week:

  • Added the ability to switch between player control and camera control on any tab (it was only on the editor tab before)
  • Added some validation functions for mouse clicks on the game from (see here for more details)
  • Added an outline for the player name font
  • Overhauled the particle engine system to make it more generic and useful

Some of these things I’m planning on writing other posts for and I’ll updated this again when/if I do. Of course, if there are any requests or questions, please drop a comment.

That’s all for now, folks!