Red Button Bulletin 8: Release Schedule

To those who know me personally, much of the following information is review. For those who don't, hopefully this will explain quite a bit.

Hello - I'm Daniel Frandsen, the President / Founder / Lead Programmer for Red Button Games. Usually when I speak as the company, I use generic pronouns like "we," but since this post is more personal I'll be talking as myself.

The Past

Mage Tower has had a sporatic update cycle. I apologize upfront about not communicating what was going on, especially when it's part of my responsibility to keep company followers up-to-date. When Mage Tower began development (May 2012), I jumped in as a full-time developer. I planned on slowly ramping up other involvement through a part-time developer and artist, making a monthly update cycle reasonable. Since then, the other involved parties dropped off (through no one's fault), and I was contacted with a once-in-a-lifetime job opportunity (August 2012). The interview process took a while, but I ended up accepting an offer (November 2012) shortly before launching Mage Tower on Desura (December 2012) and another update (January 2012).

Throughout the next 7 months, I moved across the country, sold my house, started a new job, and got married. My update schedule for Mage Tower dropped from then full-time to now just a sliver of the time I wanted to commit to it. Communication dissipated, and I became somewhat nervous to check Desura to see what new dissenting comment I would see. Finally, a new update released (August 2013), and I was happy to see people still interested and to see people who seemed to understand (on some level) what I might be going through.

The Future

Now that things are more settled, I have a bit more time to work on updates. However, I'm not going to depend on my time for the release schedule as much as I can help it. To help with that, I'll be working on making updates even smaller, making them more feasible to be on a regular schedule. Second, I'm hoping to bring on more people who would be interested in the project. I'm a bit...picky about who I work with, but it's become clear that giving more of my own time wouldn't make a reliable schedule.

I hope that helps explain my perspective and why things might be moving slower than you'd like. Trust me, I want to play the "full" game of Mage Tower just as much as you - it's just going to take a bit of time. :)

Red Button Bulletin 7: Mage Tower Q&A

It's been a while, but the bulletin has returned with a very specific purpose. Since Mage Tower has been available on Desura, we've gotten a lot of questions about Mage Tower and its development. At first, we responded to each individual question, but today we've consolidated these questions into one article (since many of the questions have a similar theme. The full text of each question can be seen at the bottom. Here we go! 

Q: Where is the community? (from elunir)

A: We're a small team (more on this later), which means we wear a lot of hats, and every minute of time we have is precious. We've been debating about what the best avenue is to build the community. A forum is ideal, but requires a bit of overhead - even if that overhead is just checking and responding to the forum daily. We'll probably get there eventually, but we're not sure if it makes sense for our small team, or to have the more "traditional" conversation through comments and news posts.

Q: Why is the development so slow? I want this game!! (from Kindlesmith, leandro213, ds39uuca, UndefinedM)

A: Our team is currently one programmer and one artist. The programmer is working full time, but the artist is working on assets in his spare time. Even with this small team, we've made some decisions to get features built faster, such as buying in-game assets rather than producing them ourselves. These assets are intended to be replaced eventually, but until we reach that point, we have placeholder assets that don't look horrible.

We plan to bring on more team members, but we want to make sure those team members are the right fit. We don't have any substantial capital for hiring, which means until our income becomes stable, we're looking for people who are both skilled and will work for experience or for equity in the company. That combination of requirements makes potential team members a rare commodity.

Q: How will Mage Tower differentiate itself from Dwarf Fortress, Towns, Gnomoria, A Game of Dwarves, etc? (from Janppa, stuntaneous, yhann, and many others)

A: Before I dive into the meat of the question, I want to mention our development process. Rather than having a specific vision for what we're building say, 4 months from now, we focus on the next patch, the next feature, the next update, and build pieces at a time. This helps us in many ways, like preventing crunch time, reacting to gamer's opinions, and being very agile in our strategy. In the software development world, this philosophy is called Agile software development. So, although I have some ideas about what Mage Tower will become, I'm not so attached to any one idea that I can't cut it.

However, I understand that as a player, you want to know what this game will become! Aside from what it already represents (a cleaner, more modern interface for DF-style games), the biggest thing we're shooting for is a larger world view. At its heart, Mage Tower is still a management game, and management games are usually rooted at a specific place, with specific boundaries. Although we're not planning to allow complete freedom on where to build, we're hoping to build a world that can continually expand as you explore. You might find a town 10 minutes walking east of your tower, conquer it, and build another tower as an outpost in its place. You might later find a competing tower of mages further off in the distance, and begin to plan how to defend or overthrow them. Basically, we're hoping to build a larger world to give context to each tower, but restrict certain interactions to only happen in certain areas (such as building and combat). It's a sneaky way to avoid some technical complications with allowing building anywhere, while still expanding the world.

The next biggest differentiator is factions in the world. In many games in the DF-style, you can gain favor or make enemies with different factions, but you don't always see these factions outside of your base. Since the world is explorable and expands, you'll have exact context of where factions are, where they might be expanding, and make decisions around those factions. Looking at the town-conquering example above, you may have conquered the town before realizing that further east of the town lies a castle, which sent in knights to reclaim the town after your actions. Since you choose how to interact with these factions, you can befriend or anger these factions as you see fit. You can ally yourself with the villagers to ward off the dragon, or team up with the dragon to burn the landscape.

The last differentiator I'll mention is the theme. Although many DF games have some level of magic involved, the focus in Mage Tower is to build the mechanics directly off of "knowledge" and magic. As mages gain levels in different knowledge, new activities become available, and in some cases, new features appear in the game. In addition to magic, the work ethic of mages (compared to dwarves) is pretty...lazy. Why lift a finger if you can just make something float? Those theme decisions are driving a lot of our design decisions, which should create a different "feel" to the game than normal.

I'm sure we'll touch on this topic in the future as we build more of the game, but hopefully that gives you a better idea for what our roadmap is.

Q: Why don't you just ask to use the "Game of Dwarves" engine? / Don't use that engine, it's not that good! (from: mjgajda / neronix17 )

A: Game of Dwarves was announced around the same time we finished the prototype for Mage Tower. We were watching it closely and nervously as it was released, knowing that if it was successful, it would cut into our niche. Unfortunately for players (and fortunately for us), it looks like Game of Dwarves could use some improvements. From my brief experience with it, it seemed like the team was very comfortable with 2D, but it didn't transition well into 3D.

Our prototype, however, focused on the interface first, knowing that the interface was critical to how the game would feel. This is probably partially responsible for why there aren't as many features in the game - we focused a lot of energy towards polishing the user experience. We looked at Game of Dwarves and realized "we don't want to make their mistake" and are taking much care to tweak the interface to an optimal level.

Also, Paradox is awesome, and I hope that Game of Dwarves doesn't make them shy away from the genre, since they seem like a great fit for that type of game.

Q: Is there a Linux version coming? (from: d10sfan [twice!] and sheldonh)

A: The first time this question was asked, Unity 4 was just released, and we hadn't upgraded yet. Now that 0.1.3 is out and we've upgraded to Unity 4, we really don't have any obstacles left. However, the release of 0.1.3 was already dragging enough, so we decided to release 0.1.3 without Linux, test the Linux version, and release that with the next Mage Tower update. Linux was the primary reason for updating to Unity 4 so soon, so it'll be in the next patch/update.

Thanks for all your questions! If you have any more questions, please use our feedback form or comment on Mage Tower on Desura. If you haven't already, follow us on Facebook and Twitter to stay up-to-date on our latest news.

You can also buy or download the demo of Mage Tower on Desura:

Full questions (taken from Desura):

Community

• elunir: You should really talk more to the Community when upddates etc. will come out. In the moment it looks like there is NO talking to the Community. Especially i couldnt find a forum to inform myself. Many other Indiedevelopers inform a lot more about their games.

Slow Development

• Kindlesmith: gah, all this waiting for people to make their games at a near complete stage is taking forever XD I'm keeping tabs on over 20 different games, bored as all heck. It really isn't fair when games in development sound better than what is already released. Hurry up would ya! XD ;) My life span isn't long enough to try out everything!
• leandro213: This would need to be 75% off before I would even consider it.
• ds39uuca: i as many I hope track this. It sounds interesting, but not paying for till its a bit better. Keep up the work, and one day, mayve when its playable and good, you will get customers. OOOOh that was mean, sry
• UndefinedM: after trying the demo i can say there is potential, but we'll have to wait a long time before it'll be really playable..and 6 and an half € is really too much for what the game offers at this stage (ie, next to nothing)

DF differentiator

• Janppa: The game sounds really interesting and I can see a lot of potential in it! I'm just wondering what are some of the key features when the game is finished. What makes it different from Dwarf Fortress and Towns and all those other games like this? But yeah, definitely tracking this. I'll see what the next few patches brings us before deciding if I should buy this.
• stuntaneous: The aesthetic alludes to potential. What are you aiming to make of the game? How will it differentiate itself from Dwarf Fortress?
• yhann: I love what i have played so far. But need a lot of work to become truely interesting, i give it a 10/10 for the idea , i will change in final version depending of the upcoming features.
• There are also gnomoria and Towns on desura, maybe you should go in a different way of those because of that you cannot do everything as DF, too complexe I think, you may choose your path, to say. Good luck RBG guys !

Game of Dwarves

• mjgajda: Why don't you try to contact Paradox whether you can reuse engine of their "A Game of Dwarves"? Then you could concentrate on making the gameplay content, and engine improvements instead of engine.
• neronix17: That engine was terrible and so was the game, I generally like games from Paradox but that one was like it was in a box for 10 years after they developed it before releasing it. This game on the other hand already looks and feels better than A Game of Dwarves.

Linux

• d10sfan: with upgrading to unity 4, are you going to be releasing linux builds?
• sheldonh: WIll you be leveraging Unity's Linux support for release to that platform?
• d10sfan: looking promising by the way, you planning on a linux version of the game?

Red Button Bulletin 6 - THE WHITE BOARD ROOM.

It's been a couple weeks since our last bulletin. So to make up for that, we'll have pictures for the first time!

Recently the "company office" underwent a major revision, making it much more enjoyable to work in and usable.  Unfortunately, we really only have "after" pictures, but there's still plenty to see.  Here's a breakdown of what we did:

• We replaced the old wall-attached desk with a new T-shaped desk.  It lets 2 people work at once, but the new desk at least doubled usable desktop space.
• By removing the old desk, we moved the file cabinet from underneath to be able to put two full desktop towers underneath.
• We ran a network cable to a switch underneath the desk, rather than using the previous wireless bridge.
• And, arguably the most interesting, we covered every vertical surface possible in white board paint.

 Now, we have a great place to collaborate, visualize our ideas, and well...doodle!

  

This is a view of the desk, set up with two workstations, the main one on the left with 3 monitors.  Any vertical white surface you see is now white board - most of which have something written on them already.

   

The wall facing our backs has the biggest usable space, and that's where a lot fo the brainstorming tends to happen.  You can see some state diagrams, UI prototyping, and a few other random doodles.

Doodles can come from anything - even some brilliant WIP terms like "super stone."

We also put a cat door between the office and utility room - to keep the noise and smell out of the main room.

Here are the two desktops and a switch, out of the way and safely under the desk.

And of course, there are doodles all over from visiting friends. 

This is an awesome Christmas gift from a friend of the company.  Seems awful familiar...

One thing that you'll have to understand is that I'm a bit obsessed with BrodyQuest.  I'm fully aware of how ridiculous it is, but IT'S SO AWESOME.  It's also the first thing I soundcheck with whenever I set up audio equipment.  My wonderful fiance decided to surprise me by creating the full progress of BrodyQuest on the overhang in the office, complete with cutouts for Brody, his guitar, and the friends he picks up along the way.

       

Above is almost the entire drawing of OfficeQuest.

And there you have it!  A ton of pictures of where we work, with some details about Codename: Jenga snuck in there.

Thanks for reading!  If you have any comments or questions, or have suggestions for topics for future Red Button Bulletins, contact us either on Facebook, Twitter, or email (info [at] redbuttongames [dot] com). Follow us on Twitter and Facebook as well!

Red Button Bulletin 5 - Life-work balance

This week's topic isn't technical at all.  It also won't be nearly as in-depth, but it's personal - it's just a few thoughts around the idea of life-work balance, a.k.a. making sure you don't become a workaholic.  It's a term I've heard thrown around in IT and software development a lot, but in game development it's usually called quality of life.  Because both of these worlds approach the problem in different ways, I'll approach what the term means in both of these fields, my struggle with it, and what I'm trying to do to fix it.

Life-work balance in IT

The typical job in IT / application development expects 40 hours week, with some overtime.  Depending on what role you serve in the company, this could mean pushing operating system updates, deploying a new version of an application, or crunching to meet a deadline.  Even though there is some "crunch time" in the way game developers use the term, the typical issue IT/developers tend to run into is constant availability.  A given work week might only consist of 40-50 hours of work, but some of those hours tend to be during inconvient times.

Quality of life in game development

The typical job in game development has a similar baseline for hours (40 hours / week), but it tends to ramp up much more during crunch time - typically running 60+ hours / week for weeks to months at a time.  Although there isn't as much "emergency time" needed as a job in typical IT, the sheer commitment of time is much higher.

My story

I've been lucky enough that neither of these issues really define my balance in my career.  It's rare when I work more than 40 hours a week at my main job, and when I do it's only to make up for hours lost the week before.  As far as work goes, it's been balanced pretty well.  However, I tend to take on commitments to fill up whatever time I have left.  Only a couple months ago, in addition to working full-time as a Business Intelligence Consultant, I was doing contract programming work, starting Red Button Games as an official business, and doing a ton of programming and planning work for a charity gaming group I help run and participate in (72 hours remain).  My biggest long-standing issue in life-work balance is over-commitment and spreading myself too thin.

The Future

All these points in mind, I realized that since I was starting a company, I can make whatever goals I want.  It's really tempting to put all my time towards the game (since I'm so passionate about it), but I realized I really need to focus on avoiding the three major pitfalls: costant availability, commitment of time, and over-commitment.  I hate the American system of only having 2 standard vacation weeks, so why not have 4?  I love the idea of taking an afternoon to just play something, so why not?  And most importantly, by going full-time working on the game (instead of working on it part-time AFTER a full-time job) I free up a lot of the stress and over-commitment I've dealt with my whole life.  I'm getting married, have a house to maintain, and have a beautiful summer to enjoy - not sitting in a codecave my whole life.

~Daniel Frandsen, President of Red Button Games

PS: Make sure follow us either on Facebook, Twitter.  You can also contact us via email: (info [at] redbuttongames [dot] com).

Red Button Bulletin 4 - Architecture Algorithm

Another technical article this week - this time digging into one of our active pieces of development.  Most likely, the algorithm will change sometime after this post, but it's what we've been doing the most heavy development on lately.  It will be one of the key systems that will provide the "fun" in the first Milestone for Codename: Jenga, but for now the actual algorithm is a little dry.

Problem

In Codename: Jenga, players will be building a structure, a "tower" of sorts.  We wanted the tower to have realistic physics, but we also wanted to allow some fantastical structures.  The universe in which the game is built needs that hybrid, straddling reality and fantasy.  So we needed a way to calculate how much "realistic stress" is being put on the building as a whole.  The "world" is a 3D grid - so each block has 4 neighbors adjacent to it, plus a block above and below.  The algorithm discussed below accomplishes that.

Terminology

A couple terms for those learning or need a quick reminder:

Set - A collection of objects.  The only use this collection has is to determine whether an object exists in the set.  There is no way to get a list of objects in the set, to iterate through the object, or to order it - but it's VERY quick to determine if an object exists.

Queue - A FIFO (First-in, First-out) collection of objects.  When getting the next object from the queue, it gets the object that was there the longest.  Think of it as a line at the coffee shop - the first person in the line is the first to get their order.

Block - A grid element in Codename: Jenga.  Not every object is literally a "block", but logically that's what they're called.

Leaf - An object in a tree or graph with no children.  In this case, it means that it's a block that we'll start calculating from.

Algorithm

The first step of the algorithm was to develop a method to "calculate everything" and would deterministically come up with the same output.  The general design of the algorithm was to start at the ground floor and iterate generation by generation until no more connecting blocks could be found.  As each block was added, if it caused additional stress it would add the stress to the total.  The first iteration of the design used the following steps:

• Add all ground level blocks to [SearchSet] and [SearchQueue]
• {A} Get next block [CurBlock] from [SearchQueue]
• Check neighbors of [CurBlock]
  • If neighbor is a generation earlier than [CurBlock], it can supply support to [CurBlock]
  • If neighbor isn't in [SearchSet], then add it to [SearchQueue] and [SearchSet]
• Add up the support of all neighbors, record the end stress and generation of [CurBlock]
• If blocks still remain in [SearchQueue], loop back to {A}

This is a simplified breakdown - but you get the idea.  It iterates over the 3D grid of blocks, sets the stress level and generation, and moves to the next block.

Metadata

Each block contains pieces of metadata - the weight generation, weight value, weight support, and external support.

Weight Generation - A number that represents how far away the block is from the "root," or in this case, the ground floor.  This is helpful in determining which blocks support other blocks.

Weight Value - The amount of weight stress the block puts on the structure as a whole.  A floor for example, has a value of 0.1, while a solid block has a value of 1.

Weight Support - The amount of support the block provides to blocks above it.  A floor's support value is 0, while a solid block has a value of 1.

External Support - The support that a block receives from the blocks below and around it.  The more external support a block has, the less stress it puts on the structure.

The final stress value for a block is calculated once external support is calculated:  [External Stress] = [Weight Value] * (1 - [External Support]).  External support is additive - so if a block is supported by multiple sources, the block is very stable.

Iterative!

But wait a minute...the algorithm above recalculates everything from scratch.  We don't want to recalculate the entire tower if we only added or removed one block, that'd be really expensive!  So we needed to refine the algorithm for how it's going to be used 90% of the time - recalculating local changes and figuring out how it affects the whole.  This ends up being really complicated, since there a lot of things to consider, but the key to local calculations was the Weight Generation data.  Using the data stored in each block, it's very easy to start at one block and find the set of affected blocks.  The general rule is: if this changed block has a generation smaller than its neighbor, add the neighbor to the recalculation set.  This rule is iterated until no more blocks are found that match the rule, and a variation of the above algorithm is applied to that set of blocks.

Once the set of recalculation blocks has been created, you find the leaf blocks with the smallest generation, and start the calculation there.  There is some additional filtering to prevent the recalculation from going outside the set, but the logic is essentially the same - recalculate support, determine possible support based on Weight Generation.

Destruction

Just when I thought everything was resolved, I started trying to remove blocks.  This got tricky because much of the algorithm depended on the "starting block," which was usually the block that changed.  However, when removing a block, there's no longer a seed to start the process!  This involved even more sets to track various coordinates - the removed block set, the recalculation set, and the leaf set.  We're still debugging this algorithm, and the logic is a bit too complicated for me to wrap my head around without examples or visual aids.  Trust me though - things get tricky.

But What About the Fun? 

This algorithm alone doesn't do much, but it does give us a lot of data we can use for cool effects.  In Codename: Jenga, you'll have a power source to support the structure.  If your power source is a higher value than the stress on the structure, then your structure is fine.  But if the stress ever surpasses the power source...well, things are going to fall apart.  And that's the biggest hook we'll have in our first alpha/pre-beta release - the structure creation and destruction.  We think it's a really cool concept that hasn't been done very well (if at all?) before, and it's part of the foundation for the world we're building.

Thanks for reading!  If you have any comments or questions, or have suggestions for topics for future Red Button Bulletins, contact us either on Facebook, Twitter, or email (info [at] redbuttongames [dot] com).  Follow us on Twitter and Facebook as well!