Tag Archives: indie game

Open Development

Little kids look up to firefighters, police officers, and astronauts and make one their role model. Similarly, I am a little indie kid and I look up to Wolfire as my role model. They are working on Overgrowth and started the bundle movement with Humble Indie Bundle (HIB).

Even though both of those are amazing, that is not why I look up to them. I have been following Wolfire for a few years now, well before HIB, and something that always stood out to me is just how open they are with their development process. They have weekly alpha video updates providing an overview of the progress made that week. Along with that they less frequently do art asset overviews. Occasionally they will make a blog posts about game tech. They even have livestreams for some of the members - David and Aubrey. Lots of great stuff and very inspirational to me.

When I started Crea I decided I wanted to apply this inspiration. When I come across a new opportunity to share I welcome it with open arms. When I decided to start a pivotal tracker to do project planning on; I made it public. I now do coding livestreams on nearly a daily basis. I like to think I am very open with my development. The other day I was reminded of my inspiration’s source after watching a reasonably old video with two guys from Wolfire doing a talk on Open Development.

I’m aspired not only to continue my growth as an indie in the same direction as Wolfire, but also to help improve, expand, and explore open development.

The Quest For Dual Wielding

We have wanted some form of dual wielding since the inception of Crea. The motivation behind this was simple. First and foremost, we wanted the player to be able to use multiple items without changing their active item on the toolbar. We also wanted the toolbar to provide access to more items. We knew what we wanted but how do we get there?

When I think dual wielding I think left click for one item and right click for the other. I think this is how most games do it. There are games that have single click to use both weapons but we need to provide means to individually use the items. This creates some new questions though. Item interaction was right click but what is it now? How do we display which items are assigned to the toolbar?

We considered splitting the toolbar and having 1-5 be for left click and 6-0 be left click. Something else we tried was having items on the toolbar be left or right click. We tried having 20 items on the toolbar. There are many other paths we fumbled down. We commonly ran into two problems. The first was adding dual wielding with only 10 items on the toolbar seemed to add more complexity than it was worth. The other problem was if we wanted 20 items, two items per number, then how do we display the items efficiently? Every way we tried left at least one of us unsatisfied.

We ventured down several paths but none of them felt right. For awhile we even dropped dual wielding, but since we really wanted it we picked it back up. I had pigeonholed myself into thinking we needed dual wielding to happen with both left and right click. I stepped back from that and quickly stumbled upon a working solution.

toolbar

Current toolbar showing what both the primary and secondary looks like.

Instead of having a single toolbar the player has two toolbar, which we call the “primary” and “secondary”. The primary toolbar is active by default and to get access to the secondary toolbar simply hold down the shift key. There are 10 items on each toolbar with each item assigned to a number key. There is only one number slot active at a time. There is also only one active toolbar at a time. Since only one toolbar is active at a time the solution to our display problem was obvious. We would only display one toolbar at a time. Left click always uses the active item on the active toolbar.

Time for an example! Lets say “3″ is your active item on the primary toolbar. Left click and you use this item. Hold down shift key and now you see your active secondary toolbar. Left click again and you will use the “3″ item on your secondary toolbar.

It took awhile to get there but it was a worthwhile journey. The controls feel right and I think are intuitive. I am looking forward to getting some feedback about this feature from the testers.

Feature – Character Progression

Overview

Close to the start of the Kickstarter, I wrote a post on character progression. This was a great thumbnail sketch of what character progression will look like. I have taken the time to flesh things out and clean some things up that I found troublesome with the initial sketch. Now character progression can be broken into two distinct parts – character level and talents.

The character level is strictly used for combat related things. It is used to represent your character’s strength and consequently is utilized in various combat algorithms such as the damage algorithm or for determining the monster levels. Upon leveling your character will gain stats. Also equipment will typically have a character level requirement.

Characters have talents that represent the character’s proficiency in a field. Currently we have four talents planned; Arms, Magic, Gather, and Craft. By performing actions related to the talent your character will occasionally gain TP (Talent Points). For example by crafting items or learning new recipes you may gain TP for your Craft talent or hitting a monster with magic may yield TP for the Magic talent.

After accumulating enough TP your character’s talent will level up. With enough TP you can spend it on purchasing and upgrading skills. Leveling up a talent grants access to new skills and skill upgrades. There will be a mixture of active and passive skills. Active skills are skills that can be added to the toolbar and used as an action such as a magic spell. Passive skills are always affecting the player such as “Defense Up”.

Early version of Talent window

Modding

As usual, nearly all aspects of talents can be modified ranging from modifying an existing skill to creating an entirely new talent. Talents are tied to body types (covered in this post) meaning different races can have different talents.

As far as the actual modding goes, here is what the adding the talents to a character body looks like.

body.talents = Talents()
body.talents.talents.append(armsTalent)
body.talents.talents.append(craftTalent)
body.talents.talents.append(gatherTalent)
body.talents.talents.append(magicTalent)

A Talent is simple and is only composed of a name, a “points to next level” list, and a list of skills.

armsTalent = Talent("arms", [100] * 20)

Skills are a little bit more complex. First of all, skills can passive and/or active. A passive skill is always in effect while an active skill must be used. It is possible to have a skill with both elements. Passive skills need to provide two callback functions – “enable” and “disable”.  Active skills need to provide the callback function “use”. All skills should provide a “description” callback function.

def enableStatUp(stat, level, user):
    user.stats.get(stat).adjust(5 * level)

def disableStatUp(stat, level, user):
    user.stats.get(stat).adjust(-5 * level)

def descriptionStatUp(stat, level):
    return "Increases a character's {} by {}.".format(stat, 5 * level)

atkSkill = Skill(name="Attack Up", icon="mods/base/talent/arms/attack_up.png", costs=[100] * 5)
atkSkill.enable = partial("ATK", enableStatUp)
atkSkill.disable = partial("ATK", disableStatUp)
atkSkill.description = partial(descriptionStatUp, "Attack")
armsTalent.skills.append(atkSkill)

defSkill = Skill(name="Defense Up", icon="mods/base/talent/arms/defense_up.png", costs=[100] * 5)
defSkill.enable = partial("DEF", enableStatUp)
defSkill.disable = partial("DEF", disableStatUp)
defSkill.description = partial(descriptionStatUp, "Defense")
armsTalent.skills.append(defSkill)

The “enable” function is called when the skill is activated. This is when the player first get the skill or when the character is loaded. The sibling function, “disable” is used when the skill needs to be deactivated. This is typically when the character is being saved to disk but it also makes it possible to temporarily disable passive skills with monster abilities. The “description” function is called when we need to display the tooltip for the skill. Having it be a function makes it dynamic so it can be dependent on any variable – such as the level of the skill. The “use” function is not featured here but it is more or less the same as the previous functions. It is called when the skill is being used.

Creating skills and entirely new Talents is definitely some more advanced modding. However, with the complexity comes some awesome power and I am anxious to see what skills players come up with.

Feature – Dynamic Music

Charlie (Robot Science) and me (Jasson) working on Dynamuse

Overview

The music in Crea will be dynamically generated. This means you will never hear the exact same track twice. The music is broken down into small sound clips that I am calling “samples”. These samples are played dynamically based off of some parameters such as how much danger you’re in, time of day, and how long the track has been playing.

The thing that turned me onto doing dynamic music was watching Renaud Bédard’s GDC talk Cubes All The Way Down. I had not heard too much about dynamic music in games, but I knew that it would be a perfect fit for a sandbox game. It is so easy to get sucked in for hours and before too long the music becomes very very very repetitive. What do we do when this happens? Mute! I know that’s what I do and it is a shame since video game music is so great. My hopes are that by making the music dynamic it doesn’t get repetitive enough to warrant mutiny…

As I have mentioned before, I made a tool for Charlie that I dubbed “Dynamuse”. Dynamuse is used to define the rules for when samples should play in a track. I will admit that Dynamuse is a little on the complicated side but with that comes much power. I recently got Dynamuse more or less completed and soon we will be hearing its true power.

Version 2 of Dynamuse

Modding

Because I’m all about modding and being open, I’m going to make Dynamuse available to everyone. That means that anyone who wants to can modify existing tracks or even create their own. Eventually I will make a tutorial on how to use Dynamuse, but for now here’s a brief overview of how it works.

A Dynamuse track is composed of any number of samples. A sample has a name and music file associated with it and it also contains a list of triggers. A trigger contains a few things but most importantly it contains a list of conditions. There are several types of conditions such as time of day, status of another sample (playing, paused, or stopped). If a trigger has all of its conditions met then it signals the sample to play. And that is about it. Simple, right? (not quite unless you’re a programmer)

Functional Is Not Finished

Has anyone noticed how long Crea is taking? I know I have! Just a few months ago I was certain I would have Crea more or less finished by now and yet here we are still months away from a reasonable release date. “Why is this?” is something I have been asking myself recently. What is making things take so long?

I looked behind me to what I have been working on over the last few months and then ahead of me to what I will be working on and the answer became clear. There has been multiple factors that are causing these delays such as a feature taking longer to implement than expected or completely overlooking a feature when I made the release date estimates. However, without a doubt, the largest contributor is the mistake of confusing functional as finished.

When we launched Crea’s Kickstarter I truly tried to make pessimistic estimates on the release dates. I was secretly hopeful that the stars would align and Crea would come out even sooner. After all, I had the basic exploration working along with world generation, character creation, crafting, user interface, and many other things. That means I was done with these and only have to look forward to the remaining features, right? Note quite.

As it turns out, function is not finished. Many of these features only had the bare necessities implemented and were by no means ready for prime time. Take the world generation for example. Back in June it did create a randomly generated world but, as it turned out, it was very hard to build onto these generated worlds. Even more pressing, the generation would take 45 seconds for a small world and I was too scared to try a large world that is 8 times larger than the small. For some time I closed my eyes and marched on as if the problem would magically go away. It didn’t.

There are several other examples. The user interface was difficult to build onto and hardly moddable. The crafting was missing the concept of recipes the player would learn. The networking is too slow and probably needs to be moved from TCP to UDP, a major rewrite of the networking code. Add all of these up and you have a few months of added development.

This is not all bad news though. With every upgrade, Crea gets that much better. I want to ensure that Crea is representative of my best work. I do plan to release Crea before some minor features have been finished, but the features I do release with I want to be polished and ready to be built onto.

…So when is Crea coming out?

Tooltips and Japanese

Decided to work on tooltips and while I was at it I decided I would once again verify that Crea was indeed localization friendly.

Styling will likely change (such as font size). Also note that this was just a test. Crea has not been translated to Japanese.

Needless to say, I am quite excited about both of these. I was unsure of how to implement tooltips for a while now and decided to finally tackle it. Also I had not tested a foreign language on the new UI and so it was a pleasant surprise to just see everything work as expected.

And here is the English version for your viewing pleasures.

Mac Port Progress

Figured this was noteworthy – I got Crea running on mac now! It does have some graphical issues that I need to iron out but besides that things are running smoothly! And no, the toolbar is not having graphical issues – it looks bad (particularly the bag area) because I made it.

Anyways, this is huge news, mostly because it proves that what I have been developing is in fact portable. This also means that the linux port is not too far away, but it will still be awhile before I do get to the Linux port. Don’t worry though – Early Beta will have all 3 platforms!

Development Stride

The past month I have hit an amazing development stride on Crea. I am more focused than I have ever been and continue to make unbelievable progress. I am utterly obsessed. When Kelley takes me out on my daily walk I have a hard time not talking about Crea and an even harder time not thinking about it. If this is the price for raw productivity then I’ll take it!

During this stride I have tackled some major issues. One example, which I mentioned in my last blog post, I completely rewrote all of the user interface code. Since that post I have written all of the previously implemented game UI which includes the crafting, equipment, inventory and toolbar. While doing this I was sure to polish some features and move them much closer to “complete”. Such as I finally added the concept of learning item recipes to be able to craft them. Or I made it so that ctrl+click on equipment will automatically swap it with your currently equipped item.

Inventory close to being finished

Another major feat is that I rewrote the world generation. In an earlier post I talked about optimizing the world generation and how it was just too slow. I decided to completely get rid of the random noise and go with using stamps to build up a world. This was a HUGE success and generating a small world went from about 45~ seconds to now 3~ seconds. Even a humongous world, 16384×3072 tiles only takes about 15~ seconds to be generated. Not only is it much faster, but we also now have much more control over the shape of the world.

What the world generation output currently looks like

There are lots of other smaller changes that have been happening which are mostly cataloged in our project plan. On there you can also see some of the tasks I have coming up. The next two big ones are Dynamuse and Combat Refinement.

Dynamuse is a little application I’m putting together for Robot Science to be able to compose tracks that will be dynamically generated during gameplay based off of a few parameters such as the time of day and the intensity of the situation. The motivation behind this is to avoid extremely repetitive music that you inevitably mute.

Dynamuse Mockup – Be glad I’m not doing the UI

The Combat Refinement is a little more vague and I will likely do an entire post on the topic at some point. We have very basic combat implemented at the moment. You are able to swing a sword, very similar to Terraria’s long swords, and hit monsters. It is functional but not quite what we want. My goal for combat is to be a little more involved and skill based rather than “click-click-click-cli-cli-click”.

One of the biggest challenges with combat in a sandbox game is that the world can be reconstructed and, if we’re not careful, could easily mean some monsters are unable to even reach a player. So, some of the things we are looking at are: monster mobility, range attacks, multiple attack animations for a single type of weapon, skill and magic types. It is a lot but I have a good feeling we’ll be looking back at it before too long thankful that we took the time to refine things.

Oh and I’m still doing livestreams everyday. Feel free to drop in anytime!

From Good to Awesom-ium

This has been quite a week! We FINALLY released alpha to a handful of people and it has been well received. Just over the course of a few days over two dozen bugs were uncovered (some already known) and half of them fixed. Between the bug fixes I began looking into moving the UI (User Interface) over into python. Why? I wanted to make all of the UI completely moddable and make it easy to add in new UI through mods. I had attempted this before and had problems getting the library I was using to be exposed. That was when I found something very shiny – Awesomium.

Awesomium is a full fledged “web UI bridge for native applications.” In other words, it is Google Chrome inside Crea. This was not the first time I had looked at Awesomium. I had considered it before for a previous project but had foolishly decided against it.This time I was no fool.

I have made the jump and I’m not looking back. I have been making great progress over this last week. This has been one of my most focused weeks – ever. I completely tore out the previous UI which I fortunately had the foresight to decouple from the rest of my engine as much as possible. Then I implemented Awesomium and got a prototype working surprisingly quickly. From then on I have been working on re-implementing Crea’s UI such as the menus, inventory, crafting and so on.

What does this all mean?

  • Crea UI will be 100% moddable
  • UI visuals and interaction is implemented in HTML5/CSS3/Javascript
  • UI interfacing with game logic is implemented in Python
  • Crea’s UI will be Awesome

For those web devs reading this, we have decided to use JQuery, Ember and Handlebars for templating and data binding the UI. You can also point your browser to a port on your localhost and you get full access to Google Chrome Developer Tools for the UI in the game. How awesome is that?

Screenshots coming soon!

Oh! I almost forgot I am doing regular livestreams now! Click for more details.