Trebuchet Games Ltd

Launching Game Experiences

Dev Blog - Working with Code in MMF

Clickteam Fusion is a great product for non programmers, designers and artists to create their own games. Without programming knowledge but a good general knowledge of logic you can create projects up to the same quality as anyone else.

But with this simplicity comes some issues. While everyone is waiting for version 3 of Fusion which should remove some of these issues, here are a few pointers about the Event Editor/Level Editor.

1. Think about how you are going to group objects and code before you start. MMF's Event editor is not particularly user friendly once you have a lot of objects on the same frame.
2. Consider using the layers object to handle visible/invisible. This is the quickest and easiest way to have objects appear and disappear before using the standard visible/invisible code to make certain objects state.
3. Where possible use behaviours for common tasks such as fading in and out, that can save you code duplication and reduce the code within your frame that is visible. When your game gets big, this can really help.
4. Consider grouping code into common elements for each frame such as Initialisation, Appearance, activation.

As we move forward in Dead of Day we begin to find better ways of making the code more efficient and easier to read, but hopefully our advice will make you think about your code and structure before you start.

Dev Blog - Core Game Screens - DOD

Putting together the core gameplay screen elements.

Over the last few days I've been putting the graphics that the artists have been working on into the game engine. It's a bit of a slow process as the images come to me unprocessed and so some work is needed to get them in the right order/layer. These last few days I've been working on the core gameplay screens, this is where you will spend a lot of your time moving around the game world looking for resources. Originally this was going to be 4 different screens in the game engine "Clickteam's Fusion," but it actually worked out better to put all of the four screens into a single "level". I then used layers and qualifiers to switch on and off the graphics when needed. It can get messy working with so many different graphics, that's why it's important to use the layer system to switch on and off layers as you are adding the graphics to the game level, it makes it much easier to see what you are doing.


Figure 1.0 The Layers toolbar.

Note: Qualifiers are the ability to group objects in code, that way you can tell Fusion to make a whole group visible or invisible in one action rather than needing to code it for each individual object.

Next I'll discuss the four screens that I've been working on and what work has been done on them.

Game Screen
Inventory Screen
Map Screen
Rest Screen

Game Screen
The Game Screen is the screen that you will move around the corridors and rooms of the post apocalyptic game world. We're still working on the graphics for the actual game world, but all of the surrounding UI has been complete. It didn't take long to get the different elements into the level such as characters and buttons. There is still quite a bit to do on this screen as though some of the buttons have been connected up, we are still missing key elements such as the mini map.

Inventory Screen
The inventory screen is where I spent most of my time yesterday, mainly getting the graphics into place and making sure it was activated and deactivated using the button on the game screen. Code wise I had to think the best way of creating an inventory using only code. Initially I was going to have each inventory box as a separate object, the benefit of this is that it's easier to code. The downside to this is that it is more memory intensive (as each inventory box has its own memory space) and it increases the number of objects in the game. I then started to look at using duplicate objects. The great thing about duplicate objects is that they don't use any additional memory, they don't add 100 odd objects to the game, the downside for me is that I've never been totally comfortable in using them. Duplicates are great for using when you have many of the same type of object, such as an enemy space ship. To get my inventory to work, I've used the Spread Value option. This puts a value (from 1..2..3 etc) in each duplicate so that I can then identify them when i need to. The most important thing to remember about duplicates is that if you can any value in the properties window, it will update all duplicates with this value. You can only change data individually for each duplicate at runtime.

Now that I have some working code for the inventory, I need to replicate this across all 100 items. Should take me a couple of hours to fix it up. At some point I will need to be able to load in data at the start of the frame to place objects in the inventory, these items will also need to know what type of equipment they are and any stats that come with it.

Map Screen
The map screen is where the player sees the area that they are moving around. There will be an element of fog of war, as we do not want the player knowing where they can move to. Most of the graphic items are in place for the map screen. We do not have any data being loaded in just get as this will need to come from the map editor that is currently being written.

Rest Screen
If the players are too injured or need time to recover. The rest screen is quite easy to code and will be coded at a later stage once other elements are in place.

Dev Blog - Where have you been?

Welcome back!

So it's been a while since I last did a development blog, mainly because things were moving forward, but moving slowly (if you are an indie developer you'll understand sometimes months can pass without much progress). Working full time and trying to make an indie game is never a good combination, especially as my day job is making games, and when you get near to the end of a project there's always lot's of overtime to get it complete.

I intend to start the blogs back up now things have been progressing well.

In November/December last year I was able to secure some match funding from Creative Englands - GamesLab system. This is where you put in some of your own money and they match it. There are rules and processes to follow and it did take a couple of months to get it all moving forward (lots of paper work :) - In April after working with a number of companies to secure examples of work, I selected both a musician and set of artists who would work on our first indie game.

Since April the design has generally been locked down and the artists have been creating content - mockup art based on my example drawings and then the final art assets. Things have been progressing well and many screens have much of the art already complete. There is still much to do but considering this is the largest indie game I've ever attempted I'm really pleased with it's progress.

I've got a little bit of time off work, so while I do that I will be posting a bit more information on what I am working on each day, and then get back into a weekly dev blog cycle.

Dev Blog WE 20/12/2014

Here is the Trebuchet Games DevBlog for the week ending the 20th December 2014. Read More…

Dev Blog WE 13/12/2014

Here is the Trebuchet Games DevBlog for the week ending the 13th December 2014. Read More…