• entries
56
96
• views
52855

## I Am Overburdened, saving my soul

Certain item skills with persisting effects (e.g.: Fear, Cripple) could get stuck or be triggered on recently summoned/resurrected monsters in rare cases. These were not visible, but could affect how well you did, so my apologies for the occasional unfair (de-)buffs.
The positioning of hallucinations from toxicity effects (e.g.: Toad monsters, poison in potion) were not correctly randomized. These hallucinated monsters were always placed in the upper-left quarter of the map, breaking the illusion. Now this is fixed.
A while ago I added item-slot notifications to item pickups and chests when standing nearby. It did not occur to me though, that with this modification the treasury pickups and chests triggered unnecessary ones too. Oops, fixed!
In balance With this update balance tweaks found their way into the game too. There were still some complaints regarding this aspect, so I made normal mode a tad bit harder and nightmare difficulty a tiny bit more forgiving. These are not substantial changes, only slightly affecting the pickup and chest spawn rates. Another extra is “near death” detection. Simply put if you end up in a really bad situation at some point, the game tries not to punish you even harder on the next dungeon level These changes are subtle, so they keep the game challenging, but they were introduced to make it more fair at the same time. Boss confusion Some people found the boss level corpses confusing. I don’t know if the new version will work out better (this is not the first time I change this ), but now the number of corpses (below the one serving as the story hint) are tied to the unlock progress of the boss entry in the monster book. I know some other unlocks still need more and better hints too. I’m going to work on these problems in the near future… Am I still alive? Yes, pretty much. Due to personal and financial reasons I had to put full-time game development on hold for a long while, but I’m back now and I will be working on my projects in the upcoming months. Before I vanished from the face of the INTERNETZ I teased possible ports and a bigger content update for I Am Overburdened. These are not forgotten and progressing well In a week or two I will reveal more details about my plans. Until then, have a fun-filled time.
Thanks for reading and take care!

## Magic Item Tech, Summer Sale (Steam / itch.io)

Hi everyone!

Two Magic Item Tech games have joined the "Summer Sale" on Steam and itch.io

I Am Overburdened

The silly roguelike full of crazy artifacts and a "hero" who has 20 inventory slots, is 40% off so currently it's only 2.99$(may vary based on region, base price is 4.99$) !

You can buy it at Steam or at itch.io.

Go go go dungeon crawlers !!!

Operation KREEP

The best couch co-op multiplayer Alien satire action game, is 83% so currently it's only 0.50$(may vary based on region, base price is 2.99$) !!!
If you are a sucker for retro party games like Bomberman (Dyna Blaster) or Battle City make sure to give it a try!

You can buy it at Steam or at itch.io.

Remember:
In space no one can hear you KREEP...

I hope you check them out and they will be to your liking !

P.S.: Magic Item Tech also has a Steam developer page now. Feel free to follow me there to receive first hand news about my games, updates and sales.

Thanks for taking the time to read my post, have an awesome summer full of fun
Cheers!

## I Am Overburdened, tiny achievement

Drop me a comment or a mail! Thanks for reading my post and for your continued support.
Take care!

## Operation KREEP - Weeklong Summer Welcoming Co-op Sale

Hi everyone!

Operation KREEP, the best couch co-op multiplayer Alien satire action game, is 83% off for a week (only 0.50$😮 , may vary based on region, base price is 2.99$)!
If you are a sucker for retro games like Bomberman (Dyna Blaster) or Battle City make sure to give it a try!

There is also a demo if you want to see the game in action first:

If you are interested in the development process, my devblog and my website holds a great bunch of write-ups about how it was made:
https://magicitemtech.com/category/operation-kreep/

Remember:
In space no one can hear you KREEP... I hope you check it out and it will be to your liking !
Thanks for taking the time to read my post. Cheers!

Take care.

## I Am Overburdened, striving for balance

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 , 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.
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.
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.
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 . 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.
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. #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 . #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.

## KREEP, missed tap.

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. But being a short tap the button state may be released one or two frames early and usually the following happens: 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.
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, input is king!

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

## I Am Overburdened, light at the end of the tunnel

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

Stay tuned.

## I am Overburdened, what takes so long?!

Hello everyone! I've been pretty silent for a while again...
Take care.

## I am overburdened, check out the graphics!

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. 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 )!
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. 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: . 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: 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). Some screenshots from the current version of the game: 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.

## I am overburdened, miles of tiles

Than I "sketch" a simple pattern for a tile using the values, usually with a light-source residing in a North-West direction.
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.
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!
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.
A screenshot with the final tiles:
Stay tuned!

## KREEP, apples and penguins.

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

## I am overburdened, evolution of box-art

Hello there! Took most of last week off for vacation == no entries, sorry about that, but this week I'm going to make multiple videos and blog posts :) ! This first one is about the box-art of the game. Backstory, requirements For previous projects I did not spend too much energy on the promotional art. That was obviously a mistake, because usually it is the first thing both the players and the press comes across when checking your game, so it needs to have a good teaser, but it is easy to forget the importance of it and miss allocating time for it... I planned to make a difference this time, but I significantly underestimated the needed efforts :( . I wanted to capture the plot of the game in an image, suggesting the core mechanic, which is trying to collect a lot of loot and having a huge inventory, but still not being enough. All in all I think I succeeded but it took two tries :) . First try My first idea was to focus on the protagonist of the game, who is a tomb raider kind-a guy (the not so morally OK one). Not being a typical hero or warrior, I wanted to present him as a bit of a simpleton and not someone who would kill a bunch of monsters with a single slash, since you won't be able to do that in the game either. Concepting and direction I started out with some concept sketches in my notebook, portraying a bandit/pirate figure carrying huge bags...
I continued with flashing out this character with a composition I thought I like:
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... First batch of line-art and shading work was pretty promising, I grown to quite like the character...
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 .
Then I throw together a "placeholder" pixel art title text.
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:

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. I came up with the following concept afterwards which I really liked:
I followed a similar approach for scalability, using Inkscape to create the outline and work from the renders, manually pixeling the final image:
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 :) . 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:
Stay tuned!

## I am overburdened, nobody make a sound!

Hi everyone! This post is going to be more like a tutorial, than a journal entry. I highly recommend checking out the video version, as it is heavily audio oriented + it contains some recent game-play footage :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!). 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. 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. 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. 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! 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 comparisonThat is all for this post. I already cranked-out tiles and some sprites for the game, so I'm guessing the next entry will be kind of similar, but focusing on the art side. Take care!

## I am overburdened, loot is forever.

Hello everyone! This entry turned out to be lengthy and pretty technical. Sorry about that, but last week was spent only on "under the hood" stuff. I did my best to make it interesting though :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
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 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:
12345
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. 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: ForearmsVambracesItem2211InflictDamagetrue20BonelessDifficulty, 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.

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!

## 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 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 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. 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 :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 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 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 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 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. 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.
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!

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.
I could go on about this game for pages (as always :D ), but this should be enough for this week.
Take care!