I am overburdened, evolution of box-art

Hello there!

Took most of last week off for vacation == no entries, sorry about that, but this week I’m going to make multiple videos and blog posts 🙂 ! This first one is about the box-art of the game.

Backstory, requirements

For previous projects I did not spend too much energy on the promotional art. That was obviously a mistake, because usually it is the first thing both the players and the press comes across when checking your game, so it needs to have a good teaser, but it is easy to forget the importance of it and miss allocating time for it…

I planned to make a difference this time, but I significantly underestimated the needed efforts 😦 . I wanted to capture the plot of the game in an image, suggesting the core mechanic, which is trying to collect a lot of loot and having a huge inventory, but still not being enough. All in all I think I succeeded but it took two tries 🙂 .

First try

My first idea was to focus on the protagonist of the game, who is a tomb raider kind-a guy (the not so morally OK one). Not being a typical hero or warrior, I wanted to present him as a bit of a simpleton and not someone who would kill a bunch of monsters with a single slash, since you won’t be able to do that in the game either.

Concepting and direction

I started out with some concept sketches in my notebook, portraying a bandit/pirate figure carrying huge bags…

2017_03_21_concept_1

I continued with flashing out this character with a composition I thought I like:

2017_03_06_boxart_11

2017_03_06_boxart_21

I wanted to create a pixel art end result, because I dislike box-arts with totally disconnected style from the game (except if it is top-notch quality + it adds to the lore of the game) but from my experiences with Operation KREEP, I knew I’m going to need a s#!tload of image sizes for promotional art (especially true if you plan to sell the game on multiple storefronts). Steam alone requests 5+ marginally different aspect ratios. So I decided to go with vector art as a base, and fix various sized renders instead of manually doing 3 to 4 different setups pixel by pixel.

Inking, results and confession

I use Inkscape for vector art. It is a free and cross-platform vector graphics editor, and has a convenient user interface . Perfect for line-art, icons etc…

2017_03_21_inkscape

First batch of line-art and shading work was pretty promising, I grown to quite like the character…

2017_03_21_lineart_1

I tried out rendering the character in various sizes and fixing them up in GIMP using color reduction and manual pixel pushing. I still had “hope” at this point 😀 .

2017_03_21_lineart_2

Then I throw together a “placeholder” pixel art title text.

header

The only thing left, was composition, fine-tuning and polish, so putting together an actual art piece which I could use as the promotional material for the game. Here are my attempts:

2017_03_21_attempt_1

2017_03_21_attempt_2

2017_03_21_attempt_3

Of course I made close to a dozen of these, to try out various text sizes, backgrounds etc…

I don’t know if anyone likes them, but I sure felt like they simply aren’t working. I liked the character, I liked the colors, but the image was lacking detail, a good looking title-text, a correct composition and most importantly somehow it was lacking life 😐 . After days of fiddling on-and-off with it I decided, that no amount of polish is going the fix these problems, so I scraped it and started over!

Second try

I wanted to approach the next trial smarter. So instead of jumping in I looked at a lot of reference pictures and lay down much clearer goals and concepts before jumping into producing the picture.

Reference material

Looking at some images made for other games helped a lot! It made me realize, that I have to focus a lot more on the text first and foremost, and a more clever use of both color and space is required for the image as a whole.

2017_03_21_reference

I came up with the following concept afterwards which I really liked:

2017_03_21_concept_2

I followed a similar approach for scalability, using Inkscape to create the outline and work from the renders, manually pixeling the final image:

2017_03_21_lineart_3

Final, final, final, final!

Funny thing about the final image is, that it took much less time and effort than my first attempt and I think it turned out to be a good deal better looking 🙂 .

boxart_final_final_final_final

The takeaway is if you feel even a tiny bit stuck, sit back to the drawing board and spend some more time on your concepts, it will probably yield better results !

The upcoming entries will be about the linux and mac ports of my previous game Operation KREEP and the tile graphics of I am overburdened. Here is a little sneak-peek of the last one:

2017_03_21_screenshot_1

Stay tuned!

I am overburdened, nobody make a sound!

Hi everyone!

This post is going to be more like a tutorial, than a journal entry. I highly recommend checking out the video version, as it is heavily audio oriented + it contains some recent game-play footage 😉 .

I missed out creating an entry last week. I juggled between projects and tasks a lot, which led to me feeling a bit weary + no significant progress was visible on any front due to working just a tiny little on many aspects, so I decided to postpone it a little. Nevertheless, I’ve spent the last few days on finalizing the audio and sounding of I am overburdened.

Chip tune or not?!

My two completed games used pixel graphics and as a natural fit they were armed with 8-bit style sound effects. This is a really economical approach since making matching effects with a tool like sfxr takes only a few hours tops. From the get-go I wanted to try something different for I am overburdened, both for personal development and because some pixel games with realistic sounds (Canabalt) made me want to experiment with this style. I’m even less qualified as a sound engineer than as an artist 😀 so take my words with a grain of salt! All my mumblings here are based solely on tutorials scattered around the INTERNETZ + some fiddling with tools…

Recording

I decided to record and process as many effects of the game as I can. Last week almost a day was spent clowning with common household items to create noises 🙂 . If you are thinking about a similar approach, start by throwing together a DIY “recording studio” (sponge box). Even if you have a decent microphone it will help immensely with canceling noise and reverberation. Some sponge (check the boxes of your PC parts 😉 ) or a curtain can do the job. Otherwise you may end up with really echoing results (noise can be helped with software!).

2017_03_02_foam_11

2017_03_02_foam_21

Audacity to the rescue

First things first, download Audacity. It’s GIMP for sounds so to speak. Its interface is relatively straight forward (all what you would expect: select, copy, cut, paste, new track, the ‘z’ key ?! for clean cut selection etc…), but Youtube is filled with video tutorials (even with advanced tips and tricks) if you get stuck.

2017_03_02_audacity

The following is a good repertoire to familiarize yourself with from the “Effect” menu:

  • “Noise Removal”: for sampling noise profiles (noisy but otherwise silent segments of a track) and noise canceling.
  • “Change Speed/Tempo/Pitch” and “Bass and Treble”: for mixing and changing effects (e.g.: making them play slower/faster or higher/lower etc…).
  • “Echo” and “Reverb”: for making sounds feel more spatial, and for creating some fancy voice effects (e.g.: making yourself sound like a ghost, demon or a robot etc…).
  • “Fade-In/Out” for correctly starting and cutting off sounds, especially alongside cuts.

My approach, which helped me out learning the ins and outs of effects, is to change back sliders to default positions (0Db, 0% +/-0) and experiment a lot, gradually trying out various modifiers, to see how something affects a sound.

2017_03_02_effects_1

2017_03_02_effects_2

Here is a short reel of what I was able to record and mix for the game:

Public domain

For I am overburdened approximately 50% of the final audio were recorded (some stuff is just hard to record in your room 😦 ), the other half came from OpenGameArt.org and Freesound.org. Both of them are wonderful sites full of really good content, many even final production quality. After listening to an hour worth of sound effects I selected the best matching ones based on my list of requirements and remixed many of them using Audacity for even better results.

2017_03_02_opengameart

2017_03_02_freesound

One thing to be aware of before browsing around these sites is licensing. Keep in mind, just like code, various assets like pictures and sound effects can only be used under strict terms. Some only require author attribution, but some permit fully free modification or commercial use. If you don’t really want to dig into the topic, simply make sure you search for and use assets under CC0. This means the asset is essentially public domain, you can do what ever you want with it, even for commercial purposes!

2017_03_02_cc0

Runtime tricks

You should be applying effects runtime too, to make the sounding of your game more dynamic. I constantly need to remind myself of this practice, I tend to forget about it. Few simple examples are: dynamic pitch, panning and volume control. If a sound effect is played a lot (e.g.: footstep, attack, shoot, hit) and your API of choice allows to set the pitch value (e.g.: XNA SoundEffectInstance) throw in some minor, but random changes! This will make it feel more varying. If your API does not allow this, have no fear! Pre-generate some good sounding variations for the often played effects and randomly select between them.

Example walking cycle in I am overburdened:

If you are not really into the video series but want to hear the difference between the placeholder sounds and the final sounds of the game, here is a timed link: Sound effects comparison

That is all for this post. I already cranked-out tiles and some sprites for the game, so I’m guessing the next entry will be kind of similar, but focusing on the art side.

Take care!

I am overburdened, loot is forever.

Hello everyone!

This entry turned out to be lengthy and pretty technical. Sorry about that, but last week was spent only on “under the hood” stuff. I did my best to make it interesting though 😉 ! So the agenda is the item system which became really sophisticated, especially compared to the size of the game + the difficulty and pacing management.

I settled on the video format of the last entry, because EP 3 was the most pleasant recording experience and in my eyes it was the most enjoyable video so far. So from now on, I’m going for condensed and “scripted” logs focusing on the features and development of the game.

Items, loot

2017_02_19_screenshot_1

The plan for the game is to have a wast and diverse set of unique items (approx 100). Since no leveling will take place, the player will have to risk collecting as much loot as possible during the journey and focus on customizing the play-style by carefully picking which items to wear. So the technology behind the game has to support a great number of skills and excessive customization of the items, but also has to allow lightning fast iteration times, since I will be spending a significant amount of time during the upcoming 2 to 4 weeks with designing and balancing the possible loot.

Attribute bonuses

2017_02_14_gif_1

The easiest development was attribute bonuses on items. Adding the following piece to the descriptor of an item in the loot configuration file will provide the given bonus attributes to the player while equipped:

<Attributes>
  <Attack>1</Attack>
  <Defense>2</Defense>
  <Vitality>3</Vitality>
  <Speed>4</Speed>
  <Luck>5</Luck>
</Attributes>

I highly recommend calculating most of the final modifiers and attributes of a character in RPGs every time one is needed. The more caching you introduce into these systems, the more groundwork you lay for pesky bugs to occur, so keep it low! Usually these calculations are pretty simple (will never be a performance hit) and the hard-coded constant formulas will be really straight-forward to follow.

public class Attributes
{
    public int Attack;
    public int Defense;
    public int Vitality;
    public int Speed;
    public int Luck;

    // events ...
}

public class Player
{
    public Attributes Attributes;

    // handle pick-ups and other logic related to permanent attributes...
}

public class Inventory
{
    public Attributes Attributes;

    // handle item pick-ups and other logic related to item attribute bonuses...
}

The player data holds the permanent attributes of the character (starting attributes + permanent power-ups) and the inventory holds the sum of the attribute bonuses from the equipped items (only a tiny bit of caching) recalculated every time it is changed (e.g.: item pick-up, item swap etc…). The final value of an attribute is the sum from these two structures and the modifiers queried from the extra skills of the equipped items applied to it.

Skills, event system

For a high level of flexibility and to have a varied set of special skills I implemented an event system. I followed a similar but a bit more dynamic approach as the built-in event language feature of C#. Essentially an event is a string (the name of the occurred event) and a context holding additional data related to it and a skill is an event handler implementation.

Event systems can be implemented a number of ways each having their strengths and weaknesses, but all-in-all the following is pretty close to the my solution:
WARNING pseudo code incoming!

// Actual skills need implement this class:
public abstract class Skill
{
    public void HandleEvent(string name, EventContext context)
    {
        if (this.EventsHandled.Contains(name))
        {
            // Additional checks related to the context...

            TakeEffect(name, context);
        }
    }

    protected abstract void TakeEffect(string name, EventContext context);

    // Some helper methods...

    public HashSet<string> HandledEvents;

    // Additional requirements for the event & context...
}

// Special events extend this structure to "add" extra data to the event context:
public class EventContext
{
    // The creature whose action lead to the event:
    public Entity Creature;
}

The execution of the “TakeEffect” method can also be chance based (luck of event firing creature is taken into account). so a skill may only take effect with a given chance (e.g.: 10% chance to “XYZ” types).

An item can have a list of skills listening for events when equipped by a creature. Some events pass in an extension of the “EventContext” class with extra information, like the damage dealt, or the target creature attacked etc…

Few of the most common events in the game:

  • NextDungeonReached: the player reached the next level.
  • Attacking: a creature starts attacking.
  • OpenChest: the player just opened a chest.
  • Pickup: the player picks up a bonus item (e.g.: health potion, gold sack etc…)

Some of the existing skill implementations:

  • Attribute: grants a “bonus” for the upcoming trial (e.g.: +10 luck for the next luck trial).
  • Cripple: interrupts the next attack of the target.
  • Thorns: reflects a “bonus” amount of damage to the attacker.
  • Vampiric: a “bonus” amount of the damage dealt is healed to the attacker.

“bonus” == modifier applied to an integer value. Can be an integer like +/- 5 or a percentage like +/- 5%. The integer bonuses are applied first and the percentage modifiers afterwards.

Most of these events and skills took only a few lines of code to integrate and I have several more ready and working. Combing and configuring them to take effect on specific events with various chances is already an immensely versatile system to build items 🙂 !

Tags

String tags can be added to a creature when describing it in a configuration file, like: undead, deamon, boss etc… The event system allows to define tag requirements for targets before a skill can take effect. A creature meets a given a requirement if it does not have any tags from its “can not have” set of tags and has all the tags from its “must have” set of tags. It is as simple as that.

2017_02_20_gif_1

2017_02_20_gif_2

This tiny addition allows skills which have real “character” to be made. Some cool examples would be monsters tagged as “undead” and a life-steal granting sword which does not work on them (pictured in the GIF), or a holy shield which grants enormous extra defense, but only when attacked by monsters tagged as “deamon”. This also allows to disable certain skills against bosses which could make them too overpowered otherwise.

I’m still at the beginning when it comes to designing the concrete items, but with these systems in place I hope I’ll have a pleasant experience while implementing the actual artifacts. As closing words for the loot topic, here is a rather complicated item description just to show how this is all put together in configuration files:

<!--
  Forearm armor:
    +1 Defense
    20% chance to cripple non "Boneless" enemies
-->
<ItemDescriptor>
  <Type>Forearms</Type>
  <Name>Vambraces</Name>
  <Sprite>Item22</Sprite>
  <Level>1</Level>
  <Attributes>
    <Defense>1</Defense>
  </Attributes>
  <Skills>
    <Skill>
      <Cripple>
        <EventHandled>InflictDamage</EventHandled>
        <ChanceBased>true</ChanceBased>
        <Chance>20</Chance>
        <TargetTags>
          <CantHave>
            <string>Boneless</string>
          </CantHave>
        </TargetTags>
      </Cripple>
    </Skill>
  </Skills>
</ItemDescriptor>

Difficulty, pacing

It’s important to constantly introduce new content and to increase the difficulty curve so the player always finds a challenge while progressing deeper into the depths of the dungeon. I achieve this with a construct called “dungeon profile”. For each level of the story (currently planning to have around 30) a profile will specify which tile-set to use, what kind of monsters can be spawned and what type of pick-ups, treasures and chests can be placed. Of course this data is read from asset files and it is fed into the dungeon generator after constructing the layout for a level. This gives fine control over the length, the pacing and the minute to minute difficulty changes of the whole game without modifying a single line of code.

2017_02_20_pacing_1

Yep, last week was rather busy, though I’m behind my schedules once again 😦 . A little more than a week ago I was confident I will have some (even if not many) art assets done for the game by now. Sadly slipped a little. This is the next step though, so the following entry will have pretty sprites and screenshots 😉 !

Stay tuned!

I am overburdened, prototyping.

Hello everyone!

I worked on a lot of stuff since my last post:

  • Thought a lot about the content/format of my blog and my freshly started video series, and made some decisions about their future.
  • Worked on the linux/mac port of KREEP, but still no announcements yet (but not far).
  • Lot of progress on the development of “I am overburdened”, although not as much as I hoped 😐 …

Blog

Both the last video and blog entry were huge in length and quite empty (video was okay? I guess as the first one). My goal with the series is to have a little introspection of the development process and to showcase the games I’m working on + to gather some interest for them. Of course with dreadfully uninteresting videos this is not going to happen 😀 . Cooked up these rules and goals to try to fix this:

  • Cut short the videos or fill them with more “action” (50+% game/feature showcase sounds about right).
  • From now on measure word-count and aim for 500 to 600 word long written entries.
  • Made an introduction video. This allows omitting the silly “greeting and explanation” section from the upcoming entries.
  • Embrace “freestyle” recording to act more naturally (+ to cut down the time it takes to prepare an entry).
  • Increase recording quality.

So here it is, in it’s full glory, episode two:

As always, open for critique and comments both for the video and the blog entry. Please leave them here or below the video, so I can make better follow-ups.

Progress

Steady, but a tad bit slow. I hoped I could complete all the core features by now, but failed to implement monsters. It is starting to become a real game though, but I’m still in the “prototyping” phase, hence the title. Here goes last weeks progress in GIFs:

RPG layer

2017_02_02_gif_1

The RPG design and its implementation is mostly complete. Our hero has health points (damage, healing and death when reaching 0 works), and the main attributes are done (most of it is integrated and takes effect on certain events).

  • Attack: damage output.
  • Defense: damage reduction.
  • Vitality: maximum health points.
  • Speed: who attacks first.
  • Luck: luck trial influence (item find chance, potion efficiency etc…)

Pickups

2017_01_31_gif_1

Treasures scattered around the dungeon floor are fully functional. There are various types (e.g.: gold sacks, health potions, permanent attribute bonuses, random artifacts), with varying probabilities to be spawn. The system is data driven, so without modifying the game a lot of pickups (and types) can be added to the mix easily.

Chests

2017_01_25_gif_1

Chests, the most valuable targets, are working. Again large part of the system is data driven (sprites, cost to open, probabilities etc…) and I have some “okay” default chest settings added to the game already.

Items and inventory

2017_02_02_gif_2

The inventory system and the basic item logic is in place. Items don’t have their bonuses and skills implemented yet, but I’m already working on it 🙂 . The plan is to have an event system “fueling” the skills, so the bonuses can be configured in tiny “scripts” (e.g.: [+X] [“Attack”] when [attacking “undead”] or [+Z permanent] [“Health points”] when [reaching “stairs”]). It has to carry the weight of 100+ unique items, so I hope this approach will be adequate.

2017_02_04_screenshot_1

As the next step, I have to complete the monster and battle logic. I put down the skeleton code for this too but it is going to take a few days to finish. Once that is done, the game will be pretty much playable, but lacking content and original assets. So the next post will focus on the monsters, finalization of the RPG layer and the item system. Maybe it will have plans for an open alpha release too 🙂 ?!

Stay tuned!

I am overburdened, begins.

Hi there!

This entry is the first one for the new game I’m working on called “I am overburdened” and the first one when I publish a video log entry too! I decided to try this format due to the following reasons:

  • I’m writing pretty lengthy posts (I know I’m a blabbermouth) and at this day and age many dislike to read even if the topic is interesting. I can totally understand that, since a video log or a pod-cast can be listened to while doing something else, it is usually more content rich and it takes much less concentration/effort to mentally digest.
  • I also like to consume this type of content myself, besides following and reading blogs of many indie developers, I subscribed to (or watch occasionally) a number of developer/designer video logs.

Content wise it essentially matches this entry, but has much more live stuff presented. I would like to continue creating these videos too (and would love to make them as frequently as the blog entries) as I had fun recording it, so I encourage you to leave a comment/critique here or under the video on youtube to help me make it even better (or fix annoying things about it) for the upcoming episodes.
So, here goes nothing:

The project.

If you followed my devlog, you probably know by now, that the new game I’m working is a small project, with the goal to complete it and take it to market in a short period of time, focusing first and foremost on practicing my skills. Currently I’m at a point where the design documentation (and the feature set) is finalized and parts of the prototype is up and running. The estimation was readjusted once already (the first version of the design was too big) and I imposed a hard scope limit on myself for this project to achieve it’s personal improvement related targets.

3 months + I’m not going to work full-time on it (only approximately 32 hours per week), so in less than 400 work hours the game has to reach a ready to be packaged and published state. That is the ultimate goal this time and for this to work out well I really had to cut corners and accept a design and feature set which fits into 300 hours (say no to dream features, innovative grand ideas etc…). The rest is there for overhead, “nice-to-have” features and because humans estimate time effort rather badly.

I have to say, designing a game with this tiny scope itself, which I still would be proud to take to market, was a challenge in an off itself and it took some time to pull off, but I feel like I succeeded. I’m confident, that I can deliver this game in time and I can make a fun experience out of it’s core idea.

2017_01_31_numbersCurrent project numbers (containing a possible Steam release work too) relative to the numbers of Operation KREEP. It shows, that the first draft turned out to be too big, so I cut features (a lot) + I gave myself a big enough buffer this time (nice-to-have) if I’m running over my estimates. I think a project with this scope should have been my next project after KREEP instead of Unified Theory.

The idea.

So the game is going to be a small “arcadey” rogue-like with a fun twist to the tried and true formula. The core idea driving the design were artifacts/loot and a huge and messy inventory 🙂 . Every single item in this game is going to be unique with mostly unique skills and abilities (or a unique combination of them) on contrary to the procedural item design of many action RPGs. Around a 100 items are planned currently, will see if I can create those in time. The other “weirdness” is the number of slots in your inventory, which is 20 😀 😛 . So from feet to head gears, everything, literally! * Mystical zombie blood tainted socks of the necromancer *. Nope this one is not actually planned, but you get the idea. Since there will be an armada of items and item abilities + a huge number of slots and thus items to wear parallel, all of the character customization will be done by gear. No leveling, no extra maximum life received after killing a bunch of monsters. You have to get more “powerful”, by collecting lots of magical artifacts and selecting your preferred bonuses.

A vertical slice of the features to convey a better idea for the final product:

  • Turn based rogue-like with perma-death.
  • Huge inventory (20 slots) with a great number of artifacts to find.
  • Carefully crafted RPG system with complex customization possibilities thanks to your inventory, but no leveling!
  • Semi-procedurally generated dungeons using hand authored layouts.
  • Run focused campaign, playable in short bursts with lots of deaths/retries 🙂 , full of intense battles all the way.
  • A funny story, packed with a vicious evil, puns, jokes and a hero with a surprisingly large carrying capacity.
  • Hall of fame for remembering your best playthroughs.

It is pretty early to show screenshots but I decided to share how the prototype looks at current stage. Important to note that nearly 100% of what you will see now is composed of open art assets, so the look is fully subject to change!

So there you have it, I am overburdened. During this week I’ll complete the final prototype which will have all the core features working. Afterwards I’m going to move onto mostly producing content for the game (dungeon layouts, monsters, items and abilities etc…), but probably by next week it will still look kind-of the same, as I’m planning to work on the graphics only at a later phase, when the game is already in a solid playable state.

Important news: you can follow the daily progress of the game too on it’s Trello board.
2017_01_24_trello

I could go on about this game for pages (as always 😀 ), but this should be enough for this week.
Take care!

Magic Item Tech, persistent.

Hello everyone!

Even though a lot of indie game developers put together a “year in review” posts by the end of December, I haven’t written in a while. Sorry for that, but the last few months of 2016 were a bit busy and chaotic, that is why I wasn’t in a mood of writing down my version and why I needed some vacation time badly.

For two weeks I was off-line, not touching any social media, spending all the holidays and some extra spare time with family, friends and games (Factorio, Risk of Rain and Torchlight 2, lots of fun 🙂 !!!).

I’m ready now to write down my thoughts about last year and to plot my plans for the upcoming one which is full of possibilities 🙂 . I separated various topics into their own paragraphs with their own header if someone is only interested in specific aspects (and for tldr reasons 😀 ).

Last year, pros and cons

2016 was a game changer for me (pun intended). I started working full time on my games (huge decision), had my first Steam release and also made an update for Operation KREEP (well received by existing players), participated in a Steam sale (again, first time for me), and haven’t made much money 😀 . I was prepared for this, since I already read a lot and knew about the financial realities of indie games + Operation KREEP was already on Steam when I made the shift, so I planned out my indie venture in a way that more than a full year is available (due to lots of savings) to release multiple games, so no biggie.

2017_01_04_christmas
A lovely Christmas present I’ve got from my wife to celebrate and remember my achievements as a game developer, much love 🙂 (sorry for the bad quality, these are framed pictures of Memorynth and Operation KREEP).

There was a bad part though which made me pretty sad. It is my progress as a game developer and my latest endeavor, Unified Theory. I hoped, that by finishing two games and releasing one on Steam I’ll be able to pull this off again and again. I feel like I learned an astonishing amount about game development during the production and the after life of Operation KREEP, but I failed to apply this knowledge on this project and failed to expand it ever since. At least this is how I feel about the last couple of months. The project is a mess and I came to serious conclusions and made an important decision in the last two weeks which I’m going to unfold in the next sections.

Operation KREEP

This game has a special place in my heart by now 🙂 . I know it is not a big thing and commercially it did not break even, but it wasn’t it’s ultimate goal in the first place (most of it was developed while I had a day job). I released it last summer on Steam, and so far with the other stores, sales and bundles combined at least it made some pocket money. As I mentioned, I learned an awful lot about planning, production, pr, marketing, publishing and further maintaining a game (so the whole gamedev package).

During autumn, I made and released a small update for it and experienced the black magic of traffic analysis, visibilities, the wishlist, the discovery queue and the like on Steam first hand. KREEP was also discounted during the winter sale. Together these two events netted as much as the Steam release, which wasn’t much but it is still nice. This may be an important bit of info to all indies out there: there is a tracked average conversion rate of all wishlists on the whole Steam service (which is kind-of a low percentage for real 😐 ). Do not expect a bigger number than that for your game, even if you discount or update your game (you know, DOOM and XCOM2 is also discounted all the time 😛 ). Maybe in the long run it can be better with multiple discounts and updates.

A small announcement regarding the game:
It is currently taking part in an Indie Gala bundle. If you are interested in trying it out, now you can get a Steam key for it dirt cheep + keys for 11 other indie titles on Steam 😉 .
I know bundles have a rather bad reputation these days, but they sort-of allowed me to get the game on Steam in the first place + it is now in the Steam library of thousands of players, which probably would have never happened otherwise. I know bundling your game probably means, that it is not selling well (heck it usually is an equivalent of a 75%-90% discount), but you get some word out about your game and you get a lot of new players, even if it only yields a tiny revenue.

2017_01_11_indiegala

I’m also working on a Linux/Mac port. There have been multiple requests for both builds + having cross-platform development experience and a build pipeline in place is valuable in the long run (I know, that both users combined are still less than 10% of all desktop gamers), though I’m still fighting with the Linux build 😀 😦 , but slowly getting there.

Unified Theory

A mess. I’m going to expand on this, but I have to explain what type of development process worked well for my previous two games. Growing up, I was always a tad bit disorganized. So when I finally decided to pursue my dream of becoming a game developer, I knew I had to get myself together and become more disciplined. I picked up some management know-how during my half-decade long career as a software developer and decided to apply the fundamentals and pick up a management hat too (besides the programmer, designer, artist etc. hats) while I work. It worked wondrous, so much so, that I considered it my best decision and one of the most important factors for shipping a project. I divided my projects into phases like planning, pre-production, production (and this one into smaller chunks like alpha, beta and final as milestones, due to being a big phase), release and post-production. Estimated both the possible time requirements and risks of various tasks during the planning phase and sliced up tasks until they took only a small manageable amount of time (maximum a day or two). Writing a quasi detailed game design document during planning and extending it in pre-production helped a lot to have a clear vision, and also documented all the possible extra design ideas I may want explore during production if I have the time/drive. During production I tracked the time I spent working on the project on an hourly basis, and kept a small TODO list too to have a prioritized list of tasks to focus on during the next couple of weeks for reaching each consecutive milestone. I also adjusted my estimations when closing a phase or reaching a milestone to have an up to date educated guess what is coming up and how far I’m actually from finishing and releasing the game. Everyone works differently, but if you are having a hard time with budgeting your game, or always over-scoping it, or ending up in a constant spiral of “it will be finished in two months maximum!”, I highly recommend you try out these things. Seriously.

Now this proposal concerns me too 😦 . Even though, these steps helped me to ship two games before, I pretty much neglected them while developing Unified Theory. I did do an estimation, I tried to cut some features (but did not do it properly), I kind-of divided the whole thing into phases, but never checked nor readjusted my numbers, and never tracked my time rigorously. Slowly, I took off the management hat. I was aware of it while it was happening, still I tricked myself into believing it is not a necessity, because I already shipped a game before + I have a huge drive now, even bigger than with my previous games (I loved the concept of the game + not earning money currently 😀 ). Thankfully I realized the horrible mistake I’ve done and I can act upon it now.

2017_01_11_estimations

These are the estimation numbers and the real work hours spent on Memorynth and Operation KREEP (+ Steam release and updates). For Unified Theory the spent hours are just an approximation based on the days spent working on the project, since I only tracked about the third of the work time I spent on the game. It is kind-of clear on the readjustments too, that I did not put enough effort into my estimations of Unified Theory. The frightening part is, that I only have approximately 50% of the tasks completed and almost as much time spent as the original scope, so I pretty much underestimated the project, did not cut out enough low-yielding high-risk features and never took the time to get my numbers together. This really bugs me. I don’t really have a clear picture about what is and what isn’t done, how much time it took to get here, what could I cut if the game turns out to be too big of an effort (which is already the case) and I especially can not make an educated guess about when could I complete and release the game.

A simple “okay, from now on I’m going to do it right!” will not do justice. I have to practice these skills again and I have to rebuild Unified Theory project wise when I reacquired the necessary attitude. For this to happen I’m going to put the project on the back burner, meaning from now on it is not a full-time project! Yep this is a harsh move, but I think this has to be done. I’m afraid of stopping it, since it would be the direct road to forgetting the project which would be a ridiculous waste of time and energy. So I’m thinking about working one or two days every week on it, to keep the momentum and the ideas alive, while I’m doing a short game project parallel to reinvigorate myself and to practice before resuming Unified Theory full-time. I think this is pretty sad in one way, but I’m confident, that this move will help me in the long run and will ensure, that the game will see the light of day in the best possible shape, only I will release it later than I originally “planned” 😦 …

I’m overburdened

The header is pretty misleading 😛 . I’m not overburdened, actually I’m currently enjoying a “healing” time-frame both physically and mentally, but this is the title of the game I started working on last week parallel to Unified Theory . I have the core concept ready, working on the detailed game design document and the prototype currently. It is in an early state, so I’m not going to talk at great length about it, but here goes nothing:
It will be a really simple “arcadey” roguelike game, with some interesting/funny? twists to the common formula and I’m going to re-apply and practice all what I’ve learned during the development of Operation KREEP. Based on my initial plans and numbers it will be a really good project for this goal, because it’s scope (even with a greenlight campaign and a potential Steam release which would be nice 🙂 ) is smaller than the final scope of the original 1.0 KREEP release (before KREEP got onto Steam). This means, that it can be accomplished and published in less than three months by working on it approximately four days a week. These numbers may change during the planning and pre-production phases, but the scope will not be increased (instead features will be cut aggressively), since it is crucial to finish this project in a short amount of time, otherwise it may endanger the development of Unified Theory which I would steer clear of at all costs.

Website

Small news as closing remarks. I’ve updated my website a little. Made a new logo for my gamedev “formation” + added some new short stories and pictures. Also there is an official Magic Item Tech newsletter! Experts tell it is an effective way to build an engaged community 😛 , be sure to subscribe 😉 .

logo_16_9

Next week, I’ll be able to tell (and show!) more about my roguelike pet project “I’m overburdened”.
As always I’m open for critique, comments and suggestions.

Stay tuned!

Magic Item Tech, news.

Hi there!

Only a handful of tiny news this time about Magic Item Tech.

Domain

Now my game development blog and contact information can be reached at: https://magicitemtech.com
I’ve reserved this domain long ago, but forgot about it a little. Now it’s set up to forward to my blog and feels a tad bit more professional. I’m already working on beefing up the graphics design of the site and preparing to have a newsletter service too for upcoming blog entries and game development news.
Soon…

Unified Theory not ready for Alpha

I’m preparing for the alpha release of the game, but it still needs a week worth of tasks to be done + some accompanying materials need to be created and organized to be ready (e.g.: a feedback form, some marketing media, maybe analytics too ?!). If you’ve already been expecting the open alpha, I’m sorry. I really don’t want to rush it, since I would like to get feedback about the design and overall feeling of the game, instead of reports about minor bugs, glitches and the incompleteness of the user interface. So probably another week of extra work it is…

Operation KREEP let’s play

James Kacer and his friends tried out Operation KREEP and they had a blast. So they made a let’s play video about it, for which I’m extremely thankful. This is the first let’s play of the game (at least the first one I know of), so I watched it with great excitement and it seemed they had fun while playing + I had fun while watching it, so I’m super happy about it!!!
Here it is for you to enjoy:


Hooray for James and his friends!

Operation KREEP 1.2 update plan

I really wanted to put some minor extras into the game for a long time now, but due to the prolonged development of the Steam release I didn’t want to work on it (took too long and got pretty tired of it the last time). I decided to give it another try, but only make an extremely small patch. The design doc is ready and it is indeed humble. It will only take a few days of work (a week at maximum) with marketing and release, so no overtime, no delays, only a tiny update under a week during this month. Due to its scale constraint it will be more of a marketing experiment than a huge update like the 1.1 version, but a few new cool stuff will find its way into the game. Will see how it turns out.

That’s all folks this time.
Take care!