I am overburdened, miles of tiles

Hi there!

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

Art direction, ideas

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

2017_02_04_screenshot_1

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

False positive

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

2017_03_26_mockup

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

Goals, final looks

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

2017_03_26_quake

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

Here goes some shots about the results:

2017_03_21_screenshot_1

2017_03_26_screenshot_1

2017_03_26_screenshot_2

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

How-to?

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

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

2017_03_26_gimp

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

2017_03_26_tile_values

Than I “sketch” a simple pattern for a tile using the values, usually with a light-source residing in a North-West direction.

2017_03_26_tile_pattern

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

2017_03_26_tile_detail

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

2017_03_26_tile_colors

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

2017_03_26_tile_noise

A screenshot with the final tiles:

2017_03_26_screenshot_3

Thanks for reading.

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 😉 …

2017_03_23_boxartmultiplatform

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

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: spidi@magicitemtech.com

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

Demo builds

2017_03_24_logo_mac 2017_03_24_logo_nix

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…

2017_03_21_concept_1

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

2017_03_06_boxart_11

2017_03_06_boxart_21

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

Inking, results and confession

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

2017_03_21_inkscape

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

2017_03_21_lineart_1

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

2017_03_21_lineart_2

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

header

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

2017_03_21_attempt_1

2017_03_21_attempt_2

2017_03_21_attempt_3

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

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

Second try

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

Reference material

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

2017_03_21_reference

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

2017_03_21_concept_2

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

2017_03_21_lineart_3

Final, final, final, final!

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

boxart_final_final_final_final

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

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

2017_03_21_screenshot_1

Stay tuned!

I am overburdened, nobody make a sound!

Hi everyone!

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

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

Chip tune or not?!

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

Recording

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

2017_03_02_foam_11

2017_03_02_foam_21

Audacity to the rescue

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

2017_03_02_audacity

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

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

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

2017_03_02_effects_1

2017_03_02_effects_2

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

Public domain

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

2017_03_02_opengameart

2017_03_02_freesound

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

2017_03_02_cc0

Runtime tricks

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

Example walking cycle in I am overburdened:

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

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

Take care!

I am overburdened, loot is forever.

Hello everyone!

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

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

Items, loot

2017_02_19_screenshot_1

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

Attribute bonuses

2017_02_14_gif_1

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

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

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

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

    // events ...
}

public class Player
{
    public Attributes Attributes;

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

public class Inventory
{
    public Attributes Attributes;

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

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

Skills, event system

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

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

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

            TakeEffect(name, context);
        }
    }

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

    // Some helper methods...

    public HashSet<string> HandledEvents;

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

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

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

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

Few of the most common events in the game:

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

Some of the existing skill implementations:

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

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

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

Tags

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

2017_02_20_gif_1

2017_02_20_gif_2

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

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

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

Difficulty, pacing

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

2017_02_20_pacing_1

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

Stay tuned!

I am overburdened, 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!