Hey everyone, this blog has been relocated to siegegames.com. This means that this is my last post here. Your subscription will NOT carry over so please resubscribe as I have lots of good stuff coming. Thanks!
I am doing my best to avoid reinventing the wheel. This is quite obvious with my extensive use of third party libraries to help with nearly all aspects of the game engine – from rendering using SFML to randomly generating worlds using ANL. This backfired on me this past week.
At first I set out to work on the world lighting. After doing some research I stumbled upon Let There Be Light (LTBL), which helps with basic lighting and shadows. I began incorporating it into my game engine and quickly found that it had some fundamental bugs. I posted to the linked forum post above in hopes that the developer would fix these issues. I was pleasantly surprised at how quickly the developer fixed the issues. Not long after resuming I once again got caught up on something and had to wait for the developer’s response. The developer was great about replying and I’m really appreciative about it but I do doubt that this was the right path.
I know what I want for the game’s lighting. LBTL gets me about 70% of the way there with minimal effort but I have to tweak and bend the code to my design. This is going to take a great deal of time and in the end it may have been faster to just throw together my own lighting system. I may still do this using LTBL as an example.
There was progress made for lighting though. I setup a light and hull (shadow casting) components. This means that entities can have a light source attached to them and/or have a shadow casting convex hull attached to them. Here is an example with a hull attached to the player, which needs much work.
During my downtimes between the lighting, I would work on the world saving. I am using boost for much of my game engine and decided to use the boost serialization library to do all saving/loading. This library has some really cool features but these features come with a heavy cost in code complexity. Before too long I realized that I did not need these features and so I was back to square one. I decided to do my own and within no time I had the basics working.
I started doing some testing. First I tried a small world of 100×100 tiles was saved to a 73kb file; this worried me. I want to have huge 8000×2000 worlds at least. So I tried a world at this size… 120MB! Additionally it took about 4-5 seconds to save. This is good for a first run but it is unacceptable and needs some serious optimization.
First I’m going to do compression on the data before saving it to disk. Fortunately this data is very compressible given that it is extremely repetitive. I tested this by zipping the small world save file. It went from 73kb to 1kb. This is promising! This helps with disk size but it is going to hurt the time. My plans for fixing the time is to reduce saving data that hasn’t changed. Right now the entire world is saved every time but the reality is that only a small portion of the world is going to change in a minute. One of the cheapest ways to do this is the same way Minecraft does it – split the world up into separate files.
This week I’m going to work on finishing up the saving/loading, which is going to take a little longer than I initially thought. What doesn’t though? If things go well then I will get back to working on the lighting. Before too long I’ll be able to have some visual to show off!
I have mentioned Terraria on several occasions here. One thing I have neglected to mention is that a month ago Redigit, one of the developers, announced that Terraria’s development has ceased. The other developer of Terraria, Tiy, has gone on to work on a spiritual successor to Terraria, Starbound. One the surface Starbound looks familiar to Terraria, but once you start digging it becomes apparent that the design direction is quite different. Nearly everything is going to be procedurally generated as hinted at in this indiegamemag.com article. In Terraria only the world is generated and all other content is predefined. In Starbound, weapons, monsters, worlds and I’m sure basically everything else is going to be generated on the fly.
I wonder if monsters attacks will be randomly generated. One attack would be the creeper attack, which is a Minecraft monster that gets next to you and explodes. Just imagine you’re walking through a forest and then you spot a deer-like creature grazing. You really want to pet it so you slowly walk up behind it. Just as you extend your hand to touch its side, it turns its head toward you, glares for a second and then begins to flash. BOOM! The deer explodes and leaves a nice crater in it’s place. I’d buy that.
Starbound Arctic Planet
This design approach is not all too surprising. Sandbox games lend themselves quite well to generated content. I think this is mostly because sandbox games are all about exploration of the world and your imagination. When the world is generated with lots of parameters the sheer number of possibilities becomes nearly limitless.
There is one problem with this though. Because Starbound is putting so much focus into the randomly generated content it limits the exploration of your imagination. I am of course talking about modding. It does sound like there will be some support for mods but it seems to be more of an afterthought. Regardless, this game is going to be legendary.
As promised, here is my first development update on Crea. We’ve made tremendous progress over the past month but to keep things short I’ll just cover what I worked on this last week. The majority of my time was spent working on water simulation. At first I was not sure what the best approach was, but after some research I discovered the joys of cellular automata. For research I found these articles to be quite useful: Gamasutra article, Compressing Space and Time and Cellular Automata for Physical Modelling.
Simulating fluids with cellular automata is reasonably cheap, which is needed with worlds as large as the ones in Crea. A bonus to implementing a cellular automata system is that it can be used to simulate other things – fire! I am rather pleased with what I have written thus far and would eventually like to write a more technical blog post about it, but that will have to wait. It is time to break up my wall of text posts with some actual content. So without further ado, here is the first look at the game and its water simulation.
In other news, while I was watching last week’s Indie Chatter, he mentioned a website that he uses for project management, Pivotal Tracker. I looked into this and it has some cool features such as automatically calculating what tasks you will be able to complete over the next iteration (typically a week). The thing that really stuck out to me is that projects can be public, which means that anyone can see what is currently being developed along with when releases are set and basically everything else.
Last week I said I want to try to be as transparent as possible, well here is the Crea Pivotal Tracker. It is a little bare at the moment because I just started it up on Friday, but I will be doing my best to keep it updated and filled with all of the stuff I am working on. Perhaps I will even be able to convince Aaron and Kelley to join in on it.
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.
When we started this new game project a month ago we somewhat jokingly called it Crea. Well, the name has stuck. We have stolen the name from an older project of ours – “We will finish Crea!” I still like the name and it is a good fit.
In other news, I want to share the plans for this blog as well as Crea.
This is obviously a game development blog, but I want it to be more to it than just that. I would like this to be a conduit between us, the devs, and you, the community. Consequently, I’m striving to be as transparent as possible. This means we will be giving somewhat frequent development updates, showing early WIP screenshots, revealing game systems early on and much more. We also want to be able to take feedback and incorporate it into the game.
I am still getting into the swing of regularly posting updates and I have been considering attempting a posting schedule. My current thoughts are that I will do a weekly development update on Monday and on Thursday or Friday do a more lengthy post discussing some aspect of the game in detail. I will even take requests for the in-depth posts.
Now onto the plans for Crea. Back at the start of development we sat down and sketched out a very rough project timeline. We have 5 phases of development planned: Early Alpha, Alpha, Beta, Release, and Post-Release.
- Early Alpha is all about getting the fundamentals down. So it primarily consists of just the basic systems – world generation, saving/loading worlds, world manipulation, multiplayer, crafting, lighting, and a few others. Another week or two and we’ll have all of this done.
- Alpha is when things will start to get more interesting. We will be adding in character creation, character stats, equipment, NPCs, enemies (death included), and refining the systems from early alpha. We are aiming to wrap this up by the end of April. We are being optimistic!
- Beta will be bringing in a wave of great additions. We will begin putting together the mod tool and documentation for adding mods. Also many other exciting things such as adding in weather, animals, and what we are calling “interactive items”. With this being further out it is hard to say how long this will take but we are once again aiming for roughly a one month period – end of May.
- Release will be all about polishing things and getting it ready for the world. If the game is accepted onto Steam then time will be spent implementing some Steam features.
- Post-Release is currently a dumping grounds for ideas that we like but are not vital for release. I imagine that as we move forward this will change a decent amount. Even more so once we start getting some more feedback.
Be sure to subscribe if you haven’t already! More updates are coming soon (and regularly)!
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.
Considering the humble beginnings of Minecraft, it is no surprise that it does not have mod support. Not to mention who ever knew that there was a desire for it. Without any official mod support, mods for Minecraft have been hacked into the game and eventually communities built up around modding the game. These communities have done their best to build their own mod API but without official support they can only go so far. The community has been begging for some official support for sometime. This is why, when Notch announced plans for the upcoming Minecraft mod API nearly a year ago, the community rejoiced.
Having official mod support for Minecraft will undoubtedly be huge for the community. This will help bring the mod community together. Another huge benefit is that it will enable players to more easily obtain and install mods. Additionally, there will likely be much higher quality mods developed. This is probably only scratching the surface on what benefits we’ll see from an official mod API. However, some of the given information does potentially have some downsides – mainly accessibility.
In order to gain access to this mod API you must signup as a mod developer. It also sounds like mods will go through some submitting process and once accepted will become available to everyone online. If this is the case then there is little place for casual mods. I do hope that Mojang has considered this and provide means for players to easily and casually create mods as well as be able to share with just friends or the entire community.
Since the mod API announcement, Notch has given lead to Jens Bergensten who is continuing to focus efforts on developing this mod API. More recently Mojang absorbed Bukkit, a Minecraft mod team, to help with the mod API. This really shows Mojang’s continued committed to this mod API – not to mention how much this team will help bridge between development and the community.
Back when Bergensten took over Minecraft lead, he had an interview with Gamasutra and from it there is a quote of resounding truth.
“there is no way in hell I will be able to add as much content as the whole internet can” – Jens Bergensten
This quote has stuck with me since I read it and undoubtedly helped set the course for our recently announced sandbox game.
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.
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
siegegames.wordpress.com 