Author Archives: jmcmorris

Seeking Developer

This position has been filled! Thanks again to all that applied.

After much internal debate, I have decided to look for an additional team member. This is a programmer/designer position for Crea and would preferably be long term (4+ months). Here are some details.

Requirements

  • Advanced scripting knowledge
  • Game design sense
  • Available to work for 20+ hours a week for the next few months (at least)
  • (major plus) Familiar with Python and/or C++

Duties

  • Implement content using the modding API (Python)
  • Design content such as items, monsters, biomes and so on
  • Help write modding tutorials and documentation
  • If you know C++ then you can help with the game engine as well.

Compensation

  • Upfront payment and/or profit sharing (To be negotiated)

Location

  • San Francisco area but remote work is fine.

If you are interested or have any questions, then please contact me at [email protected]. Be sure to include details about yourself and any projects you have worked on.

NOTE: The roadmap I posted yesterday was made under the assumption that I do not find another developer.

Updated Roadmap

It has been awhile since I posted an update regarding our release schedule. I want to thank everyone for their patience. Here is what we have planned.

Beta Phase 1 (Early Beta)

  • Time Frame: Early April
  • Duration: 4-6 weeks
  • Availability: Only $50+ Kickstarter Backers
  • Features: Windows/Mac/Linux support, Multiplayer, Leveling, Skills, Combat, Crafting, Generated Worlds, Character Customization, Day/Night Cycle

Beta Phase 2

  • Time Frame: Mid May
  • Duration: 4-6 weeks
  • Availability: $25 Kickstarter Backers. Publicly available for $25. (contains game, digital soundtrack, and digital artbook.)
  • Additions: NPCs, Researching, Grafting and additional Biomes, Monsters, Equipment, Items, Skills, etc.

Beta Phase 3

  • Time Frame: Late June
  • Duration: 4-8 weeks
  • Availability: $10+ Kickstarter Backers. Publicly available for $10. (game only)
  • Additions: Official Mod Support, Bosses and more content.

Release

  • Time Frame: August
  • Availability: Can be purchased by anyone for $15.
  • Additions: Quests, Mounts, Second Playable Race and more.

Some things to note

  • Any of this is subject to change but I have waited to post it until I was reasonably certain on the time frames.
  • Updates between releases will be posted on a weekly basis
  • Beta Phase 3 marks the official mod support. At this point I will do my best to provide all details regarding mod changes, provide mod API documentation and additional features such as in-game mod management. Before this it is still very possible to mod Crea.

EDIT: I have updated the original estimates to better reflect our current status.

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.

Malware Vanquished

Unbeknownst to me, this website was suffering from a malware infection. It was causing a few issues but the most noticeable one was mobile devices were being redirected to sketchy sites.

After receiving a second report of this redirection this morning I began to dig into the cause and am now pleased to say that I have cleaned up the site and upped the security. Please let me know if you see anything sketchy in the future though – it would be much appreciated!

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)