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, Unified Theory.

Hi everyone, long time no see!

It’s been a while since my last post (more than two months), and back than I sort of hinted that in a week or two I’ll be ready to present the next game I’m working on 😀 …

Here is what happened:

I’ve been working on the prototype of this project of mine, coding the core features zealously, filling my design doc with cool ideas, but the mechanics simply did not add up. The concept on paper sounded really cool and straightforward, but the actual fine-detail design and implementation was nightmarish. I hit a lot of roadblocks during the formalization of the rules and I had to redesign some mechanics and re-implement parts of the prototype a couple of times 😦 .

Takeaway:
What sounds as a nice and simple concept on paper may bite you in the a$$ during realization…
“The devil is in the details!”

Okay, so the prototype is ready now (playable and feels good) and I’m ready to present it. I took some pictures and some game-play footage, but keep in mind, that the game is filled with placeholder art and is heavily work-in-progress currently!

Unified Theory

A real-time strategy puzzle game which plays with the idea that the workings of the whole universe could actually be described by one formula, one grand rule.

A little about how it works and how it looks currently:
Unified Theory, screenshot from the prorotype #1

Unified Theory, screenshot from the prorotype #2

The core concept is simple. Take a real-time strategy game like Starcraft, but remove all the units except for the worker one. Unified Theory will contain only one “unit”, but will feature all the common tasks of arcade RTS games like: mining, building, research, upgrades, tech-trees and battles. Another BIG gotcha, is that you have no direct control over your units, but they march blindly towards the direction they started out when they were created! You will only be able to place buildings on the levels to interact with your units, and to actually solve logistic and management problems (and later to battle enemies) by controlling your “army” indirectly. Due to these rules, the game is probably more closer in controls and feel to a Tower-defense game or a management game focusing on base building, than to an arcade RTS.

To better showcase how this works in action I’ve captured a little footage of me playing with the current prototype build:

And why is this a puzzle game? Well, in its current state it is not, but the “campaign” levels of the game will focus more on solving puzzles related to level traversal, logistics and management of your base with serious constrains (resources and/or technology), so the final version will feature equal parts strategy and puzzle solving.

What is this “one formula” technobabble story?! Well, the core of the game is a really really really simple discrete math construct (cellular automaton), but it can actually be used for really complex stuff (like programming/calculating anything 🙂 ). I’m being constantly amazed by these seemingly simple but infinitely deep systems and the intricate connections of math and nature. This fueled me to choose this theme as the “story”, to tell about the beauty of this phenomenon instead of having a classical plot where faction A fights faction B for glory and whatnot…
I still have to work out the detailed structure and presentation of this “narrative”. Will see how this goes, fingers crossed 🙂 .

The plan, whats next:

In the upcoming week or two I will work on the look and feel of the game and make it more appealing and accessible. When this is done and the game more closely resembles my final vision, I will release an open alpha version. The goal with this build is to gather feedback on the core mechanic and the accessibility of the game. Plus I’m hoping it will start building some “traction” for the siege of the gates of castle Steam, the holy battle to acquire the legendary green-light 🙂 . Most probably I will keep it updated and re-release it with the final version as a demo.

This alpha build is the next big step, but afterwards I will focus on building an engaging campaign full of puzzles and strategic levels.

Stay tuned!