I am overburdened, monsters and mods.

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

2017_02_11_gif_1

During this week, I pretty much completed all the logic related to the monsters of the game. From their type description (sprites, attributes, inventory?! ๐Ÿ˜ฎ ๐Ÿ™‚ ๐Ÿ˜› , 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

2017_02_11_tiled_2

I decided to ship the game with built-in support for the 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.

2017_02_11_screenshot_1

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!

I am overburdened, prototyping.

Hello everyone!

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

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

Blog

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

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

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

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

Progress

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

RPG layer

2017_02_02_gif_1

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

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

Pickups

2017_01_31_gif_1

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

Chests

2017_01_25_gif_1

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

Items and inventory

2017_02_02_gif_2

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

2017_02_04_screenshot_1

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

Stay tuned!

I am overburdened, begins.

Hi there!

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

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

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

The project.

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

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

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

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

The idea.

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

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

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

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

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

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

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

Magic Item Tech, persistent.

Hello everyone!

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

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

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

Last year, pros and cons

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

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

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

Operation KREEP

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

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

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

2017_01_11_indiegala

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

Unified Theory

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

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

2017_01_11_estimations

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

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

I’m overburdened

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

Website

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

logo_16_9

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

Stay tuned!

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.

Operation KREEP lane change maneuver 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.

Operation KREEP lane change maneuver input handling GIF

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

Operation KREEP missed lane change maneuver input handling 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.

Input buffering technique frame-by-frame depiction

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!

KREEP, tales of low productivity.

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:
Operation KREEP box art

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).
Operation KREEP Steam Trading Cards

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 ๐Ÿ˜€ , 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 ๐Ÿ˜ ), 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!

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 ๐Ÿ˜‰ ), 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.
Montage of all the maps in Operation KREEP 1.2
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):
Showcase of the map-fix of the
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 fiancรฉe 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 ๐Ÿ˜€ . Enjoy:

Br. and take care!