Category Archives: Game Design

Plants Update

I wrote this last week put forgot to post it.

Got a large update today. The last week I have been in the zone and have gotten a great deal done. First off, we reworked our website a little. In my last update I said I was working on implementing plants. At that point I was still in the designing phase for them. Since then I have finished implementing them and much more.

For every feature my mantra is easily moddable but lots of control. All of the supported content up to this point has had one form of communication – engine asking for the entities components which are returned in component definition form. I struggled quite a bit while attempting to fit the plants into this format. I finally came to my senses and realized what I had to do.

All of the plant logic resides inside of python. How the plant grows, how it visually looks, how it is harvested, and even how it is planted. With this solution, any modder has unlimited control. As for the “easily” part of my mantra, I am wrapping the core plant concepts up into nice little python classes which are extremely simple to use. I have included the code below for those interested in its awesomeness.

Because of this approach I have had to go through my entire game engine and expose it to python. This is something I have been putting off because I wasn’t sure of the requirements, boost python is a little scary and I knew it was going to be quite an undertaking. With this beast finally slain, creating new content will be much easier and have even more freedom.

Here are some screenshots featuring the plants that can grow overtime and be interacted with. There is also an early version of the grass. Right now the grass just grows on soil and is destroyed when the tile underneath it is removed. Later today I plan to make grass occasionally spread to nearby areas as if seeds were dispersed.

You can harvest the trees too!

This is the Zebra tree script that most people will see and have to worry about. I hope most of this is self explanatory. We are adding the different components to the zebra tree entity and the ZebraTree class is used to override the default properties of the tree (which can be seen below). We can add bases, trunks crowns and saplings images and they will be randomly used in the appropriate places. We can also override many other properties such as the seed it produces how tall it can grow, and how fast it can grow.

name = "Zebra Tree"

add(ModularRender())

interactable = Interactable()
add(interactable)

class ZebraTree(Tree):
trunks = [TreeImage("mods/base/plant/tree/zebra/trunk1.png", 2, 28), 
TreeImage("mods/base/plant/tree/zebra/trunk2.png", 2, 28), 
TreeImage("mods/base/plant/tree/zebra/trunk3.png", 23, 28)]
crowns = [TreeImage("mods/base/plant/tree/zebra/crown1.png", 34, 101), 
TreeImage("mods/base/plant/tree/zebra/crown2.png", 31, 98)]
saplings = [TreeImage("mods/base/plant/tree/zebra/sapling.png", 8, 33)]
seed = "mods/base/plant/tree/zebra/seed.ce"

def __init__(self, entity, organic):
super(ZebraTree, self).__init__(entity, organic)
def createZebraTree(entity, organic):
return ZebraTree(entity, organic)

add(Organic(createZebraTree))

Here is the Zebra seed script which is really simple. As with all content entity scripts we add the needed components, this time a Render, Item and Interactable components. The important part here is that we add an interaction “use” and provide the “useSeed” function which is defined in the tree script just below this one. To make this function reusable the plant the seed creates needs to be bound to the function provided – in this case we provide the path to the zebra tree.

import functools

name = 'Zebra Seed'
render = Render('mods/base/plant/tree/zebra/seed.png')
add(render)
item = Item()
item.stack = 999
item.delay = 200
add(item)

interactable = Interactable()
interactable.add("use", functools.partial(useSeed, "mods/base/plant/tree/zebra/zebra.ce"))
add(interactable)

Now for the meat of the tree logic. Here is the tree script which contains the Tree class and useSeed function that are used in the above scripts. As with everything this is still in the works but is most of the way there. I’m not going to go into detail in this now since there is so much going on but if you understand it then awesome. Once things start becoming finalized we’ll write some official documentation on these sorts of things. I put this in a pastebin because it is somewhat large.

Tree script

Lastly, I wanted to throw in the grass code which I’m happy about because I was able to write it without making any engine code changes. There is still in the works but I have the basics down. I will likely do the same for the grass that I did for the tree and have a base Grass class and allow for inheriting and changing the properties without having to worry about the logic. Pastebin link for the same reason as above.

Grass script

Thanks for reading through all of this! I know it is a lot. I’m interested to hear what you think of this.

Creating Placement Items

First of all, this builds on top of my previous blog update so you should read that now if you have yet to. This post will go a little more in-depth into what it takes to create an item that can be placed in the world.

Starting out lets say you are an amazing artist or have one on hand – like I do! Said artist has created an ingenious llama statue.

Hello, I am a Llama.

Now you want to place it into the game… but how do you do that? Inside of your item mod directory you need to create a content script so Crea knows about your statue. Here is what the script would look like.

name = 'Llama Statue'

#Render Component
render = Render('mods/base/item/llama_statue.png')
add(render)

#Item Component
item = Item()
item.stack = 999
item.delay = 200
add(item)

#Craft Component
craft = Craft('Home', 'Decoration', '') #Category, Subcategory, Surface
craft.add('mods/base/tile/stone.py', 50) #Materials needed
craft.quantity = 1 #Quantity made from a single craft
add(craft)

#Placement Component
placement = Placement()
placement.addAxis(PlacementAxis(AxisType.AXIS_FLOOR), Vector(5, 32))
add(placement)

I added in some comments for the crafting since I have not covered that before, but what we are really looking at is the placement component at the bottom. Items are composed off a list of possible axes that the item can be placed on.

The item can be placed on any axis but only one at a time. The types are floor, ceiling, left, right, backwall and wall. Backwall is the a tile in the wall layer. Wall is the combination of left and right. In addition to the axis type, each axis has a range, an area, and a list of supports.

The range of an axis defines where and how much support is needed to place the item down. This is the second parameter for PlacementAxis. In this case we have Vector(5, 32), which translates to start at pixel 5 on the bottom of the image (since it is floor) and go for 32 pixels. This will default to starting at 0 and using the entire axis length. The reason for this feature is to enable items to have a skinny base and only require support for the base and not the entire width of the item.

Area for an axis is the game’s physical representation of the item relative to upper left corner of the image. This area is used to reserve space for items in the world. This area defaults to the size of the image.

The last part of an axis is the list of support it can provide. It is defined very similarly to an axis with a support type and a range of where and how much support to provide. The type can be on any one of the four sides; top, bottom, left or right. Here is an example of a table placement with support on the top.

placement = Placement()
floorAxis = PlacementAxis(AxisType.AXIS_FLOOR)
floorAxis.addSupport(PlacementSupport(SupportType.SUPPORT_TOP, Vector(3, 57)))
placement.addAxis(floorAxis)
add(placement)

And now we have a llama standing on a table!

Here are a few cool features about the placement system.

  • Item placement is on a per pixel – not a grid.
  • Item placement is smart and provides some tolerance to moving to unavailable spaces.
  • When you have a placeable item as your active item you will see a semi-transparent hint of where it will be placed.
  • An item can have an animation component added to it with animations named to the different axes. The game will automagically use the correct animation when the item is placed.
  • An axis can have any number of supports, which means that you can do something like a Menorah.

Overall this system is really flexible and provides an extreme amount of power to both modders and world construction. Currently its biggest limitation is that items cannot be placed inside of another item. This limits some items such as a bookcase and placing individual books in it. It is probably still possible – just have to be creative! If the demand is high in the future I may revisit this limitation but for now it is something I am willing to live with.

Feel free to ask any questions or give constructive feedback. This is my first attempt at writing a more in-depth guide to modding.

Crafting in Crea

When I first started brainstorming Crea and how I would do things differently from current sandbox games, crafting was the second thing that came to mind (after modding of course). The positional crafting system in Minecraft is an interesting approach but it, like other crafting systems, share a common problem: The player has no idea what can be crafted and/or what materials are needed for an item. Nearly everyone (if not everyone), loads up Minecraft, plays around a little bit and then opens up a wiki to find what items to craft and what is needed. The same goes for Terraria for the most part. In the end, players become wiki dependent and consequently the game does as well. This stops in Crea.

A player must first aquire the recipe for an item before being able to craft it.There are several means to acquiring recipes: monster loot; treasure chests; quests; and, most importantly, the Researcher NPC.

The Researcher is specifically for discovering new recipes. First you provide the researcher with materials. Upon returning to him after some time, you gain any recipes his research turned up. We are also considering a hint system that will help steer players into being able to discover more recipes.

This should help give new players direction and also keep them in the game. Basically, crafting will feel like a natural and intuitive aspect of the game rather than a mystery that requires switching in between the game and a wiki. Another exciting aspect of this crafting system is that it lends itself to the ever-expanding content Crea will see.

Terraforming in Crea

Randomly generated content can be great and sometimes not so much. If the input is too constrained, then the result is something that is different and yet all too familiar. I think this can be seen in the Terraria world generation. Terraria has a fairly limited number of biomes and how they are used is restricted. Such as a large world will always have 6 floating islands and there is always one dungeon. After a few worlds patterns quickly become apparent. Don’t get me wrong though. Terraria can provide dozens of hours of exciting exploration, but the novelty does eventually wear off.

World images created with MoreTerra

When I set out designing the world generation for Crea, I knew I wanted to enable players to be able to have unique experiences with every world. The answer was quite obvious – moddable biomes. If players could easily create their own biomes or play with other player’s biomes then the possibilities are endless. Here is an example of what a biome content looks like.

biome.name = "Plains"
#How often this biome should be used
biome.frequency = 50

#The minimum and maximum dimensions of the biome
biome.minWidth = 80
biome.maxWidth = 300
biome.minHeight = 80
biome.maxHeight = 300

#Specifies that this biome only occurs on the surface
biome.surface = True

#The elevation of the biome
biome.elevation = 100

#The amount of elevation changes (hills) in the biome
biome.hilly = 10.0

#How much the lowest and highest elevation can differ
biome.relief = 2.0

#A list of biomes that cannot neighbor this biome
biome.blacklist = ['Volcano']

#List of actions to apply to the world
#This part is still being worked on.
biome.placeTiles('stone', frequency=20, pattern)
biome.placeTiles('mud', frequency=10, pattern)
biome.plant('grass', frequency=40)
biome.plant('tree', frequency=5)

Some of these details will change but this gives a good idea of what a biome looks like. Most of the contents are explained. You can do simple things like increase the ‘hilly’ and ‘relief’ properties and have mountains. For the real power we have the actions section at the bottom.

After the basic terrain has been generated, each biome has it’s list of actions applied to it. In this case all Plains biomes will have stone randomly placed, then some mud, then lots of grass will be planted, and finally a few trees. I plan to include several basic actions that players can use to make creating biomes as simple as possible, but what if you want to do something completely different? Lets say you want to build a crazy dungeon. For advanced modders, I have added a special action that takes a callback function which provides you ample power to twist the world to your desires.

Now that we know how biomes are made, the next logical question is “How are they used”? Players will have the option to create a world with simple or advanced options. With simple the player chooses a name and the world size and is good to go. From the advanced options the player is also able to adjust the frequency of biomes. Want a world consisting purely of bunny warrens? Kelley, our artist, does!

Not only will players never have to see the same world twice, but they will be able to explore the worlds that they want.

Behold the Power of Modding

I have been rambling on about this sandbox project being mod friendly, but I haven’t given any details. How will the mods work? What will they look like? I want to take the time to answer these – please bare with me as this is  more technical than previous posts. Mods will work through the power of Python, a scripting language, and a component-based engine. Each piece of content has its own text file that describes how to create it in game. This file is actually a python script. I will touch on why this is so important soon. The content definition file is very readable and I am doing my best to simplify it. Before digging in too deep lets look at an example – a simple pickaxe.

name = 'Pickaxe'

render = Render('mods/base/item/pickaxe.png', SpriteData("Pickaxe"))
add(render)

item = Item()
#How many of this item can stack in one inventory slot.
item.stack = 1
#How often the item can be used. This is in milliseconds.
item.delay = 200
add(item)

#Adding a craft component enables players to craft the item
craft = Craft('tool')
craft.add('mods/base/tile/stone.py', 2)
craft.add('mods/base/tile/wood.py', 3)
add(craft)

#Tool components makes the item be able to break down compatable tiles
tool = Tool()
#Each tile has a life amount that is decreased by tool's power - once zero the tile breaks
tool.power = 1
#How far can the tool reach - this is in pixels (tiles are 24x24 pixels)
tool.reach = 125
#Which tiles the tool is compatable with. This can list tile groups ("soil") or specific tile names ("stone")
tool.compatable = ['soil', 'stone', 'sand']
add(tool)

Any content created in game is known as an ‘entity’ and each entity is composed of one or more components. Every component has a specific function such as a render component is used to render the entity to the screen and a craft component is used to provide information on how to craft the item. An entity can have any combination of components added or removed from it, which makes the system very modular. At entity creation the content script, such as the above pickaxe script, components are added with the add() function – such as add(render). You’ll see that a pickaxe is composed of a render, item, craft and tool components. Don’t want the pickaxe to be craftable anymore? Simply remove the craft component. Remember how I said that this is a python script? Because of this it opens up all kinds of doors. Some components will provide the power to define custom functions. What this means is that content can have unique logic inside of it. Here is one quick example.

Say you decide you really hate monsters attacking you while you’re trying to mine for some copper. You’re a simple man with simple pleasures. You don’t ask for much. Then suddenly you have an idea – lets make a new piece of equipment that insta-kills any monster that comes in contact with you. This can easily be done by adding in a custom OnHit function to your newly crafted equipment piece. You won’t worry about those monsters anymore as they squirm on the ground in agony at your feet.

If I lost you with my first mention of functions, then don’t worry because as I have previously said, all of the included game content will be a mod. Consequently, there will be plenty of examples to copy from. Also we’ll do our best to provide lots of documentation on modding. This is just one example of the true power of modding.

Sandbox Modding

My last post I introduced this idea of building a sandbox game that is mod friendly. What does this “mod friendly” actually mean? Isn’t decompiling the game’s executable and editing the source code considered as supporting mods? Not quite. Decompiling is obviously a way to mod games, as Minecraft and Terraria have proven, but it is still far from being truly mod friendly. To be fair, these games were built by very small teams (1 and 2 people respectively) and being mod friendly can be a lofty goal. To me, mod friendly means to make creating, sharing, and managing mods as simple as possible for the average player.

Creating mods will be simple and fast but still provide much flexibility for those with big plans. Tools will be provided to help perform the more basic tasks such as setting up a mod. Adding content will be as simple as creating a new file, typing in a few lines, saving the file, and then loading it up in the game. No compiling will be required. One goal I have is to make it possible to reload content in game to help streamline the creation process. No restarting necessary!

The provided mod tools will help with packaging up a mod as well. Once packaged a player simply has to drop the mod package into their directory and the game will take care of the rest. We are also considering providing an official hub to upload mods to. Eventually, if the game gets onto Steam, we would love to support Steam Workshop. This is a service provided by Steam that allows players to easily share, search, and subscribe to game mods.

Players will be given the ability to enable/disable mods and even completely remove the mods all in game. The goal is to minimize the amount the player has to manage mods externally. We even have plans to make the multiplayer host (aka server) provide any missing mods to joining players.

The way that we will ensure that this game is truly mod friendly is by dogfooding it. All of the game content will actually be a mod to the game. With this philosophy we will be able to ensure that nothing is hardcoded and nearly every single aspect of the game can be modified. This won’t just include the basics such as items, monsters and tiles. It will include much more such as biomes, NPCs, character customization, and eventually the ability to add entirely new systems to the game.

In my next post I will go into the more technical side of how the game will be made mod friendly.

Sandbox Concept

I am almost ashamed to admit it, but I have never played Minecraft - “Minecraft is a game about placing blocks to build anything you can imagine.” I remember first hearing about it when it started to really pick up momentum about a year and a half ago. I watched videos of all of the amazing things that people would make in it but I never caved in. Due to Minecraft’s popularity, several Minecraft knock-offs have been done to only mimic the core basics, not add anything substantial to the formula, and then profit like mad. The first true exception I saw was Terraria, which actually builds onto the core mechanics of Minecraft and its inspirations. Terraria adds NPCs, much more in-depth fighting (bosses included!), and some more RPG elements.

Back in November Aaron, my brother and Siege Games designer, picked up Terraria and before too long I was sucked into it as well. We played an alarming number of hours before we even started to slow down. To revitalize the game some, Aaron began looking into the mods for the game and even tried making his own. I watched and cringed as he fumbled around trying to decompile the executable just in order to add a mod to the game. After much hackery he was able to get the game recompiled but broken. It wasn’t much longer when we decided that the game had ran its course.

Fast forward a few months, I had been struggling to get the movement down for Crazy Old Me for a few weeks. I knew its importance but it was really starting to take its toll on both the project and me. So much so that I began an innocent brainstorming of “If I were to make a game like Terraria, what would I do differently?” The answer was clear – “Easily moddable”. My excitement grew exponentially as I began to realize the implications that this could have. Many people describe Minecraft as a virtual Lego set. My envisioning is to not only let players play with the Legos but make it easy for them to build the Lego blocks as well. I’m sure Aaron and I could still be playing Terraria if we had at least some freedom in modding it. Of course, the core game has to be enjoyable enough to warrant mods and so Aaron and I had a more official brainstorming session. We came up with some more answers to my original question that could help set us apart.

We were thoroughly seduced by this sandbox idea. So much so that we knew we had to at the very least play around with the idea. Crazy Old Me had not been forgotten but and it did slow us down some but “we can come back to it in 2 weeks” was enough to convince us. So for the last two weeks we have been working adamantly on fleshing out this concept and working on an early alpha. The likelihood of us returning to Crazy Old Me dwindles everyday as we march forth to the holy procedurally generated land. Here are some (random) main points planned for the game. I will go into them in greater detail soon.

  • 2D platformer with building (somewhat given)
  • Easily moddable but with extreme flexibility
  • Unique crafting system
  • Core RPG elements (such as leveling)
  • Colorful and stylized art from Kelley McMorris
  • Multiplayer