• Advertisement

Bryky

Member
  • Content count

    31
  • Joined

  • Last visited

Community Reputation

254 Neutral

About Bryky

  • Rank
    Member

Personal Information

  • Interests
    Programming
  1. 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: 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!
  2. 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: 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): 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!
  3. Twin Demon Slayers

    XCOM mechanics in a roguelike!
  4. 7DRL 2018 progress on "Demon Slayers" so far: [~90% done] Introduce new graphics, possibly animated ones [done] Introduce two player-controlled characters [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) [done] Introduce "crates": tiles that are not passable, but ranged attacks are possible through them. [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. [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 [done] pure melee-type and pure ranged-type enemies [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: 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. 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: Take care!
  5. ds_1.gif

    Thanks! There won't be an online version, but you will be able to download it from the Jam page (https://itch.io/jam/7drl-challenge-2018) - assuming that I will finish it on time
  6. Hello again! 7DRL 2018 progress on "Demon Slayers" so far: [~50% done] Introduce new graphics, possibly animated ones [done] Introduce two player-controlled characters [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) Introduce "crates": tiles that are not passable, but ranged attacks are possible through them. 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. [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 [new] pure melee-type and pure ranged-type enemies (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: Now, the next thing will definetely be that cover system! Take care!
  7. 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: [~50% done] Introduce new graphics, possibly animated ones [done] Introduce two player-controlled characters 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) Introduce "crates": tiles that are not passable, but ranged attacks are possible through them. 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. [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 (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! 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
  8. 7DRL Challenge 2018

    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: Introduce new graphics, possibly animated ones Introduce two player-controlled characters. 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) Introduce "crates": tiles that are not passable, but ranged attacks are possible through them. 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. 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 [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!
  9. 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!
  10. 1 Room Demon Slayer submitted to jam!

    Thanks! I've added a gameplay gif link on the game details page. The link is http://i.imgur.com/SfVWZVL.gif.
  11. 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:
  12. 1 Room RPG Jam

    Please do! Its topic sounds quire amusing to me, so it will always be a good thing to see some more games following that idea.
  13. 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. 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. 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!
  14. 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. 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. 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: 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!
  • Advertisement