• entries
    50
  • comments
    87
  • views
    50089

Entries in this blog

Spidi

Hello there!

In the big sprint towards publishing this game I forgot to update my blog with a proper release announcement :D . I had to split myself in millions to actually finish the game and put it out there, but still, silly me how could I forget :| .

Takeaway: I have to prepare better for my next release, but I heard from other developers, that no time is actually “enough” :D .

boxart_animated_art_portrait

Released

Yes, I Am Overburdened was released at evening (by GMT) on the 2nd of November.

It can be bought on Steam and itch.io for 4.99$ and there is a launch-week 20% discount so get it while it’s hot (currently at 3.99$ which may vary based on region)!

icon_steam_small icon_itchio_small

There is also a tiny extra for my previous customers, call it a “gesture” if you will. On Steam if you bought Operation KREEP before, there is a Magic Item Tech RETRO Bundle to “complete my games” and you get an extra 10% off for I Am Overburdened (sorry itch.io users, I haven’t found a way there to bundle it like this).

First day

Now that I’m over the big rush for the release and over the first day, I can slowly ease into handling issues and working on updates, fixes and fine-tunings. The first batch of feedback is really positive and I got decent featuring from the press so far, which is awesome. People seem to understand and like the game, many even praise it and are really enthusiastic about its future :) . This is an awesome feeling!

The game is up to a slow start sales wise but it is too early to draw any kind of conclusions (it’s only been a day). Of course I will do that in a few weeks in another blog entry. Fingers crossed :) .

Thank you!

Allow me to grab this opportunity to formally say thank you. Thank you for all who followed the development. Thank you for those who supported, helped and encouraged me along the way. Thank you for everyone who contributed, either with tips, suggestions, testing or critique. And thanks for everyone who already bought the game, I hope you all are having a great time :) !

I’m adding a new screenshot about the inn in the game (pun intended :P ), because in the last two weeks of development I changed it a bit (added even more stuff to the game :D ).

2017_11_04_screenshot_1

Thanks for reading, I’ll be back with more stuff soon.
Take care!

Spidi

Hello there!

This is going to be a painful post for me, but I got to do it :( ...

TLDR:
I had to postpone the release of I Am Overburdened by a little more than a week, to the 2nd of November :( !

2017_10_23_approved.png

That is the Steam workshop page. The build is approved, only a press of a button would make it live, yet I messed it up big time!

During the "hopefully final" test session this weekend I discovered few severe technical issues (bugs :( yuck). Since I went to a family visit I did not start fixing stuff + it would have taken more than a few minutes (still tried to work a little during the middle of the night :P , but with no luck yet :| ) . I also miscalculated how much time I will have for creating proper release marketing materials today, so all in all I simply did not prepare well for the 23rd of October.

I can not express how sorry I am and how shameful I feel right now. This was an extremely hard decision to make. I made a lot of posts around the INTERNETZ with the previous release date, trying to gather some interest around the game, but releasing it in this state would go against my principles. I simply don't want to publish a buggy product.

2017_10_23_sorry.png

I know, I know, there will be bugs, no software is perfect, but as I stated numerous times before, a good game tomorrow is better than a mediocre one today and we are talking about only 10 extra days. "If it is only a few bugs and a bunch of marketing materials why not only a few days instead, why more than a week?!" Good question and the answer is simple. This is already and immensely embarrassing situation, even though I know I'm making the right choice. I feel like I'm letting people down who wanted to play the game today :( . It is a no-brainer, that I don't want to end up in something similar again. Targeting the 2nd of November will give me plenty of time to fix the remaining issues and prepare for a better launch without an absurd work-schedule.

I hope you understand my decision and forgive me for my messed up planning. I thought about continuing the release calendar at least. I prepared the first extra one and if you are interested I will keep posting it ;) .

item_15.png

Again, I'm really sorry. I'll try to make it up to you with an even better game :| !
Take care.

Spidi

Hi everyone!

This entry is a bit more like an announcement and less like a devlog entry, but here it goes:
I Am Overburdened is going to be released on October 23 for PC :) !!!

Here it is, the release trailer featuring some fun game-play footage in all its glory:

Store, platform, price & wishlisting

The game will be sold primarily through Steam and itch.io for Windows PC initially. The future platforms will depend on how well the game does sales wise. I would not like to promise any other devices/OSs upfront as porting can be a big effort so if the game flops I may not have the time/capital to deliver.

It will cost 4.99$ (may vary based on store & region).

It is a relatively short game, but has a huge “replayability” factor.

Since it is run focused and has permanent death, completing it once will take less than an hour, but the game has enough content (artifacts, monsters, procedural dungeons, unlocks, game modes) to keep it fresh for dozens of playthroughs.

I really believe it is a correct price point. It has a lot of fun stuff to keep you entertained for a while ;) .

You can already wishlist the game on Steam to get an e-mail on release day:

icon_steam_small

Or you can follow my developer profile on itch.io to get a notification:

icon_itchio_small

My website, the Steam store-page and the Steam Community Hub already has a lot more information about the features of the game and the release itself.

Release calendar

I’m doing a little marketing “sprint” thingy up until the release day. I’m calling it the “Wishlist Release Calendar”. Essentially, to promote the game a little, I’m going to release an artifact from the game every day with its “fluff” text on various channels (here too) updating or posting the new version of the following image:

item__0

Heeeeeeeelp!

If you like the game or liked it’s development “story” you can help me. Wishlisting the game now on Steam (even for buying it later) or buying it on release day (there will be a tiny discount ;):P ) supports me tremendously. Even if you are not really interested in buying/playing the game you can help. How :o ?! It’s simple, share it. Share a store-page link or the trailer with friends and relatives who may be interested in playing it. That is all! It’s really nothing, but it may allow the game to reach a broader audience, and thus in the long run may allow me to further support my game development journey :) .

Thanks in advance.

Promises, future

No one knows how the future unfolds. I have confidence in the game, because it is AWESOME, but I’m crazy nervous :( . The success of a game doesn’t only depend on its quality (or I should say the quality it’s developer perceives :| ). No matter how this release turns out I can promise more devlog entries ;):) . At least one about the last development weeks of I Am Overburdened and a little later a postmortem entry about it.

My journey may change course, but it doesn’t end here :) , wish me luck ;) !

Thanks for reading and thanks for all the support so far!
Take care.

Spidi

Hello there!

I'm still alive and working on the game so I jump right into what I worked on in the last month or so. Even though I was pretty silent a lot has "changed". The topic will be polishing, because it never stops :P , some input handling tricks and another pretty complex one: game balance.

Polishing

During a series of play-test sessions with friends, family and old colleagues I gathered some really valuable feedback on how to enhance the user experience. Thankfully the game itself was well received, but the mentioned "issues" really bugged me, so I sat down for a week or two to further enhance the presentation.

Cost indicators

This was a tiny addition but helped a lot. Now the color of the chest and shop item cost texts reflect the state whether you can open/buy them.
2017.09.02. GIF - Cost indicators

Animated texts

I went into an in-game UI tuning frenzy, so I added a "pop" animation on value change, besides the existing yellow highlights, to gold and attribute texts.
2017.09.03 GIF 1 - Animated texts

Health bar

The health bar got some love too! I implemented a fade-in/out effect for the heart sprite slowly turning it into a "black" one when you are low on health. I also added a maximum health indicator and the same value change "pop" animation I used for the gold and attribute texts.
2017.09.04. GIF 1 - Health bar

Battle events

Battle events and various skills (hit miss, dodge, fear or cripple events etc...) got many complaints due to their visibility being insufficient, leaving the player puzzled sometimes why a battle didn't play out as expected. Besides using the existing sprite effects I added text notifications, similar to the ones used with pickups. No complaints ever since :) .

2017.09.05. GIF 1 + 3 - Battle events

2017.09.05. GIF 2 - Battle events

Critical strike

This one was an "extra". I wanted to beef-up the effects of the critical strikes to make them look more ferocious and better noticeable.
2017.09.06. GIF 1 - Critical strike

Level transition

Play testers shared my enthusiasm towards having a better level transition effect, so I slapped on a black screen fade-in/out during dungeon generation and it worked wondrous.

Input handling

I knew for a long time now, that the simple input handling logic the game had will not be good enough for the shipped version. I already worked a lot on and wrote my findings about better input handling for grid based games, so I'm not going to reiterate.

I mostly reused the special high-level input handling parts from my previous game Operation KREEP. It was a real-time action game, so some parts were obviously less relevant, but I also added tiny new extras.

I observed players hitting the walls a lot. Since the player character moves relatively fast from one cell to another this happened frequently when trying to change directions, so I added a timer which blocks the "HitWall" movement state for a few milliseconds towards each walled direction for the first time when a new grid cell is reached. Again, results were really positive :) .

2017.09.16. GIF - Input handling

Balancing

My great "wisdom" about this topic: balancing a game, especially and RPG, is hard. Not simply hard, it is ULTRA hard. Since I never worked on an RPG before, in the preparation phase I guesstimated, that it will took around 2 to 3 days of full-time work, because after all it is a simple game. Oh maaaaaaan, how naive I was :( . It took close to two weeks. Having more experience on how to approach it and how to do it effectively I probably could do it in less than a week now with a similar project, but that is still far off from from 2/3 days :D .

Before anyone plays the judge saying, I'm a lunatic and spending this much probably wasn't worth it, I have to say, that during the last 6 months nothing influenced the fairness and "feeling" of the game as much as these last 2 weeks so do not neglect the importance of it :| !

Now onto how I tamed this beast!

Tools and approach

Mainly excel/open-office/google-sheets, so good old-fashioned charting baby :) . And how? I implemented almost all the formulas (damage model, pickup probabilities, loot system etc...) in isolated sheets, filled it with the game data and tweaked it (or the formulas sometimes) to reach a desirable outcome.

This may sound boring or cumbersome, but in reality charts are really useful and these tools help tremendously. Working with a lot of data is made easy and you get results immediately when you change something. Also they have a massive library of functions built-in so mimicking something like the damage reduction logic of a game is actually not that hard.

2017_09_07_balance_1.png

That is the main chart of the game, controlling the probabilities of specific pickups, chests and monsters occurring on levels. It plays a key role in determining the difficulty and the feel of the game so nailing it was pretty important (no pressure :P ).

If balancing this way is pretty efficient why it took so much time? Well, even a simple game like I Am Overburdened is built from an absurd number of components, so modeling it took at least a dozen gigantic charts :( . Another difficult aspect is validating your changes. The most reliable way is play-testing, so I completed the game during the last two weeks around 30 to 40 times and that takes a long while :D . There are faster but less accurate ways of course. I will talk about that topic in another post...

Tricks and tips

2017_09_08_balance_1.png

#1.: Focus on balancing ~isolated parts/chunks of your game first.
This wide "chest chart" works out how the chests "behave" (opening costs, probabilities, possible items). Balancing sections of your game is easier than trying to figure out and make the whole thing work altogether in one pass. Parts with close to final values can even help solidifying other aspects! E.g.: knowing the frequency and overall cost of chests helped in figuring out how much gold the player should find in I Am Overburdened.

2017_09_11_balance_1.png

#2.: Visualization and approaching problems from different perspectives are key!
The battle model (attack/defense/damage/health formulas) wasn't working perfectly up until last week. I decided to chart the relation of the attack, defense and health values and how their change affect the number of hits required to kill an enemy. These fancy "damage model" graphs shows this relation. Seeing the number of hits required in various situations immediately sparked some ideas how to fix what was bugging me :) .

2017_09_11_balance_2.png

#3.: ~Fixing many formulas/numbers upfront can make your life easier.
Lot of charts I know, but the highlighted blue parts are the "interesting" ones. I settled on using them as semi-final values and formulas long before starting to balance the game. If you have some fixed counts, costs, bonuses or probabilities you can work out the numbers for your other systems more easily. In I Am Overburdened I decided on the pickup powers like the + health given by potions or the + attribute bonuses before the balancing "phase". Working out their frequencies on levels was pretty easy due to having this data. Also helps when starting out, since it gives lot of basis to work with.

Now onto the unmissable personal grounds. Spidi, you've been v/b-logging about this game for a loooooong while now, will this game ever be finished?! Yes, yes and yes. I know it has fallen into stretched and winding development, but it is really close to the finish line now and it is going to be AWESOME! I'm more proud of it than anything I've ever created in my life prior :) .
Soon, really soon...

Thanks for reading!
Stay tuned.

Spidi

KREEP, missed tap.

Hello everyone!

In my last post about Operation KREEP, I mentioned that for the 1.2 update of the game I made some improvements to the input handling logic and hinted a near future deep-dive into this topic. Quite a while ago, right before releasing the Steam version, I wrote a similar post describing the input handling enhancements I made back than. Although it is a bit lengthy, if you are interested in the technical details of high level input handling logic I highly recommend it. Not a requirement though, since I'm continuing this post with its summary to level up your knowledge for easier digesting of the upcoming technical details.

Short recap

The game plays on a grid and all entities move complete tiles (no standing in between two tiles). Each "move" action by a player will actually take multiple frames to complete (precisely 12 which is 200 milliseconds under 60 fps). The players usually do not feel this (it does not feel laggy/bugging), since it is a quite fast and action packed game + 200 ms is not much and the overall rules/design of the game is deeply intertwined with grid based movement.

The initial movement handling logic was utterly simplistic. If a direction button is pressed the player moves towards that direction, with a silly hard coded priority for handling cases when multiple direction buttons are down: "Up" beats "Down" beats "Left" beats "Right". When a player is already moving and the corresponding direction button is held down it will be handled with highest priority, so continuing movement forward is considered "important/intentional".

Warning, warning incoming pseudo code:

void handleIdle() {
    if input.isPressed("up") {
        startMovement("up");
    } else if input.isPressed("down") {
        startMovement("down");
    } else if input.isPressed("left") {
        startMovement("left");
    } else if input.isPressed("right") {
        startMovement("right");
    }
}

First pass of input handling in "Idle" character state.

void handleMoving() {
    if (input.isPressed(currentDirection)) {
        continueMovement();
    } else if (input.nonePressed) {
        stopMovement();
    } else {
        // this will handle direction change
        // the same way as in "Idle" state
        handleIdle();
    }
}

First pass of input handling in "Moving" character state.

That is it. This simple control mechanism was really easy to code certainly but it wasn't intuitive nor responsive, and clearly intentional actions were missed out from time to time. It took me some time to realize that it was bugging many players and it could be improved a lot.

Around the 1.1 (Steam) release, I made significant changes to this system, by introducing some smart checks to figure out the intentions of a player as best as possible. These rules included:

  • Checking the surroundings of the player character.
  • Taking non-walkable target tiles into consideration (making them a less preferred choice).
  • Taking dynamic blockers like other players, props or the KREEP, into consideration (just as important targets as walkable tiles).
  • Saving the elapsed time since the last press of each direction button to use it for prioritization (presses closer to the direction change in time considered more important/intentional).

These modification made a huge difference back than. At least the "testing committee" (a.k.a. friends) had an immediate positive reaction, although I still had some ideas for improvement I was thrilled by the results. For more details about these enhancements, please check the old post. I'm jumping onto new stuff now!

The missed tap

One thing that was still bugging me related to these movement controls and the overall responsiveness of the game is the "missed tap". Due to one move action taking 12 frames, the direction change evaluation logic runs "rarely" and it is easy to miss it by a frame or two. An occasional maneuver is trying to change "lanes", by moving one tile perpendicular to our current direction, but continuing in the original direction right afterwards.


2016_12_12_gif_1_1.gif

Some players (including me), try to achieve "lane changing" by holding down the main direction button and tapping the perpendicular direction button. The perpendicular direction gets bigger priority, due to the press occurring closer to direction evaluation in time, so it would be selected as the new direction for the player.

2016_12_12_gif_1_2.gif

But being a short tap the button state may be released one or two frames early and usually the following happens:

2016_12_12_gif_2_1.gif

Based on my guesswork, trying to achieve "lane changing" with a tap fails 3 out of 4 times (may be even worse). This is not hard to detect and sort-of can be made sure to be not mixed up with different intentions, so here comes my solution.

Implementation details

Instead of saving only one elapsed time since the press of a direction button, two timers are saved for the last two states (regardless whether it is pressed or released currently). This way we can buffer the most recent changes and the preceding actions of the players related to movement (buffering input events and their timings).

struct BufferedInput
{
    bool pressed;
    float currentElapsed;
    float previousElapsed;
 
    void update(bool state, float dt)
    {
        if (pressed == state)
        {
            currentElapsed += dt;
        }
        else
        {
            previousElapsed = currentElapsed;
            currentElapsed = dt;
            pressed = state; // pressed changed, timers swapped, current restarted...
        }
    }
}

That is the most crucial part of the solution. From now on we can detect the "missed taps" when evaluating the player movement, since we have all the required data. I think each game needs a little fine-tuning / trial and error regarding this part as timings and speed wildly varies between them, but my logic and my numbers may be useful:

const float FrameTime = 1f / 60f; // frame time in case of 60 fps
const float MovementTime = 12 * FrameTime;
 
bool detectBufferedTap(BufferedInput input)
{
    if (!input.pressed)
    {
        var tapTime = input.currentElapsed + input.previousElapsed;
        if (tapTime <= (MovementTime - 2 * FrameTime))
        {
            if (input.currentElapsed &amp;lt;= input.previousElapsed)
            {
                return true
            }
        }
    }
    return false;
}

This means that the game considers a situation a missed tap, when a direction button is released during evaluation, a press occurred at least 2 frames after leaving the last tile (last direction evaluation) and the button was in a pressed state for at least as much time as it was released during these x <= 10 frames.


2016_12_12_taps.png

Taking these "missed taps" into account with just as much priority as a pressed input button, while the player is moving and a direction evaluation occurs, reverses the 3 out of 4 failures, so approximately 3 out of 4 times (maybe even better) a short tap is enough for a tile lane change. Tried tweaking this logic and the numbers, but could not really improve the consistency further. I'm happy with these results though. And again, after this update, controlling the game felt much better than before!

Probably there won't be updates for (nor posts about) Operation KREEP for a long while, since despite my efforts the game could only reach a miniscule audience + I'm getting fully occupied by my upcoming game Unified Theory, but who knows what the future holds...

Take care!

Spidi

Hi there!

I'm not going to go into a big yakking this time about the obvious again. Summarizing: still not advancing as planned and my online presence is still far from adequate, but the update I've been working on is "finished". Finished in the sense, that I've added all the features, fixes and fine-tunings I really wanted to add, but it is not yet released, so a final test and a last big "marketing" push is ahead of me...

This time I would like to talk about the last feature I've implemented, and as the title suggests, it is input handling related. I feel like it was bit of a daring act, but in the final stage of the development I've decided to rewrite most of the input handling logic of KREEP as the finishing step. Yep, it was kind of a bald move, and took some serious effort, both design and implementation wise, at least compared to other features I've been working on lately, but it made such a huge difference, that I'm really glad I made it!

A while ago I had a rather lengthy test session with some friends and colleagues. They told me they had a blast, but I could squeeze out some constructive (negative :)) criticism too. It was targeting the input handling, notedly the movement of the player characters. While I was observing my peers playing, I noticed this sentence come up a couple of times: "it's not moving in the direction I want it to move". It wasn't angry/bad, but heard it enough to start thinking about it, but when I asked around, no one could actually pinpoint the problem, or describe it in more detail, only there was "something annoying" about the feel of the player control.

Some other developer friends, actually praised the controls before, stating, that it is really tight, and feels like older Pac-Man or Bomberman games, so it took me some time to figure out the problem, but approximately two weeks ago I had an "a-ha" moment while playing and realized what was bugging my buddies. The game indeed feels like old Pac-Man or Bomberman games, but I discovered some problems with this scheme (at least with my implementation). The movement is discrete as in the mentioned games, so by pressing a direction key, your character will not stop until it reaches the next tile and the game is pretty fast. It takes 0.2 seconds, so 12 frames (with 60 fps fixed loop), for a player character to move a full-tile distance. When trying to do tight "maneuvers", so turning around a corner, or entering a door, or simply changing your direction at the right moment, you have to be spot on, otherwise you can miss the corner/door! Based on what I've found, this 0.2 seconds is already lower than the average reaction time for humans to a visual stimulus (which is 0.25 seconds by the way). This is pretty common in games, so reducing game speed was not something I planned to change though, especially because it would modify the design and game-feel a lot. I went further down the rabbit hole and found, that not only you have to be spot on in KREEP, but the logic I've implemented for deciding which direction to "prefer", when multiple keys/buttons are pressed in a given frame, does not "aid" the player. It is pretty much stupid (simplistic) and fails utterly in a sense, because in the before mentioned situations (maneuvering), you usually have two buttons pressed...

Here it is what I'm talking about, what the user intends to do is on the first GIF, and the second and third GIF shows what happens from time to time:

2016_05_09_gif_1.gif?w=6302016_05_09_gif_2.gif?w=6302016_05_09_gif_3.gif?w=630

In the first "failure" case, the player is holding down "Right" and "Down" together for a split second and releases "Right" too late, and in the second case "Down" is pressed too late. The latter problem is really hard to battle, but can be done to some degree (still experimenting with that, more on it a little later), but the first one is actually not "fair" (at least the players feel that way: "it's not moving in the direction I want it to move") and it can be fixed using a simple idea + a full rewrite of my previous input handling logic :lol:.

So previously I used a pretty simple input handling logic for controlling the player character movement (warning, warning incoming pseudo code):

void handleIdle() {
    if input.isPressed("up") {
        startMovement("up");
    } else if input.isPressed("down") {
        startMovement("down");
    } else if input.isPressed("left") {
        startMovement("left");
    } else if input.isPressed("right") {
        startMovement("right");
    }
}

Input handling in "Idle" character state.

void handleMoving() {
    if (input.isPressed(currentDirection)) {
        continueMovement();
    } else if (input.nonePressed) {
        stopMovement();
    } else {
        // this will handle direction change
        // the same way as in "Idle" state
        handleIdle();
    }
}

Input handling in "Moving" character state.

There is a huge problem in both parts. One is that a direction "preference" is hard-coded, so "Up" beats "Down" beats "Left" beats "Right" and the other is that while "Moving" the current direction is again "preferred" over other directions, for no real obvious reasons (except for it is easy to code :P).

Both problems and the previously mentioned "multiple buttons pressed" issue can be eliminated easily by adding time-stamps to button presses! Instead of simply checking one button after the other, we always check each direction and the later a button was pressed the more "preferred" it is, due to a simple logic which is: the last button pressed by the player is most probably is the "intended" new direction. This logic off-course can be further enhanced with another trick. It is most probably isn't the "intention" of a player to face a wall when multiple direction buttons are pressed and some of them would mean simply trying to move into concrete, so besides time-stamps, possible directions are checked also.

Here it is, the further enhanced "smart" input handling algorithm (warning, warning incoming pseudo code again):

bool canMoveTo;
direction target;
time pressed;
 
void handleIdle() {
    canMoveTo = false;
    target = null;
    pressed = time.min;
 
    detectTarget();
 
    if (canMoveTo) {
        startMoving(target);
    } else if (target != null) {
        changeDirection(target);
    }
}
 
void detectTarget() {
    foreach (direction) {
        if (input.isPressed(direction)) {
            if (canMove(direction)) {
                // prefer movement over hitting a wall
                // if no walkable target is detected yet use this one!
                if (pressed < input.pressedTime(direction) or not canMoveTo) {
                    targetDetected(direction);
                }
                canMoveTo = true;
            } else (not canMoveTo) {
                if (pressed < input.pressedTime(direction)) {
                    targetDetected(direction);
                }
            }
        }
    }
}
 
void targetDetected(t) {
    target = t;
    pressed = input.pressedTime(t);
}

New input handling in "Idle" character state.

bool canMoveTo;
direction target;
time pressed;
 
void handleMoving() {
    canMoveTo = false;
    target = null;
    pressed = time.min;
 
    detectTarget();
 
    if (canMoveTo and target == currentDirection) {
        continueMovement();
    } else {
        if (canMoveTo) {
            changeDirection(target);
        } else if (target != null) {
            changeDirection(target);
            stopMovement();
        } else {
            stopMovement();
        }
    }
}

New input handling in "Moving" character state.

And here is the representation of the inner workings of the new algorithm in action:

2016_05_09_gif_4.gif?w=630

The direction arrows represent the pressed direction buttons by the player and the lighter color means the most recent button press. Both possible directions hold an orange question mark until the decision about the direction is made (this is not actually checked or saved anywhere until the respective frame). The frame in which the decision happens is "frozen" for a tad bit in the GIF so the choice is clearly visible.
It worked wondrously :)!!! The movement become a bit easier using the keyboard, the multi-press problem disappeared, but the gamepad + thumbstick based control feel got a real "level up" due to this modification! It is really cool. After completing and trying it, I felt that all the updates I've added to the game (new maps, new mutators and achievements) are simple gimmicks compared to this modification. It really makes a difference and I'm really happy I made it.

After a lot of testing, I've found a situation where the new logic was kind of detrimental, and I felt like it may not actually follow the players intention. When a corridor gets blocked by a dynamic entity (a player or the KREEP), the new logic actually "tries" to move the player in a different direction, like in the following situation:

2016_05_09_gif_51.gif?w=6302016_05_09_gif_6.gif?w=630

Here the player presses "Down" than a bit later "Left" in both cases, but in the second case another player blocks the corridor. Since "Down" is still pressed, due to the new logic, the player starts to move downwards as there is nothing in the way. I felt like in most cases this could be counter intuitive, since the player usually tries to move towards these "dynamic blockers" (due to the game rules this is the most logical goal), so I introduced some extra code, which separates dynamic and static blockers (collidable map tiles) and handles dynamically blocked tiles just as much "preferred" as walkable tiles, so that only the button-press time-stamp makes the difference in these cases. Again this worked like a charm, but all-in-all it is pretty ugly and "duct-taped" (so no pseudo code this time :rolleyes:) + the whole thing took a long time to experiment, implement and test thoroughly.

What I'm still fiddling with, but is not going to be in the upcoming Steam release, is the second issue from the original "perceived" control problems: pressing the intended direction too late. This is much trickier and it is much more a player fault than the first one, but can be helped a little with an "input window". For one or two frames, you buffer specific situations where different input state would have ended in a different direction. Than later you reposition the player, if still possible / makes sense, and it is much more likely, that the given direction is only a late press (e.g.: in the new position it would be blocked by a wall and no other directions are pressed at the current "late" frame). Most probably in these situations a one or two frame continuation in the same direction will not be noticeable by players, but will extinguish almost all late-press annoyances. Here it is, a little animation showing the inner workings of the "input window" algorithm in action:

2016_05_09_gif_7_1.gif?w=6302016_05_09_gif_7_2.gif?w=630

In the GIF there is a one frame "window" represented. This frame in which the decision and reposition happens is "frozen" for a tad bit so the choice is clearly visible. The second GIF shows the animation sped up to the same level as the characters move in the game. Even on this GIF with rectangles and lines, the one frame "window" and repositioning is barely visible so I have high hopes, but the implementation is tricky, so it's going to take some time + I'm already in a "I really want to release this game on Steam" mood :)!

Overall working on this problem was a wonderful experience, because it taught me how much difference good input handling makes (input IS king :wink:), and that it is worth putting energy into seemingly miniscule issues/ideas too, since they may end up awarding huge benefits (+ I F'ING LOVE GAME DEVELOPMENT :D).

I'm planning to release the update in two separate turns. First giving it out to those who already bought the game on itch.io and IndieGameStand within a week or two, than releasing the game on Steam a week or two afterwards.

Sorry for the long write again, stay tuned for more :wink:!
Best regards.

Spidi

Hi everyone!

I took my time again to make this new post, but I was really occupied with life and stuff and took approximately two weeks off from work (got married <3 + been pretty sick for a week :( ). Last week was only spent on polish and adding "extra" features, so it is only a matter of a few weeks to finally tackle this beast of a game :) , I'm almost at the end of this marathon!

I'm also trying a new vlog format this time, with more video content and less slides. It is a video log after all :wink: ...
I hope you all will like it.

 

Map generator tricks

I extended the implementation of my "semi-procedural" map generator algorithm with a neat and simple trick. It is working from hand authored map templates, so I added the possibility to randomly flip over the vertical and/or horizontal axes!

large.2017_07_15_Generator_Flip.png.6af3

For the 4 resulting maps on that screen the exact same handmade tile-map template was used. This results in 2 to 4 (if you can use both axes) times the possibilities of slightly different generated maps for the same amount of hand made maps :wink: .

Dungeon progression

Each level type has a unique name now :) + when you enter a level you get a notification about where you are in the dungeon/story:

large.2017_08_06_Screenshot_1.png.d8e7d3

I'm still not 100% satisfied with this level change pacing/effect. I may add a really tiny "to black-screen and back" transition effect too. I'll try it out and see whether it works better...

Speech bubbles

These fancy text graphics are pretty useful for delivering help notifications, narrator or character speeches and to convey more details about the world to the players.

large.2017_07_20_GIF_1.gif.6e519a663ac29

I also implemented some features to make them easier to control and more readable:

  • New ones can optionally "cancel out" old ones (request them to start fading out), or can simply be played alongside the existing ones (conversation).
  • New ones are automatically overlaid on top of the existing ones.

large.2017_07_20_GIF_2.gif.5fc4276bf1834

Some conversations and player speeches will occur during the game-play too, not just in the "menu".

Polishing animations

The game has only static sprites, no hand-drawn or any key-frame based animations at all. So far I tried my best to move the sprites in a way, that make all the motions look fluid, but I always had plans to go further than that! I wanted to achieve a look, regardless of having no "proper" animations, that is interesting, at least a little bit.

I implemented an animated "stretch and squeeze" transformation for sprites and added a subtle one to the hitting obstacles/walls movement of the player character.

large.2017_07_29_GIF_Combined_1.gif.03c1

As the next step I added stretch, squeeze and shake to sprites at various points during battle.

large.2017_07_29_GIF_Combined_2.gif.f6f7

These GIFs have "New & Old" slides for comparison, but it's fun to check back how the game looked few months ago. Here goes the "same" battle from an early version:

2017_02_08_gif_1.gif

I'm really proud how much I could achieve with only "static" sprites :) .

I wanted to further enhance the user interface too, not only the in-game action, so I added a small and short "Back Out" ease to item pickup sprites to make them pop:

large.2017_07_31_GIF_Combined.gif.0369f0

I still have plans for more animation enhancements, but it is already August and I still have a lot of other tasks to take care about before releasing this game, so it most probably will have to suffice.

Collectibles

I integrated some systems into the game last week which I deemed "extra" previously, but as I mentioned around a month ago, I want to make the most out of this game, and completionist players (myself included :P:D ) are going to love this :wink: !

Now you can gather detailed information about the monsters and artifacts of the game. After several kills you can unlock a monster (weaker ones need more kills) and after a few pickups you can unlock an artifact (rare ones need less pickups).

large.2017_08_05_Screenshot_1.png.94c5a3

large.2017_08_05_Screenshot_2.png.be895b

There is an extra secret monster unlock too, which you have to look for carefully during a play-through, its hidden well :P . There will be more traditional achievements too, but they are currently in the design phase, so nothing to show yet.

I also ~finalized my "elevator pitch" for press/buyers:
I Am Overburdened, a silly roguelike with 20 inventory slots
Tell me what you think!

I'll be back in a week or two with more news on the game :wink: .

Thanks for reading!
Take care.

Spidi

Hi there!

Where was I for a month again and what’s up with the title?! Many friends already asked this and other difficult questions like “I planned to finish this game in 4 months and I’ve been working on it for 6 now” or “Last month you kind-of promised to have an open beta and a complete game by now” and the title was the best answer I gave. Actually I really believe in what I’m doing and the way I’m doing it. I know it is madness, game development is about risk management and this project is becoming more and more risky day by day (risk of losing a lot of money and losing the ability to continue full-time game making :( ).

The thing is the game was NOT GOOD two months ago. I could have rushed it to market, I really could, but my ghost whispered to me and I had to follow its lead. I’m in this for the love of it and for the love of the craft as a whole. I want to make games and continue making games as a living, but at the same time I want to be good at it and be proud of what I make.

Now with this out of the way let’s jump onto the progress in the last four weeks :) !

Polish

Few people said to me, based on my last entry, that the game starts to look really polished. I felt really happy about that, because I haven’t actually started on my planned polishing tasks. Besides composing the sound track and working on finalizing and balancing game systems, the last few weeks were spent on polishing the look and feel of the game :) .

Movement

First I added some sprite effects to the player movement which fades out over time. This is a great visual cue to show the direction and the old positions of the player and also makes the “dusty & old” dungeon image more believable :) .

2017_06_20_gif_1

Then a subtle bounce was put on top of the original player movement transition. It does not seem like a big addition but it does make it feel more like walking than the old moon-walker dance move :D .

2017_06_20_gif_2

The last movement tweak was configurable sprite and sound effects for levels. Now there is splashing in the caverns instead of dust puffs as an example.

2017_07_11_gif_1

Animated health-bar

This is something which is absolutely not a necessity for a game, but once you saw the Diablo 3 health globe it cannot be unseen :D . Back to reality. I wanted to add a subtle sliding animation to better signal the player about the significance of the health change. I think it turned out wondrous :) !

2017_06_19_gif_combined

Ambiance

One nice touch I really like is atmospheric sound effects. In many games if you mute the music you can easily hear a lot of background effects which do not come from entities in the world but from the environment itself. Examples include crackling fire, rats squeaking, stuff like that. I Am Overburdened is not a gothic themed nor a horror game, far from it actually, but I wanted to achieve a “spooky” overall feeling so I added something similar. Dripping water in the caves, rattling chains in the dungeons etc…

Dripping.ogg

Chains.ogg

Monster skills

This was a feature which was missing from the game for so long. I actually implemented the underlying system while working on the prototype (so really really long ago), but I had no time to actually add unique skills to the monsters :( . Now each and every one has it’s own “thing” which makes them memorable and really stand out. Not just attribute differentiation, like :o careful this one is “strong”, this one is “fast”, bla bla, but instead something like this: careful this can dodge your attacks, or that one can interrupt you and cancel your hit, or that pesky beast can resurrect so it is a real damage sponge!

2017_07_11_gif_combined

There are some neat ones which I will not spoil because they are really fun, powerful and buy the game once it’s out :P (there is no fun in spoiling everything) !

The Black Raven Market

During a play-testing round I realized there is a huge problem with the pacing of the game. The game-play did not change enough during a full play-through regardless of the changing environments, monsters and increasing power levels. Another problem a lengthy game usually had is RNG (those infuriating random numbers :D ). It felt a little boring and a bit too random (not enough control over the outcome). I realized a shop could solve these issues, but not a typical buy whatever you want when ever you want type, but more like a rogue-like shop ;) , that allows more player control but it also presents another hard choice (as many things in rogue-likes).

2017_06_09_shop

Welcome to the Black Raven Market. Every first shop level sells random pickups (health potions, attributes etc…) and every second shop level sells random magic items, but you can only buy one stuff on each level! I’m evil, I know it :D MUWHAHA. In a full play-through you will encounter 10 shop levels which gives some extra space for player choice and nicely breaks up the “kill some monsters defending important loot and run to the next level” game-play loop.

Music makes the world go around!

I’m not a musician and the following sneak-peek into the official soundtrack of the game is proof of that. Regardless of it being pretty amateurish I’m still really proud of it :) . Instead of trying to make AWESOME music (which I simply can’t :( ) I focused on adhering to some fundamentals I settled on before jumping onto composing:

  • Retro sound, match the looks of the game.
  • Leave a spooky and mysterious impression.
  • Be consistent using similar patterns and tunes.
  • Gradually get more intense and chaotic.

I hope it isn’t grating at least :| .

The full OST is around 15 minutes so its my longest work in this regard yet + it is long and varies enough to not get too repetitive during a full play-through :) .

I should also mention, that I used the wonderful Bosca Ceoil tool for composing. It’s quite limited, but it is really really easy to use. You should definitely check it out if you would like to make some chip tunes. It is free and works in the browser too!

2017_07_11_bosca_ceoil

Thanks for reading!
Stay tuned.

Spidi

Hello everyone!

I've been pretty silent for a while again...
I really dislike this, because I'm usually open and post a lot about my progress, but sometimes it just slows down and I end up in a spiral of "awkwardness", when I'm not progressing too much and I really don't want to talk about that :mellow: .

Oh well, I'm preparing for the beta, some tiny fine-tuning left before I'm ready to upload a build, but before that, I share this update with a teaser.

Menus, menus everywhere!

I completed most of the menus. Some minor stuff (few more characters) are still missing but I will finish those during June. I included myself as the inn keeper :) . Interacting with the guy brings up the help screen and he also tells the "story" of the game in the teaser.

2017_05_24_menu.png

Your journal

I went for a journal look for the classic focus driven menus and your inventory. I think it turned out good looking and it fits the game well.

2017_05_31_menu_1.png

2017_05_31_menu_2.png

2017_05_31_menu_3.png

For item pickup notifications I made a fancy scroll too.

2017_05_31_menu_4.png

Animated box-art

While preparing the trailer and other marketing materials, I had this urge to animate something related to the game :) . The in-game sprites are all static and I wanted to keep it this way, so I made an animated box-art. Some say it's a better attention grabber on storefront pages :wink: .

boxart_animated_art_portrait.gif

Dungeon templates

I made a bunch of new dungeon templates for the generator. Not enough for the final build, but there are already plenty and they provide good variety for a full beta play-through.

2017_06_03_screenshot_1.png

Progress, balance

First balancing pass over the item, monster and pickup power levels is also done. Nothing major, but you can complete the full 30 level deep dungeon now, encountering a new set of monsters and a new tile-set after every 3 or 4 levels and generally fighting stronger enemies as you progress. It is going to take days of tweaking to make it engaging though. I'm planning to devote a full entry to this topic soon.

Teaser trailer teaser

Yes, the following is just a teaser for the teaser trailer :D , a sneak-peek so to say. I'm working on a lengthier one which showcases gameplay features too with music, flashy texts and everything one would expect from a proper game trailer. So this is just the first 20 seconds of the real teaser, but I thought I should share it in this form and ask for some feedback/opinions about it...

Thanks for reading!
Take care.

Spidi

Hi there, long time no see!

Last month was rather chaotic for me. After a lengthy Easter vacation a nasty flu forced me to spend almost a week in bed, and overall the progress on "I am overburdened" was dreadfully slow up until last week. That is why I had no energy and not much drive to write new posts or to create video log entries, but it is time to break the silence.

Really, no progress?

There was a lot actually, but the development entered its last stage where there are a zillion small tasks left to be done but no modifications are substantial. The notorious last 10% which takes 90% of the development time :D . I go through all the changes made during last month in a few sentences, than I'll adumbrate when and how am I planning to push this game through its finish line.

Monsters

I completed all the monsters from the easiest pawns up until the final boss. Their attributes are not balanced yet, but all their names, sprites and basic settings are done. Now each and every one has its own corpse graphic and unique sound effect too. This last bit was originally flagged as a nice-to-have addition, but after trying out the game with a few monsters having its own sound and carcass, there was no turning back :) .

gallery_228029_1183_64717.gif

gallery_228029_1183_10862.gif

Attack and skill effects

The battles and item skills were lacking visually, so I decided to apply some cosmetics. I Implemented a simple system to flash in and out various sprites at given coordinates in the dungeon on top of the entities. I was pleasantly surprised with the effectiveness of the initial results. Since than, I added configurable opacity easing- in and out and timings. Now item usage and battles are really shiny :o .

gallery_228029_1183_203004.gif

Notifications

Another set of crucial visual queues missing from the game were notifications. Many pickups and events yield varying results in a roguelike and yes a player can figure out how much gold was picked up, but it is so much nicer if the game helps a little with these, especially when important changes occur. Clearly when it does not fit the style its not necessary, but I am overburdened is not a "super serious" game. Of course these can be overdone, but I tried making them not too obtrusive. Both the effect system and the notification system is accessible by the item skills, so various "spells" can trigger these too.

gallery_228029_1183_42591.gif

gallery_228029_1183_383346.gif

Items, items, items

103 unique items, each and every one having a unique sprite. All the graphics are done with around 50% of the item lore finalized and it was a hell of a lot of work. Sadly something I underestimated again. Making the graphics was not difficult but coming up with unique, interesting or funny concepts, skills and short descriptions after having around 75 piece already, was tough. The last mile became a grueling, laborious crawl! When a lot of great content is already in place and almost every single archetype is taken, it becomes ridiculously hard to come up with new ideas hitting the same quality bar :( .

After all I think I achieved my goal in creating intriguing hand crafted loot what may serve as a strong hook for the game, so I'm proud of the end result. I don't want to spoil too much so I'll only show a small selection of sprites. Sorry, you have to play the game for more :) .

2017_05_09_items.png

Localization

In Operation KREEP I hard-coded some strings, rendering the game impossible to be fully localized without code modification. Some buyers actually asked about how they could do translations. I felt really ashamed while answering those mails :( . For I am overburdened I've built a system which allows to bind assets for specific cultures and all the strings are read from asset files too. There are no major limiting factors now, so technically the game could be localized to any language without modifying the application. I know some languages are super hard to handle, e.g.: right-to-left ones or the ones with huge glyph sets, but the point is, that it is feasible now.

Since I don't have the budget to pay for professional translations, only English and Hungarian will be done for release, but if the game does well, this is something, that is high on my list :wink: .

In-game UI

The user interface for the game is pretty much complete. Some finishing touches are missing here and there, but it is already pleasant looking and almost fully functional from the health-bar all the way to the item pickup pop-ups.

gallery_228029_1183_47643.png

gallery_228029_1183_2251.png

gallery_228029_1183_92258.png

The main menu

I dislike making menus because they are usually boring to design and program. For Operation KREEP I came up with the idea of creating a "screen in the screen" look, to make it more interesting and alleviate this feeling while working on it. You navigated the menus of a retro-looking computer and the whole frame of the machine was drawn. It blitted the maps on the level selection screen in awful 4 colors and all the cozy stuff like that :) . It worked for me and for the game too.

I tried a non-traditional approach again, but menus are still boring :D . Since it is a classic trope to have a city in action RPG-s and roguelikes where you return to from time-to-time, I thought about including one in I am overburdened. The idea did not align well with its mechanics, so I decided to make it the main menu! You move around in an inn, interacting with people and objects there to enter specific parts of the game. Talking with the inn-keeper lands you on a help screen, poking a bookshelf shows the settings, leaving the inn exits the game and the trap-door starts the actual dungeon crawling... If a player gets lost, escape will bring-up an ordinary focus driven menu. It is far from complete, but the skeleton is there and some parts already work.

2017_04_05_inn.png

2017_05_09_menu1.png

Open beta, plans

I've been talking about this open version thingy for ages and I still haven't released it. In my original plans I wanted to have the full game completed by now :( . For the most part it is, but some planned content and finalization (+polish) is missing. There comes a time when I have to say stop and I think it is here, so from now on I will only focus on wrapping the whole thing up and this starts with putting out a beta version. Will prepare some marketing materials beforehand, like store page graphics and texts, maybe even a teaser trailer, so it may take a few days, but will share a download link for it in the next post :) :wink: !

Stay tuned.

Spidi

Hello everyone!

Tiny post with lot of pics this time. Last week I worked on the original sprites of the game and progressed steadily. Far from finished with every piece but a huge portion is done!

Missing pieces

In the last log I showcased the tile graphics, but one final adjustment was missing back then. All the tile-sets shared a single stair sprite which wasn't fitting well, so I made a separate sprite for each one.

2017_03_29_stairs.png

Entity sprites

The next stop was entities. I started out with defining clear goals for the looks and creating a palette serving these goals. The idea was to select contrasting, vivid colors to make entities pop from the environment and on contrary to the looks of the dungeons make them lively (browns and yellows are still pretty strong still :D )!

2017_04_03_palette1.png
Not yet finalized!

Player

I really liked the design I came up with before for the player character so I reused my concept which was a failed attempt at the box art of the game. Two sprite states exists, since in the planned "story" scenes the player will have his sword in its scabbard.

2017_04_03_gif_1.gif

Chests

The first apparent visual choice here are the light borders. I decided to add a colored one to every interactive entity type, so the player can not miss which tiles poses a threat and which ones provide bonuses. I made four chests with various costs/functions but I'm keeping the last one as a secret for the final version :wink: .

2017_03_30_gif_1.gif

Pickups

Pickups come in many flavors. Permanent attribute bonuses (Meat = +Strength, Frying pan = +Armor, Carrot = +Vitality, Coffee = +Speed, Clover = +Luck), gold, potions, random items etc... Here are a few:

2017_03_31_gif_1.gif

2017_03_31_gif_2.gif

Monsters

I settled on a style after a few tries where the monsters are pictured from the same angle as the player. I plan to have around 15-20 unique monsters and a boss, which will provide a good variety for the 30 dungeon levels. They were divided into four groups based on the story when designing the looks: were/giant animals, goblinoids, undead and the allies of the boss. Almost all of them is ready (currently at 16).

2017_04_01_gif_1.gif

2017_04_01_gif_2.gif

Some screenshots from the current version of the game:

2017_04_01_screenshot_1.png

2017_04_01_screenshot_2.png

2017_04_01_screenshot_3.png

This week will be spent on completing the missing sprites (e.g.: items, some monsters) and overall visual improvements and polish, so I'm guessing the next entry will be similar. A kind-of "news" is my plans for an alpha demo. Before I complete and release the game I really want to do a open build (which will become the demo later) to gather feedback. I think wrapping this version up sometime next week is perfectly viable, so by the end of this week I'll post a finished plan for this too.

Thanks for reading.
Take care.

Spidi

Hi there!

Short entry, a bit tutorial-ish, about the tile graphics of the game.

Art direction, ideas

I really liked the style of the open art assets I used for prototyping. Pixel art, huge value differences between the wall and the floor tiles and a little noise to make it a little grimy & wrecked.

2017_02_04_screenshot_1.png

Though I liked it's looks and simplicity, I wanted to try some other ideas before settling on anything so I went ahead and made mockups.

False positive

The most interesting and furthest developed one was a tile-set and look with an oblique top-down view effect. I think this looks really good in many games, but sometimes it can get too exaggerated covering too much of the entity sprites.

2017_03_26_mockup.png

I came up with this, but I decided to scrap the idea. I liked it sort-of, but making multiple varied sets for the 30 to 60 minute long campaign and fully fleshing them out in this style would require and immense amount of work. I choose the original simple style with a decent amount of variation instead.

Goals, final looks

So I returned to the looks of the prototype. Easily distinguishable wall and floor tiles, noisy and grimy places (it is an old dungeon after all) and good variations (many sets and small randomization within each set too) so it does not become boring during a full play-through. I needed a cool palette. Something murky. While picking colors I naturally deviated towards the looks of a game I always cherished for its atmosphere :) .

2017_03_26_quake.png

Colors were picked carefully for supporting the look of the entity sprites, as they will use a marginally different palette full of contrasting colors instead of saturated ones to make them pop from the terrain (again just like in the prototype).

Here goes some shots about the results:

2017_03_21_screenshot_1.png

2017_03_26_screenshot_1.png

2017_03_26_screenshot_2.png

I have 10 different tile sets ready which I suspect will provide a good variety :) . With 30-ish level deep dungeons a set change will happen after every 3 levels.

How-to?

For creating a lot of pixel art tiles, like the ones I made, you are going to need a frame so to say. Some rules and patterns how you start pixeling each tile and afterwards patience for experimentation. That is all to it actually. I walk through the creation of one.

I use GIMP, a free and cross-platform image editor, but pixel art can be done just as well in a lot of paint programs (even in paint, but I advise you to choose a better one which supports layers). A graphics tool which can work with tiles or a hot-reload engine feature (because GIMP as an example does not support tile graphics) also helps, since you can check while you are drawing, whether your graphics work well when tiled instantly.

2017_03_26_gimp.png

First I usually start with selecting values for the whole set. This is a handy technique for defining an overall lightness/darkness balance for each tile.
2017_03_26_tile_values.png

Than I "sketch" a simple pattern for a tile using the values, usually with a light-source residing in a North-West direction.
2017_03_26_tile_pattern.png

I add a little variation, like cracks, missing bricks, mixing up the pattern etc... Detail like wines or stains can be added after coloring is done but this step alone makes enough differences between tiles.
2017_03_26_tile_detail.png

I know simply selecting the same hue for the given values feels easy, but it makes the outcome look kind-of boring. Try to make colors interesting by selecting at least two different hues and by playing with saturation a little. It will make a huge difference!
2017_03_26_tile_colors.png

Now you have a nice looking tile. The next step is optional. Adding noise was a deliberate style choice in my case. You simply add an extra set of values with only slight changes relative to the originally used ones. Select the noise colors the same way as the "normal" colors. Generate a noise pattern and overlay the noise colors on top of the tile using it as a mask.
2017_03_26_tile_noise.png

A screenshot with the final tiles:
2017_03_26_screenshot_3.png

Thanks for reading.
Stay tuned!

Spidi

Hi everyone!

Haven't written for months now about Operation KREEP. It is time to revisit this old buddy bud bud of mine!
Yes, as the title suggest, it is cross-platform time :wink: ...

2017_03_23_boxartmultiplatform.png

Not official, but soon...

Nope, sadly no official release yet :( , but the Linux build is ready and tested (at least on my Nix machines) and the MAC build is ready for testing too. This means, that in a week or two an official release can happen, although a little piece of the puzzle is missing.

I require additional pylons!

I have two PCs, so I tested the Linux version of the game on two Ubuntu versions, but more would be nice (zillion distros :( ) + I HAVE NO MAC MACHINE :( ...
This means, that the MAC build essentially never ever been started! I would really love to release the cross-platform builds, players already asked for them, but without sufficient testing it is not going to happen. Buying a MAC would be a somewhat logical investment at this point, but Operation KREEP (and my whole game development venture for that matter) is on an extremely tight budget as it is not profitable so far, so I will try to postpone that a little.

Feedback, results, "compensation"

Based on the differences between the builds (almost 0 code change, only packaging varies), I think a few simple checks would suffice. Whether installation works (files copied, icons set etc...), whether the game starts and basic configuration settings checks (settings work and are saved to correct application data folders) + a short test play round just for fun :wink: .

I know it is shady to ask for free QA for a product, but this is the reality of the situation I'm in :| . If you would like to help out I thought about sharing a limited amount of Steam/itch.io/IndieGameStand keys for the full game as a "payment".

I put together a short form to ease reporting results: KREEP, apples and penguins
If you dislike sharing any personal information, but still would like to help out, please simply post results as comments here or contact me by e-mail: [email="spidi@magicitemtech.com?subject=KREEP,%20apples%20and%20penguins"]spidi@magicitemtech.com[/email]

I guess contact info of a cheap&used MAC reseller in Hungary could help too if you know any :) .

Demo builds

2017_03_24_logo_mac.png 2017_03_24_logo_nix.png

Porting tech stuff

Just a little tech talk as closing words. The windows version of the game was made in C# using XNA. Two really cool projects were born to both preserve and enhance XNA in the last few years. MonoGame and FNA. Both are great and well established/tested at this point, but I choose FNA for porting Operation KREEP to Linux and MAC. My reasoning was the following:


  • Around a year or two ago when I was using MonoGame to work on my Linux machines I encountered some difficulties. MonoGame on Nix platform was using OpenTK for window, input and OpenGL context management and as I know, that library had it's fair share of bugs and there was no real support/contribution/fixes for it for a long while.

    Remark: as I know the MonoGame team changed to SDL2 lately, the same library FNA uses under the hood so it is probably not the case by now.

  • MonoGame favors a per-platform build approach, which looking at all the possible target platforms (desktop, mobile, consoles) is a logical choice, but requires managing and building multiple executables for each target. FNA from the get go approached this with a common desktop runtime, so one build works on all major desktop platforms (only packaging has to be taken care of per target).

    Remark: if I'm not mistaken, last year a "common desktop" build was introduced for MonoGame too, so technically it could work the same way as FNA for desktop.

  • The FNA developer Ethan Lee had laser focus on cross-platform desktop XNA development and delivery, and the wiki for FNA had a really nice documentation about both working with FNA (differences and extras compared to XNA) and packaging + delivering games using it for Windows, MAC OS X and Linux. This documentation seemed really helpful and complete.
    All in all I suspect both libraries could work perfectly for publishing your games to the three major desktop platforms, but I wanted to give FNA a try too. I was pleasantly surprised, most things worked like a snap without much fiddling.

    That is it for today, in a few days I'll post a new video & blog entry for I am overburdened. If you decide to help MUCH LOVE, SUCH WOW :) and thanks awfully!

    Take care!

Spidi

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.jpeg

I continued with flashing out this character with a composition I thought I like:
2017_03_06_boxart_11.jpeg

2017_03_06_boxart_21.jpeg

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.png

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

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 :D .
2017_03_21_lineart_2.png

Then I throw together a "placeholder" pixel art title text.
header.png

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.png

2017_03_21_attempt_2.png

2017_03_21_attempt_3.png
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.png

I came up with the following concept afterwards which I really liked:
2017_03_21_concept_2.jpeg

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.png

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.png

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.png

Stay tuned!

Spidi

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 :wink: .

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 :D 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 :wink: ) 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.jpg

2017_03_02_foam_21.jpg

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.png

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.png

    2017_03_02_effects_2.png

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

    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.png

    2017_03_02_freesound.png

    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.png

    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:


    • Without any runtime modifications: Walk_Normal.wav
    • With dynamic random pitch modifications: Walk_Random.wav
      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!

Spidi

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 :wink: ! 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.png
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.gif?w=240&h=192

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:
1 2 3 4 5
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 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_11.gif?w=240&h=192

      2017_02_20_gif_2.gif?w=240&h=192

      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:

      Forearms Vambraces Item22 1 1 InflictDamage true 20 Boneless

      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.png?w=480&h=882
      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 :wink: !

      Stay tuned!

Spidi

Hi there!

Small update this time. Been working on wrapping up all the remaining core features, but got a bit sidetracked so I'm going to write a little about level editing too besides monsters + I'm trying out yet another video setup.

This video is the most condensed so far, focusing exclusively on last week's development and showcasing gameplay features. I thought making a third video using this form will result in a diverse and easily comparable set and will help to draw my final conclusions about the series.

So it is short (3 minutes), maximally to the point and heavily "scripted" :) :

Monsters

gallery_228029_1183_219008.gif

During this week, I pretty much completed all the logic related to the monsters of the game. From their type description (sprites, attributes, inventory?! :o :) :P , database of monster types etc...), all the way to battling with them. Also filled the game with a bunch of placeholder monster sprites/types to test it out, and now it feels like a real rogue-like with character advancement, treasures and risk of death :) .

Battle system

Once you try to move to a tile occupied by a monster a "battle" starts. Both entities will take their turns to attack, the faster one (speed attribute) will start or it will be decided with luck trials if there is a match. If both contestants survive the first attack the slower/unlucky entity strikes back, and shortly after the player gets back input control.

Levels and modding

Official mod support is sadly out of the scope of this project, but I still managed to come up with a clean solution for a "half-offical" way :) . Since all the configuration files (monster/pickup/chest types, starting attributes, spawn profiles, item skills) will be shipped as plain XML files, huge part of the game can be tweaked with a plain old text editor, but for a pleasant level editing experience that will not suffice...

Tiled

2017_02_11_tiled_1.png?w=170&h=92

gallery_228029_1183_9523.png

I decided to ship the game with built-in support for the Tiled editor. Now the game can read plain tmx files. Never made a run-time parser for it before, but I used this editor multiple times so it was a natural choice. The final package will also feature a pre-built tile set for Tiled map files (placeholder one pictured) and a written guide on specific map properties related to the game.

gallery_228029_1183_7500.png

By the next entry I will have all the missing bits and pieces of the game-play loop implemented (difficulty management and item skills) and the game will be pretty much fully playable albeit lacking content or balance. As always, open for questions, comments and critique.

Take care!

Spidi

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 :mellow: ...

    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 :D . 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

      gallery_228029_1183_8766.gif

      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

        gallery_228029_1183_9199.gif

        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

        gallery_228029_1183_24763.gif

        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

        gallery_228029_1183_2103.gif

        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.

        gallery_228029_1183_12436.png

        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!

Spidi

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_numbers.png?w=820&h=432

    Current 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 :D :P . 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!
      gallery_228029_1183_13352.png?w=480&h=270


      gallery_228029_1183_63591.png?w=480&h=270

      gallery_228029_1183_31193.png?w=480&h=270

      gallery_228029_1183_12203.png?w=480&h=270

      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.png?w=150&h=46

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

Spidi

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 :D ).

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 :D . 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.jpg?w=1024&h=575

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. 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 :mellow: ). 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 :P ). 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.jpg?w=400&h=200

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 :D :( , but slowly getting there.

2017_01_11_linux_1.png?w=480&h=2702017_01_11_linux_2.png?w=480&h=270

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 :D ). Thankfully I realized the horrible mistake I've done and I can act upon it now.

2017_01_11_estimations.png?w=768&h=333

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 :P . 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 :P , be sure to subscribe ;) .
logo_16_91.png?w=768&h=432

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!

Spidi

Hi there!

The last two weeks were full of bad luck (health issues, disapproval from Valve, visit at a local veterinarian all kinds of things :( ), and as a result my productivity approached zero. Actually it did reach it when it comes to Unified Theory my upcoming game, but thankfully I could pull myself together to complete and release the 1.2 update for Operation KREEP.

The 1.2 update:

I've written a lengthy post about the contents and details of this update and not much has changed on this front, but I made some extra fluff for the game since.

A new box art kind-a thingy:
gallery_228029_978_8053.png

A new announcement trailer for the update:

I added trading cards to the steam build as it was mentioned (and requested) by many as a good value addition for steam games, because many players go crazy for collecting them. It was not a big deal to create them, but took surprisingly many tries to get every related content right and up for the requested quality bar (though descriptions and requirement docs. were decent).
gallery_228029_978_92067.png

The game itself hasn't been modified much. I found a few minor bugs and fixed them, some were new ones related to the new fine-tunings and modifications, few were old ones hiding for a while now, but nothing major. And as a last minute unmissable colossal modification which happens with every single software close to a dead-line :D , I enhanced the input buffering capabilities of the game and successfully incorporated a "buffered direction change tap" detection logic to make "tile lane changing maneuvers" possible. Seems to be working well, made the keyboard and dpad controls even more responsive and pleasant. It isn't actually that complicated, but sort-of interesting (I guess :mellow: ), so I'm thinking about writing a short post dedicated to the topic instead of delivering an inadequate explanation now.

I'm currently trying to promote the update and the game (press, youtubers, streamers etc...), but probably it isn't going to yield much results. I mentioned before this is not a big deal, I consider this an "experiment", so even if it does not show any return, the update was a rather small one to begin with.

Soon I'm going to have all my time devoted to my next game.

Next stop is the finalized look and the alpha release of Unified Theory which I've been neglecting for far too long now.
Stay tuned!

Spidi

KREEP, designing an update.

Hello everyone.

As I mentioned last time, I decided to do a small update for Operation KREEP and to change the "scenery" a little, last week I took a little more than two days off from the development of Unified Theory and made it happen. Thankfully my estimations were correct and the updated builds are ready to be delivered to various stores (and yes it is indeed a tiny update only). Preparing all the marketing materials for this update (trailer, announcement texts etc...) is going to take a few days so I'm guesstimating, the release will happen somewhere around this weekend or early next week. Until than, I'm going to continue working on the Alpha build of Unified Theory too parallel since I've made significant progress on the visual presentation of it in the last couple of days (a post with fancy pictures coming in a few days :wink: ), but the focus currently is definitely the "marketing experiment" of the KREEP 1.2 update.

This time I'm going to dive into the technical details of the update, its design and the reasons why I decided to create it even though imposing serious time and scope constraints on myself.

Level design

The 1.0 version of Operation KREEP featured 13 levels and the 1.1 update increased it to 17 arenas. With this update I'm bumping that number up to 20, so adding in 3 extra. Even though this sounds like a relatively small number, from the beginning I went for quality over quantity with the design of the maps. My goal was to make both mechanically and visually distinctive levels delivering the possibility of varying tactics and play-styles on a per-level basis. Adhering to this goal made each consecutive level harder and harder to design and thanks to it I made various mistakes too, but I think I succeeded and with this update I'm also delivering refinements and fixes to the old levels.
gallery_228029_978_17372.png
Just look at the first few levels how blunt and simple they were, but the overall picture is vivid, lively and seems to be full of surprises and varied tactics :) .

A little about the level fixes:
The most common mistake I discovered is choke-points and too enclosed larger rooms "favoring" the KREEP. If the players get close to defeating the KREEP but it ends up within a larger room with low number of entry points, it becomes close to impossible to purge it. There is a "solution" where the players let the KREEP spread out of the room/choke-point and can destroy it more easily when it is spread thin, but obviously this was a mistake from my side either by not making this obvious to the players or by allowing a situation like this to happen...
Here is an example of where the map named "Vessel" was modified to be more fair (sometimes less obtrusive modifications were enough tough):
gallery_228029_978_5852.png
6 previous maps were modified with various fixes while making the 1.2 update.

Fine-tuning

A couple of small modification got into the update related to accessibility and difficulty. These are changes which are not immediately obvious or visible for the end user but they do make the game better, more balanced and a much less hassle to play (e.g.: UI streamlining). A short list of what this covers:


  • Two new options on the "game-over" screen. Previously you could restart the match on the same level, with the same player setup and the same mutators (rule settings), or you could go back to the main menu to start a new match with a different setup. Now the new options allow to keep the player setup (because in a couch co-op you usually play with the same number of people after you first configured) and change the mutators or the level too for the upcoming match.
  • I modified the KREEP power levels just a tiny little, to make the last couple of seconds of a match even more easier/harder based on the outcome, so if the players are close to victory it is now easier to score, and if the KREEP is close to eat the whole map it becomes even faster.
  • I tried to make the "sudden death" mechanic play a bigger role in the game because I discovered, that some plays end up in a quasi stalemate situation, where players can not kill the KREEP effectively enough to destroy it (due to a lack of good tactic or PvP). Previously the KREEP got a speed/power boost when it reached 60% occupation of the level, but these stalemate situations kept the KREEP size just under it for long minutes easily, so I introduced a 2.5 minute timer to boost the speed/power regardless of the KREEP size, so a "stuck" situation will result in KREEP victory (yep I'm evil) instead of a long, grueling and probably boring match. I'm not really afraid of the negative implications of this modification since most matches tend to be between 0.5 to 1.0 minute and I feel 2.0 minutes is already a pretty lengthy play in this game (it is pretty intense and action packed). Of course the "No Sudden Death" mutator setting will disable this timer too!


    Marketing

    I talked multiple times about this update being a "marketing experiment". This means I'm going try to promote the game (or this update + the game) with close to as much time investment as with the Steam release. Besides the usual key mailing, I will try some new stuff too, focusing on the dark humor within it (funny poster, new logo/splash screen and Steam trading cards!). If it does not yield good returns it will not be a devastating blow on me, since both the update and the pr + marketing effort totals not much more than a week worth of work, so it is no biggie, but I really wanted to give a little more love + chance for the game to succeed, hence the phrase.

    P.S.
    While I was testing the new levels, my fiancee found one of the test cases fun to look at so I decided to record it as a bonus for this entry, because it is indeed fun to watch the KREEP sped up overtaking the levels :D . Enjoy:

    Br. and take care!

Spidi

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!

Spidi

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 :lol: ...

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:

gallery_228029_1135_36954.png

gallery_228029_1135_88909.png

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!

Spidi

Haven't written in a while about what is up with Operation KREEP or my next game, not even game-tech related posts, and I think it needs a little explanation ( at least me, myself, are in desperate need of some honesty towards myself :().
After I finish my rambling about "life and stuff", there will be some tech talk too in the topic because I dislike not showing anything fancy, so if you are only interested in that part, scroll down a couple paragraphs :wink:.

So why isn't the next game announced, I've already mentioned it twice before, that it is close to being playable, and in the upcoming weeks I may even distribute an open alpha build...
It is still not ready for that (no kidding :mellow: ?!).
The last month was somewhat "wasted" from a gamedev perspective. Wasted is a harsh word for it, but the truth is I feel a bit ashamed of how the last few weeks played out (development wise), so it kind-of fits. Instead of mostly spending my time with the development of the new game, I've mostly spent my time with "engine-tech". The worst part is, that it got a tiny bit out of control, since if I'm going to be really honest with myself, at least a week worth of development was 100% unnecessary for this upcoming game.

A little back-story:



As many of you may already know, I'm developing my games using C# and the framework of my choice is XNA/MonoGame. This goes way back in time (almost 10 years): Unity did not exist and XNA was a hot new tech (in BETA or 1.0 which was extremely bare-bones can't remember) when I started learning programing (University + the ultimate purpose of being able to make GAMES!!! :D). Back than it was a natural choice and worked wondrously. Fast forward to today and MonoGame is still a great choice, if you have professional programing experience (or want to learn programing) and you are ready for some game-system/engine development compared to Unity, but for a more complex game, lots of stuff has to be coded (no physics, no advanced rendering system, no UI system etc...).
I actually like this level, I feel comfy working this way + I've been building and growing my own "framework" (or whatever it should be called) on top of XNA/MonoGame for years now. I have a keen eye for software quality and I'm especially proud of it's feature level and stability, and I'm really productive when using it to develop a game.
I think, that last one (productivity) is the most important part when it comes to "choice" regarding your language/framework/engine/tech!
But, and here comes the BIG BUT:
It is still only a light-weight game development framework. Not, that there is a problem with that :), but if I would take the time to get proficient in Unity, most probably I could be just as much, or even more productive, especially looking at the current situation when I go in to game-tech feature creep craze :(.

Nowadays, I'm trying to make more out of working on games (living / business), so this becomes an increasingly important question, whether my time is spent well working on this framework. The answer is probably no, but my current level of productivity and emotional attachment (I don't know what else to call years of hobby development :mellow:), keeps me working on it. Of course I have more rational reasons than that, but the post would be humongous and it is already big :D. From now on, I have to be brutally honest with myself when it comes to this question and be more self-aware when it comes to tech development decisions.

A little more detail about the current project/situation:



I wanted to upgrade my testing framework for this upcoming project which went surprisingly well and happened pretty fast, but this game I started working on required numerous other features which were lacking from the framework too. I decided, that I'm going to spend approximately two weeks on development of these features in isolation, not really jumping into coding the game beforehand (just only the basics), so I can focus on delivering clean and stable code for starting production.
This became four weeks, due to various "common" reasons: underestimation (only a little), forgotten pretty important framework related developments (these were not even estimated in my backlog :() and a week amount of feature creep.
The only conclusion here is the same I mentioned before, I need to re-think how much energy I pour into this code-base, and whether it is going to be "worth it".
Now, that I have everything in place (and got out of this spiraling feature-creep menace), the development of the game is advancing, but it is still far from a presentable state :(.

Here comes the technical part, what I've been working (wasting my time) on:



The major part of the tech development was a proper UI/Widgets system. For Operation KREEP I used a simple approach, where each UI element was a simple graphic object positioned relative to it's parent UI element. Nothing fancy just a simple base class with a position and an attachable graphic (e.g.: sprite, text etc...) arranged in a tree-like hierarchy, lean and clean.
No built-in serialization logic, no scaling, no anchoring, no alignments, no padding or margins, even mouse input handling and a good event system was missing! For the most part it was OK for KREEP (not much UI and pretty simple), but it was certainly an insufficient solution, and a lot of stuff had to be done in the project code-base and hard-coded while working with it. Yep, pretty ugly :(.

The current strategy game I'm working on is much more UI heavy and will have a pretty different look (not pixel graphics + different resolutions), so the before mentioned "problems" had to be resolved. I heavily extended the old system, and implemented a two-pass layout engine (measure the elements of the hierarchy first, than arrange them based on their requested size), with some fancy additions (e.g.: nine-patch sprites).

This is how it looks now:
2016_08_09_widgets_uml.png?w=1050



And, than it hit me, I forgot about auto-tiling :(...

Yep, I pretty much forgot to estimate and put this feature into my backlog when designing the game. And no, it is not some fancy tooling stuff, which I don't really require, but plays a kind-of an important role in the game. It plays a big role in the looks of it, which IS important, so I had to implement a run-time auto-tiling feature. This is how it looks in action:

It only handles one type of surrounding tiles (supporting multiple ones is ridiculously difficult + the game did not need it) and supports both four-way and eight-way rule sets.

And, while working on auto-tiling I made a performance bug...

It was a mistake I did not discover while testing my code. The internal data-structures were handled incorrectly, and with an imperfect stop condition, from time-to-time the auto-tiling took more milliseconds than a frame should at 60 fps, so I sat down to hunt for the reason of these frame-spikes. Needless to say, that I already had a vague idea how to approach the problem and where to look + an existing .NET profiler would have revealed the exact issue in mere minutes (if not seconds), but somehow I felt this is the sign of the "NEED" for a visual profiler (I don't know what pills I took that morning :wacko:).
I was already way out of my frame-work development time budget but still the creep emerged from the dark depths of the unknown and engulfed me. I took the time (few days) to develop my own visual profiler integrated into the framework...
Cthulhu_and_R%27lyeh.jpg?w=220&h=300
This is how I imagine that mental state from now on. I can't exactly remember or picture it, so this will do :).

After this point, I'm still not over the feature creep, but starting to grasp reality!
Took a couple more days to wake up from the refactoring madness too...

That is enough from the wall of shame of Spidi. Next week will finally be about my upcoming game.
Best regards.