Author Archives: jmcmorris

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.

Upcoming Minecraft Mod API

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.

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

Quick Development Update

Since the release of the flash prototype, I have been working hard at getting a game engine up and running in C++. I wont go into much details about how this engine works, but I will say that it is seeing some great progress thanks to some open source projects such as SFML and box2d. Here is a small video preview of what the engine is capable of so far. In it you will see some boxes being created and interacting with each other. Yay! Physics!

Before too long I will have some gameplay to show off, but there is still a long ways to go for a playable game.

http://screenr.com/qY4s

Prototype Shipped

The prototype for Crazy Old Me has been published to two flash game sites, Newgrounds and Kongregate. Yay!

The prototype is getting reasonable ratings and reviews. The general consensus is that the core mechanic is good but the execution could have been better. This is good news considering that the focus of the prototype was on the core mechanic, phase shifting, and only mild effort was put into the other fronts.

Now that I have confirmed my suspicions that phase shifting has potential, it is time to stretch the core mechanics and expand on them as well. I will divulge some information once we have narrowed down what we want to do.

A New Challenger Appears

Immediately after putting Crea on hold, I began to look at what my next game project would be. I was not looking for a rebound relationship. I knew that it had to be absolutely feasible. So I began to brainstorm with my brother Aaron and my wife Kelley.

We came up with a few different ideas but I was uncertain about the feasibility. Eventually we came up with something that we liked and was achievable in a 9~ month timeframe. Over the past month we have been working on a flash prototype to get a feel for what the game and development would be like. The flash game is nearly done with only a week left of bake time before putting it only some major flash sites such as Newgrounds and Kongragate.

The working title of this new game is Crazy Old Me. It is about Felix, a young scientist, and Pickles, his pet cat. One day Felix is going about his normal life when he is abducted by his future self, who infuses Felix with ME (Me Enhancing) technology in order to complete a deranged quest. Felix is forced to go through insanely intensive training in order to prepare for a future event in which Pickles is stuck in a tree.

The gameplay in Crazy Old Me is a traditional 2D platformer at heart with some serious modifications. Several of these modifications are inspired by games such as Super Meat Boy, VVVVVV and I Wanna Be The Guy. If you know anything about these games then you know that this roughly translates to DEATH. Lots of death! Death every few seconds. Death from lava, death from heat-seeking missiles, death from pointy things. In other words, the game will be made up of many small levels that range from moderately challenging to insanely challenging. Only those with quick reflexes, good muscle memory, and determination will be able to make it through the most challenging levels.

In order to achieve unique gameplay a new concept to the genre was mixed in – phase shifting. There are two different ‘phases’ that the player can go between. Objects typically exist in only one phase or the other, which means the player must phase shift in order to avoid objects and much more. Have no doubt that we will be having fun with this concept.

I will be providing more information next week with the release of the prototype. Check back here then. Oh and here is the title screen for the prototype that Kelley did.

Three Common Pitfalls To Avoid In Indie Game Development

When standing at the threshold of a new project, humans tend to be overly optimistic and at least have best intentions for the project. Perhaps this is done to help rationalize our projected time investment into the project. Whatever the reasoning, I am particularly prone to this condition. When beginning my previous project, Crea, I was certain I would finish it and its beauty would cause the entire world to weep and cause the sea level to rise. Fastforward two years and it is clear there were several mistakes made that lead to the project being put on hold. I want to share some of these mistakes in hopes that others can learn from them – or at least I can.

Feasible Design

Ideas only have value if they are feasible. If it’s impossible to execute an idea given the resources available, then it is worthless. I’m talking about the resources you absolutely have - not promised or hope to have. It is all too easy to think “I can find people online.” or “My friends said that they’d help.” to help rationalize the scope of a large project.

Crea was designed to provide both story (PvE) and competitive (PvP) modes along with hundreds of cards and dozens of quests. This is a feasible project right? It is if you have the resources and I had convinced myself that I did. The project started with three people and grew to 6 people over the course of a few months. Life quickly began to pull team members in different directions, which left me with a large project and limited resources. Instead of calling the project a loss, I counted my chickens before they hatched. I convinced myself if I just get enough of the project done then people will see its potential and want to help. However, I gradually realized that to develop a project of this size on my own, a massive amount of work would required over a span of several years. This was undoubtedly the largest issue for Crea.

Moving forward, while coming up with a new game project my primary focus will be to ensure that the very basic design is feasible with the resources I currently have. I will try to be more realistic for project timelines and time pouring will be limited to something reasonable. I will not count new team members as a reliable resource until proven otherwise.

Defined Scope

The only way to determine a project’s feasibility is to have a well-defined scope. A carefully thought-out project design can fight against the deadly disease known as scope creep. Scope creep is where new features are added after the initial design without adding new resources – a temptress that has seduced many game projects and led them down a path of destruction.

In addition to Crea not being a feasible design, it was not well-defined upfront as well. The very core gameplay was detailed but gameplay systems were left to be sketched out. This vagueness left the project wide open to scope creep. We added a dozen cool “features”, such as character classes, card levels, card fusing, and the list goes on. Countless hours were spending pondering these features and implementing them. We were so excited about all these new ideas that we lost track of the big picture. The result: a bloated, needlessly complicated game design.

Eventually, during a cleansing period, I trimmed over a great deal of this extra fat, but the damage had already been done. The large scope had scared off many and left the few remaining reasonably discouraged considering so much progress lost. I imagine that the course of this project would have been severely different if we had taken the time to detail out all of the features and the scope of the game’s content – perhaps it would have not even made it past design.

All of my future projects will always have all aspects detailed out in a design document before any development begins, this includes features and content. I have found that prototyping a project gives an invaluable insight into the true scope of the project with minimal commitment. A prototype also is a great time to play around with the design to help minimize the changes needed in the future. Initially, nothing is set in stone since it is impossible to get things perfect on paper; however, I will be cautious any changes particularly further into development. Whenever changes are made it is vital to keep the project’s scope in mind to avoid losing control.

Cautions About Free Help

People are cautious of how they spend their free time – particularly when giving it away. When dealing with game projects, if the project is not benefiting someone then that person is unlikely to stick around and I don’t blame them. Even if the person genuinely wants to help or is getting something out of the project, legitimate reasons come up that may require the person to reassess his time commitments. Life happens and it happens unpredictably. It can be a real challenge when trying to determine if you can truly rely on someone when the going gets tough.

Throughout the entire lifetime of Crea, I was depending on free help from both friends and people from online forums. Most of my online contacts who promised to help, never did, or would help for a week then disappear without warning. The few team members who did stick around for a few months eventually either became too busy to work on Crea or just lost interest. I believe that the daunting size of the project was what scared most off. In retrospect, it was completely unreasonable to expect others to invest years of their time into a project.

I have learned that if you’re asking for someone’s free time then don’t ask for too much. Keep the project short with continual returns on the person’s investments, even something as simple as tangible progress can be acceptable. When searching for that perfect someone, look for someone that is as passionate about the project as you are. If all else fails, I have found that money is very good at convincing people to stick around.

Conclusion

I by no means want to discourage large projects and do not think people should not take risks. I have read about several successful indie games that faced some rough times, such as Magicka and Super Meat Boy. I am certain that serious doubts filled the developers minds at some point, but yet they persevered and found success. This post is about minimizing project failure. After all, the number one defining characteristic of successful video games is that they’re finished.

Facing the Truth

I have been hiding from the truth for a long time now. I thought that if I could just close my eyes long enough that it would go away. Two months ago I finally opened my eyes once again and now that they have dialated I can see that the truth is still staring at me.

The truth is that Crea is too ambitious for where I am at. I was asking too much from my team, which was likely the cause for chasing away some members. I was asking too much from myself. I have decided to put Crea to the side for now. This is very difficult for me to admit, because I have put literally more than a thousand hours into this game over two years.

I do not completely regret working on Crea. I learned a great deal about game development from nearly every perspective. I believe that moving forward I will be able to avoid pitfalls that I discovered during Crea’s development and consequently create a better game than I could have before.

One day I hope that I am able to pick Crea back up and finish it. However, for that to happen, the project will have to truly be feasible given the resources that I have at the time and not what I hope to have in the future.

Creating unique and quality games is still my passion, and I already have some new game ideas that I am playing around with. I am not certain what my new project will be, but no matter what, I know that it must be feasible for a very small team (my wife and I, basically) to finish within a 6 month time period.

In my next post I will list what I learned from the failure of the Crea project and how I’m using that knowledge to shape my ideas for future games.

Valiant Return

Over the past month I have given myself a semi-vacation from Crea. It was needed after working on Crea nonstop for about a year. I am ready to get back into the fight.

I did not completely halt development. I did make some vital progress and just now was able to step through an entire round in a match. I was at this before minus being able to use cards. Next few items on the list are all about making the game actually playable (i.e. giving the player feedback).

More posts should be coming before too long!