• Advertisement
Sign in to follow this  
  • entries
    12
  • comments
    12
  • views
    7273

About this blog

Thoughts and ideas on game design. Also, a showcase of my work.

Entries in this blog

Hello there!

I've been busy implementing the display of cover status. Basically I used the similar approach that XCOM uses: three types of shields (full, half-full, empty) indicating three types of cover, plus a yellow shield if a character is flanked. Here's the final result:

giphy.gif

You might notice that I removed the HP display; I need to rework it so that is looks cleaner - so that will be the next thing that I will be able to (hopefully!) showcase to you next time!

 

Take care!

Hello there!

So obviously I have submitted my game to the jam. I even changed the title slightly again (added the "Twin" word), because I can! :)

Anyway, the cover mechanics that I started working on during the jam looks pretty interesting, so I decided to progress further with this idea, even though the jam has already ended.

First of all, I added some more visuals to indicate that a character is hiding themselves behind a cover:

large.twin_demon_slayers_cover.gif.33ab9

Additionally, I have fleshed out the cover system, making it more similar to the one from XCOM. Basically it does not rely on a simple line-of-sight mechanics, but also implies that a character might be able to lean to actually hit the target (which might be leaning as well):

large.twin_demon_slayers_hit_probabiliti

Player on the left is able to hit the enemy even though there is no direct line-of-sight. What is more, the hit probability is 100%, as the enemy is flanked.

 

I guess the next thing to take care about is to make it more clear to the user what kind of cover (light/heavy) are the characters having. I will keep you posted on updates!

Take care!

7DRL 2018 progress on "Demon Slayers" so far:

  1. [~90% done] Introduce new graphics, possibly animated ones
  2. [done] Introduce two player-controlled characters
  3. [done] Dumb-down the ammo mechanic to the same approach that was present in XCOM (the player simply needs to reload a weapon after X shots; there will be no ammo items/drops in the game)
  4. [done] Introduce "crates": tiles that are not passable, but ranged attacks are possible through them.
  5. [done] Introduce % to hit mechanics. 85% is the base value. 0% if path is obstructed. 50% is the path goes through a "crate" that the target is next to.
  6. [done] Remove the mechanics of merging the enemies from low tier into upper tier; alter the enemy spawning mechanics so that enemies of different tier can be spawned
  7. [done] pure melee-type and pure ranged-type enemies
  8. [done] randomize the level creation

Well, that was quite a long time with no update... but I did manage to create a lot!

I spent a lot of time to implement the cover mechanism. Even though it is working exactly as I wanted it to be, it turned out not to be as entertaining as I thought (well, simply put - XCOM did it better ;) ).Basically if the character is standing next to a crate, it receives a cover bonus:

giphy.gif

Red imp has only 50% to hit me!

 

As you can see I tweaked the graphics and added some animations. Also, there are now two types of enemies - the green one, which simply tries to perform a melee attack, and the red one that will always try to shoot you. 

And, last but not least, I've put new winning conditions - the player needs to destroy the crystal that spawns on the other edge of the room, which is now randomly generated.

large.crystal.png.e3880ae98c62e726490a2a

Crystal - destroy it, and you will win.

I am basically done with adding the gameplay mechanics. I mean I still have a lot of ideas that could be used here, but there is simply no time. I will try to add/improve the graphics, test the game and balance it if necessary, and that's basically it. I plan on submitting it to the jam on Sunday.

And here's another gameplay gif:

giphy.gif

 

Take care!

Hello again!

7DRL 2018 progress on "Demon Slayers" so far:

  1. [~50% done] Introduce new graphics, possibly animated ones
  2. [done] Introduce two player-controlled characters
  3. [done] Dumb-down the ammo mechanic to the same approach that was present in XCOM (the player simply needs to reload a weapon after X shots; there will be no ammo items/drops in the game)
  4. Introduce "crates": tiles that are not passable, but ranged attacks are possible through them.
  5. Introduce % to hit mechanics. 95% is the base value. 0% if path is obstructed. 50% is the path goes through a "crate" that the target is next to.
  6. [done] Remove the mechanics of merging the enemies from low tier into upper tier; alter the enemy spawning mechanics so that enemies of different tier can be spawned
  7. [new] pure melee-type and pure ranged-type enemies
  8. (nice-to-have) randomize the level creation

I managed to spend a few hours on the game, and I've simplified the ammo mechanics. Now basically the player has 3 ammo points. After three shots, the player needs to reload, which simply takes an action, but does not require any ammo items.

What is more, the enemies themselves are now able to shoot the player characters! I need to make sure that there are different types of enemies - maybe one pure melee type, and another one that only uses ranged attacks. I have added this feature into the scope. Well, that's feature creep, I guess. And the time is running out :(

Also, I played around with the interface a little (the text is now displayed on mouse hover), but I don't think it will stay this way. Anyway, here a gameplay gif:

large.ds_2.gif.c7497e993ffc6ba42561756cf

Now, the next thing will definetely be that cover system!

Take care!

So yeah, I basically needed a name for my game for the jam. The original was called "1 Room Demon Slayer", as it was created for the 1 room rpg jam. So now I've removed the "1 room" part. And as there will be two player characters, the "Slayer" part got renamed into "Slayers". Mind. Blown.

7DRL 2018 progress on "Demon Slayers" so far:

  1. [~50% done] Introduce new graphics, possibly animated ones
  2. [done] Introduce two player-controlled characters
  3. Dumb-down the ammo mechanic to the same approach that was present in XCOM (the player simply needs to reload a weapon after X shots; there will be no ammo items/drops in the game)
  4. Introduce "crates": tiles that are not passable, but ranged attacks are possible through them.
  5. Introduce % to hit mechanics. 95% is the base value. 0% if path is obstructed. 50% is the path goes through a "crate" that the target is next to.
  6. [done] Remove the mechanics of merging the enemies from low tier into upper tier; alter the enemy spawning mechanics so that enemies of different tier can be spawned
  7. (nice-to-have) randomize the level creation

Anyway, I got the opportunity to do some coding for the Jam. I did manage to introduce two player characters. User can switch them using the "tab" button. Man, that was some hard work - the previous version of the game did not have any code base that would be ready to handle more than one player-controlled entity. It is now working though!

large.ds_1.gif.6233146888457e0af54b8e528

I have also removed the gameplay mechanic that was responsible for merging enemies into higher-tier units. Currently the AI only focuses on reaching the closest player character and perform a melee attack on them.

Also, as you might seen on the gif above, I have replaced the player and enemy character images with my own ones! Ones that actually have an idle animation! Sweet!

I guess that the next thing to focus on is to make sure that the shooting mechanics are using the cover system.

Take care!

bryqu

Hello, world!

Long time no see! But - as there is a new opportunity to extend/alter my "1 Room Demon Slayer" game, I want to make sure that I keep everyone up-to-date. Basically, the 7DRL Challenge 2018 has just started, and I do want to remake my original game during that time.

My idea is to keep the current implementation of movement/action points (similar to the one present in new XCOM games), and also introduce a basic concept of cover - meaning that the percent to hit will depend whether there are any objects blocking the line of fire.

To make stuff more interesting, I want to give the player the control upon not one, but two characters - so that flanking tactics might become available.

I also plan to change the general gameplay mechanic - currently the player needs to kill the demon,  which can only spawn when lower-tier enemies merge themselves into it. The new mechanism will be about destroying a static object in the room, while keeping your characters alive.

Anyway, because I will only have 7 days - here's the list of changes I want to make:

  1. Introduce new graphics, possibly animated ones
  2. Introduce two player-controlled characters.
  3. Dumb-down the ammo mechanic to the same approach that was present in XCOM (the player simply needs to reload a weapon after X shots; there will be no ammo items/drops in the game)
  4. Introduce "crates": tiles that are not passable, but ranged attacks are possible through them.
  5. Introduce % to hit mechanics. 95% is the base value. 0% if path is obstructed. 50% is the path goes through a "crate" that the target is next to.
  6. Remove the mechanics of merging the enemies from low tier into upper tier; alter the enemy spawning mechanics so that enemies of different tier can be spawned
  7. [nice-to-have] randomize the level creation

The list is actually pretty long, considering that I will be only working in my spare time - and I definitely do not have too much of it.

I will make sure to post daily progress on my blog, so stay tuned!

It turned out that a month has passed already since my last blog post. Clearly I got distracted from any kind od game development activities for too long.


Anyway, I wanted to share some of my experiences from the development process of 1 Room Demon Slayer game which I've submitted to the 1 Room RPG Jam.


So here goes:


Learn about the jam details


It turned out that the jam did not have any voting activities whatsoever - meaning that after the games have been submitted and the deadline has passed, nothing else happened. That was quite a surprise for me, as I (and surely not only me) was looking forward to see how the others rate my game.

Define gameplay pillars


Yeah, I know that this sounds like a no-brainer - but for a person who did not complete any full game up until now, that is an important thing to remember. Before you actually start building up the game, try to define two or three core aspects of the game. Of course the Jam rules themselves did enforce some gameplay decisions, but they were not that restrictive. So I came up with following pillars:

- Game would be turn-based, but fast paced (by making the interface and interaction as simple as possible),

- The mechanics should be transparent, simple and has as less randomization as possible,

- The game should reward risky play.


Having such core values in place, it is much easier to stay on track when designing stuff. For example: initially I thought about introducing more randomized approach to combat - by introducing to-hit percentage values. However, this made the gameplay too random and disallowed the player to plan ahead their actions - so I decided to drop this.

Have a version control set up


Seriously - if you're not using any kind of version control system, go set it up. This is the only way in which you will be able to track your changes and not to worry about loosing any of your code history. You do not have to necessarily store it in the cloud - it should be sufficient just to set up a local instance of a repository. Aim for Git or Mercurial, or any other kind of distributed version control systems. Personally I am using Mercurial, due to my bigger experience with it.

Use free assets


When you're racing against time, especially in jams with tight deadlines, it is no shame in using some existing stuff. I stated a slightly different opinion myself in that matter, in one of my older blog posts, but I am pretty sure about this now: if you want to deliver stuff, do not waste time on creating the assets yourself.

Make sure someone else playtests your game


Man, this is so crucial. In my case, I went full hardcore and let my wife check the game out. I didn't give her any pointers whatsoever except the possibility to read the readme file. Then I just watched as she tried to understand how stuff works.


The thing is that my spouse is not into gaming whatsoever - so observing her struggling with the interface was actually a great thing, and gave me a lot of pointers on how to improve the flow of the game and its usability.

Unity is cool


Yeah, it is. I love the modular design behind it. I love the fact that I can use Visual Studio when working with the code. And the fact that the community is extremely big and helpful helps even more.

That being said, I haven't really researched what other engines I could use. I went with Unity as I heard good stuff about it. Maybe there is a better 2D game engine out there, waiting for me to be discovered?

That's all the tips I got for now. I am not sure what should I do with my game from the Jam though. I guess that I will try to tweak it a little bit - especially on the visual side (add some animations, effects etc.). This will allow me to know Unity even better.


Take care everyone!

So that's it - I have uploaded my game for the 1-Room RPG Jam. Go check it out at its page, along with all the other submitted games that started appearing today.

I plan to post more detailed lessons learnt from the development process in the next blog post. For now I will just state the obvious, I guess: it takes much, much more time to actually finish a game than one thinks :)

Take care! And as people like screenshots, here's one from the start menu screen:

1.png

1 Room RPG: combat

Hi again!

Deciding to participate in that 1 Room RPG Jam turned out to be really a good thing! I have never found that much motivation inside of me before. Also, I am learning a lot about Unity, as it was actually the first time I decided to give it a go and try to create an actual game using it.

Anyway, I have around eight days before the jam's deadline. Given the fact that I am only working during evenings (and definitely not everyday, as I actually have a life), this is not that much.

The good news is that I have all the important game mechanics in place already, and it is "only" a matter of balancing them. And maybe adding one extra game feature. Oh, and possibly upgrading the visuals a little if there will be some time left.

Speaking about game features, let's talk combat. The player is able to attack the enemies in two different ways: using direct melee attack or shooting a ranged weapon.

source.gif

Melee attack in action. The player ends up being killed in the end.


For melee attacks, the player needs to stand right next to the enemy. The player can attack even if they used all their moves.

As for the ranged attack, the player needs to have the enemy in a line of sight. And the player needs ammo, which can be dropped by killed enemies. The player is able to shoot only if they haven't already spent all their actions on movement.

source.gif

Obviously, player cannot shoot through walls.

Now, the interesting part: I was trying out different approaches for how to calculate the hit probability of combat actions. And to make the game more predictable, I've decided that the player (and enemies, as well) will always hit their target when attempting an attack. In such way the player can more-or-less plan their moves in that tiny room full of monsters. And they better plan them correctly! Is it better to kill that level-one zombie in this turn, but be exposed to two other ones that will inevitably attack you? Or, maybe it is worth moving back, allowing two zombies to merge into a level-two creature (which is more difficult to kill, but can drop more powerful item), which you will be able to kill relatively easy in two turns from now?

Not everything can be planned though. There is still a dose of randomness included, because:

a) After each turn, a new enemy is spawned in a random location,

b) Dead enemies drop different types of loot, and these drops have probabilities of their own.

I guess I will write more about enemies, items and item drops next time. For now I can say that this game actually is fun to play for me, and this already makes me proud of myself :)

Take care!

1 Room RPG Jam

Creating games in WPF might be nice - as I was already familiar with its features, due to its extensive usage in my daily work. I knew however that sooner or later I would have to learn using some kind of "real" game engine - just to explore what kind of features I am missing, and to change my mindset (obviously the way in which one designs and creates an application using a game library/engine differs from the more business-related approach in WPF).

As there is no better way of learning a tool than to create a clear goal that needs to be accomplished using it, I've decided to join the 1 Room RPG Jam, and to use Unity Game Engine for the project.
I have a month to submit a game that would meet all the criteria, and these are:


  • Entire gameplay is contained to one room
  • Game must have 3+ interactive objects
  • Game must have functional inventory system
  • Gameplay must be 5+ minutes
  • Game must be appropriate for audiences under 18

    After couple of evenings, I already have something nice to show and talk about. The idea that I am aiming for is simple: we're dealing with 2D, tile-based room. Some of its tiles are passable, some are not. The gameplay is turn-based. The player controls one character, which is able to move around the room using similar approach to the one present in the new X-COM games.


    source.gif
    Movement mechanics in action - xcom style!

    I used some old A* implementation that I used in one of my previous prototypes and it worked out pretty well. It does impacts the performance when calculating all the possible fields that the player can reach. I basically run the pathfinding for all the map tiles in the player's range, and it takes around half a second. Luckily I only need to perform such calculation once, at the beginning of every turn.

    There are hostile characters present in the room. During their turns, they either try to approach the player and attack him, or to enter a field in which another hostile character is standing - and then they combine into a stronger enemy.

    enemiesCombining.png
    Two weak enemies combine into stronger one, after they took their turns.

    After each turn, a new enemy (of the weakest type) appears in a random part of the room. The player needs to destroy all the enemies to finish the game successfully. Currently only a direct (melee) attack is available - so when the player is standing next to the enemy, he can try to attack it. I still need to re-think the way in which these attacks should work like (whether there should be a % to hit - to introduce randomness - or to make these attacks to hit all the time, to make the gameplay more predictable). I guess I will write more about the combat mechanic in my next blog post.

    As for learning Unity, it looks like I do not have any major issues with it. Its component-based approach is very clean and efficient. I can still use Visual Studio to create code. The only major issue I've experienced so far is about these artifacts appearing in some resolutions:

    artifacts.png

    Surely there is something that can be done to eliminate these funny lines...

    Anyway, that's it for now. Hopefully I will be able to write something extra about the combat system next time!

Welcome again, fellow game developers and enthusiasts!

When you're prototyping to test new game mechanics ideas, the visuals of the game should not be that important - it is not the graphics that matter during that period. We even have this whole "programmer art" term to define all these temporary assets.

Well, that's theory. And it seems it doesn't work in my world.

I mean there is an obvious difference between prototyping a game in a large dev studio and a single person who is creating a game as a hobby project in their spare time. You struggle with the lack of resources, from which the most critical are the time necessary to get things done, and the determination to continue with the work.

In the first game prototypes that I've created I did not put too much emphasis on the visual side. I had a lot of experience with composing the user interface, but only for pure business applications. As a result, my game prototypes were more similar to Excel than to something that might be perceived as enjoyable. Well, I maybe some people might find Excel fun and enjoyable... but I strongly believe that they are a minority.

Anyway, figuring

out w

hether a particular gameplay mechanic is fun meant more to me than being able to see cool stuff on the screen.

Or so I thought - but after some time spent on a project I found myself getting less and less enjoyed with my game idea. Even if the mechanics were good, the lack of good-looking visuals was hurting my gameplay experience. And if I stopped enjoying my hobby project, I abandoned it.

oldVsNew.png

Old vs new: comparing how the initial visuals looked like in one of the game prototypes vs their refined version. One can surely agree that finding any fun in the left one would

hardly

be possible.

Even though I was aware of the fact that these visual aspects are not the ones that I should be focusing on at this given moment, I simply couldn't focus on the game mechanics. Playing the prototype was not fun anymore.

Of course I could start using existing free assets. And in some cases doing so was in fact better. But then came another problem: I just felt that it is not something that I have created myself. This reduced the amount of enjoyment I had from creating a game. Sounds weird, I know.

steamRogue.png

Prototype of a

"Steam rogue" game, using pre-defined assets.

Therefore, I changed the way in which the new prototypes were created. I've upgraded the visuals by learning how to draw stuff so that it looks not as crappy as before, and now I simply feel better when I am working with my prototypes. Of course such approach takes more time. I am pretty sure that most of the visuals will have to be thrown out, or at least recreated in the long run. That many of them won't make it to the final game, as they will be not fun enough to get through the prototyping phase. On the other hand, it simply wouldn't be possible for me to work without creating these better looking visuals. And as I definitely want to feel good when spending my free time on a hobby, I see no ther way.

But maybe that "prototype with ugly visuals" approach is how the prototyping should be made? If the visuals and usability of the UI are crappy, but the game is still fun and enjoyable, maybe that's when the designer can be sure that their game idea will simply rock? And adding nice visuals will only further improve player's experience, resulting in a top-notch game? I don't know, maybe that's how we should approach to creating prototypes. It is just that this way of working didn't work for me.

manor.png

"There's no one left": visiting a manor outside the town.

Introduction

Hello everyone! As a software developer, the part of my regular job is creating NET applications - mostly in WPF, lately. Additionally, I spend some of my spare time designing and prototyping video games - and I believe today is the right time to start sharing all my experiences with all of you.

Instead of running a blog, I decided to create a game project and post my experiences as articles here. The reason is that I have created quite a few game prototypes so far, and didn't find them very enjoying (hey, that is what the prototyping is about anyway - figuring out which ideas are fun, and which are not, right?). However, recently I stumbled upon a game idea that might be worth digging into - and that's where the idea for "There's no one left" appeared - an idea that might turn out to be more enjoyable than other stuff that I prototyped in the past.

"TnoL" is surely NOT an arcade game of any sort. I simply do not feel like designing a game where the player needs to use their reflexes to achieve something. It doesn't mean that I do not like playing such games, hell no! I enjoyed the new Doom very much, for example. It is just that I prefer to design more calmer approach - so turn-based stuff, generally. Things like XCOM or Civilization series.

So yes, "TnoL" (and all of my previous prototypes, which I will surely describe in further articles) will be a turn-based game, if you can call it that way. The player will have a pool of action points (replenishable at the end of each game turn) that they can spend on different actions.

The game is about a making sure that a person who suddenly became alone in the world survives long enough to escape the area. Or maybe to solve the game plot in a different way. Hard to tell right now. This is tied to the narrative and the story of the game, and on this early level of prototyping is not that relevant. That being said, I believe that the game should be placed in a steampunk world. And that is simply because I like this stuff.

OK, so I stated that the story is not really important for now. What is relevant though is the general direction that the game should be heading to. My core pillars of the game are as follows:


  • The player needs to make meaningful choices in the game (whether to go searching for water and food, risking an attack from a wild animal, or maybe take a look around in the mines to find a better weapon? Or maybe stay at the shelter and look through all the junk lying around, hoping to find something that will allow the player to create animal traps?). This also implies that the player should be able to take risky actions that might pay off if successful.
  • The player needs to feel that the number of actions that can be performed during the day is too small to be able to accomplish everything that needs to be done. This will require some planning and thinking ahead.
    The player should see combat as a danger that needs to be taken into consideration when planning the actions. The combat should be simple enough to make sure that it does not become more involving than the rest of the game.
  • The player should experience the loneliness in the world (this seems like being only bound to the narrative and story, but I believe that it might be used in the game mechanics as well - more about this in further articles).


    One might say that "TnoL" will be some kind of a more advanced tabletop game. And I totally agree. To be honest, "Civilization" series are also kinda tabletop - but due to their complexity, one wouldn't be able to play it nicely without the support of computer's processing power.

    Anyway, that is all about the game idea for today. Now, some screenshots! These are from the prototype that I am creating in WPF. The graphics have been created by me. I use pixel art as for me it is the easiest form of creating visuals that don't look like crap.

    [sharedmedia=gallery:images:8193]

    The shelter view - so the main "base" of the player, with the possible actions that the player might undertake.
    Also, all the stats are visible on the top - including the number of action points left in the day.

    [sharedmedia=gallery:images:8194]
    A shot from combat screen. I will surely write more about the combat in further articles. The wolf is cute, isn't it?

    [sharedmedia=gallery:images:8195]

    One of the locations that the player is able to go.

    Alright then, enough for today!
    So the idea is that all my articles appearing here will be related to game design, including my thoughts on game mechanics, story, narrative or visuals. I will also be surely posting all the progress on the "There's no one left" prototype. Stay tuned, and I hope you will enjoy it!

Sign in to follow this  
  • Advertisement