I’m back. The last 2+ years have been a very hard time for me but I have still been working on projects and growing my skills. The latest one I wanted to show off is this game engine-ish prototype I’ve made using Rust.
It started out just as a way to learn graphics programming using the tutorials on learnopenl.com as I was learning the Rust programming language separately. One day, I decided to combine the projects and have been adding new things to it as I progress.
Here’s footage of the current state of the project.
You can download it over on itch.io if you’d like to see it for yourself. (Note: Collision detection and resolution has been disabled while I work on improvements for it.)
Given the date, I just want to make sure everyone understands that this is serious and not some April Fool’s Joke.
I’m back everyone. I somehow managed to survive GDC and being staff at another convention both in one week and not come out sick or dead.
I was hoping to playtest the game at my alma mater’s Prototype and Playtest Night but space filled up there pretty quickly so I spent my time playtesting others’ games instead of my own. However, I still came out of the conference with some ideas for how to change up my game.
I believe I’ve discussed changing the title of Rogue Lives to Memento Mori before and I think that’s going to be the working title from now on. The basic idea stays the same: Zelda-inspired rougelike where each run is a new life in the reincarnation cycle of a legendary hero.
However, I’ve decided to try changing the gameplay to work off a card based system. Every card (probably called a Memento in game) is supposed to have some memory of the hero stored inside of it. With each life, the hero will be able to add some new memory to the deck based on the accomplishments made in the previous run. I’m still designing how that would work.
In addition, I’m planning on a simpler dungeon system of moving between rooms with the press of a button instead of having to navigate inside of them. This was born out the switch to the card system and a desire to get that up and running on mobile. This seemed like a simple way to do that and fits the somewhat turn-based structure I think the game will go in with the new system. I still plan on things like locked doors and closed doors but they will obviously need to be changed a bit to fit the new structure.
I also decided to start “from scratch” on a new project for this but over time, I plan on incorporating as much of the old version as I can to save myself time.
Over the last week, I’ve taken just about every opportunity to work on the project but that leads me to my last announcement: Due to how hectic my schedule has been with all of the outside issues that need to be taken care of, this will be the last Progress Update post for a while. I still intend to make them but I don’t think I can make enough progress on a weekly basis with my schedule the way it is at the moment. Honestly, I don’t think I was making enough for a while. My current plan is to make one whenever I feel like I’ve made a decent amount of progress on this new protoype.
That’s it for now. I guess I can’t say see you next week so I guess I’ll see you later.
Well, it’s Monday and with GDC a little less than a week away, it’s time for another progress update on the development of Rogue Lives.
GDC is in a week! I would like to keep stressing that. It’s both exciting and terrifying. I’m hoping to show off a prototype of the game at the Playtest/Prototype night my alma mater puts on but I’m not so sure what I’ll have at this point. I’d really like to have something so this is going to be brief.
I spent most of my time fixing issues with the tools I was creating. I got doors spawning correctly on walls. I also modified the size of rooms so that they were still wider than they were tall. I tried using square rooms but it just didn’t look right. This, along with modifying the size of the walls meant I had to change the exact placement of rooms on the board so that they didn’t overlap.
I improved the editors themselves to handle opening and closing doors properly along with locking and unlocking closed doors. They even animate in the editor even if it takes them a while. I also got connections between rooms working properly in the editor along with removing some of the hard coding that was there when dealing with board size.
So, this week was a lot of fixes and not a lot of new content created. I’m really hoping to focus on that this week. I want to make sure all my changes work in procedurally generated levels so that even if I don’t have the big bad’s lair done, I can still have people try out those ones.
I’ll be off for the next two weeks with all the GDC and other things I have but I will be back on April 1st. No fooling. See you then.
Well, February is over and GDC is ever closer but for now, it’s time for another update on development of Rogue Lives.
As I expected, I spent this week focusing on developing the first area of the game, the big bad’s castle. I had the basic layout done last week so I spent this week trying to figure out how to simplify adding things to it. To do that, I developed some new editor tools for the board, rooms and the like.
The Board Editor
For the Board Editor, it allows for quick changes of the number of rooms in the board or the dimensions of the rooms. Hitting generate board will create a new board using that information. Right now, I’m looking for a way to allow for it to modify the rooms on the board instead of generating a new one every time.
The Room Editor
The Room Editor is a bit simpler, at the moment, it’s just for modifying the entrances to the room. If there’s no door on a wall, there will be a button to add one. If there is one, there will be one or more buttons to allow for removal of the door and control of the open/closed/locked state of the door.
Adding a new door will also add a connecting door to the room on the other side. If there is no room on the other side of the wall, the editor will not allow for a door to be placed on the wall.
Tile Editor
The Tile Editor is fairly simple allowing for the spawning of multiple tiles to allow for easier modification of rooms.
There is also an editor for activators but that still needs work because I was naive and thought I could get all of this working without making many changes to the code for classes to get them to work well in the editor. Now, I’ve realized my mistake and will be working had this week to fix that up so I can get back to working on content for the GDC demo.
Welcome back to another update on the development of Rogue Lives. It’s been a week and here’s a quick look at what’s changed between now and then.
One of the biggest changes is that I’ve started adding in sound effects. I created a sound manager class that handles sound effects at the moment. I plan to have it handle background music in the near future as well. Currently, it uses a similar method of storing clips with a name as the Game class does with treasure, enemies and the like except now, it moves the list into a dictionary and then, clears the list at the start of the game. I’ll be looking into other methods to improve this as development goes on but these both work for now.
There have also been additions of new items to be used in dungeons. The biggest, at least in size, are the rocks that without bombs to destroy them, serve as an impenetrable barrier to the player. I also added in levers that function as another kind of activator.
Finally, I created signs which gave me a bit of a headache as I tried to figure out a way to allow them to be read without infinitely cycling through the text as the player just kept pushing the button to read them. I think I’ve gotten all the problems solved but with game development it seems more arise with each fix. These might not be all the useful for procedural levels but I think I’ll get use for them in some of the areas that are static between runs. Speaking of that…
I also spent time working on the first and last level of the game. I don’t really have a name for it at this point beyond the Big Bad Castle. The game starts with a fully powered player journeying through the castle to fight the big bad and I’d like to use that as the basic tutorial teaching the player about all their actions and items.
I’m still working on the layout but I think I like my current path of doors and placement of the minibosses and the big bad at the center. I’m going to be focusing on this a lot so I can hopefully have it ready for GDC.
There were a few other minor things this week like adding in the ability to reflect certain projectiles so hopefully, there can be a tennis boss but as I said, I’m focusing on developing the tutorial level now. I’ll be back with an update on that next week. See you then.
Happy Monday, everyone and welcome to another Progress Update.
Progress on Rogue Lives was hindered by the heavy rain in the area and a few other things causing changes in my schedule but I still made a decent amount of progress. Most of the work was put towards adding in one or more placeholder minibosses to get the concept working within level generation and then making it work within the levels themselves.
First, creating the minibosses. Before last week’s update, I had already selected a few sets of sprites from my list of assets to use so I proceeded to create a basic miniboss fight using them. The sprites I picked had an elemental theme like they could just pop into existence and then out using whichever element they were composed of.
Because of that, I decided to have them move around by teleporting which started and ended with them fading out. When I’ve done something like this before, I’ve written the code for every object type that uses this. This time, I decided to create a class that handles the fading of a sprite using the Sprite Renderer. It’s so simple I can’t believe I never thought of doing this before. I’ve already added it to the treasure chest prefab which I think gives it a much more magical feeling.
With that complete, I also had to create the basic attack pattern of the minibosses. Currently, this is:
Teleport In
Wait A Bit
Fire A Projectile
Wait Another Bit
Teleport Away
I like this as a basic patter but I want to update it in the future. I’d like to give each of the elementals some kind of special features like fire leaving behind a trail that damages the player if they touch it. That will probably have to wait as I iron out a few more things I need done before GDC.
Finally, I started adjusting level generation to account of the addition of the miniboss room. I’ve experimented with adjusting the size of the dungeon and the distance between the entrance, the boss room and the miniboss room. Currently, the miniboss room can be anywhere that is at least two rooms away from the boss room and the same amount away from the entrance. Right now, it generally means that it’s in the middle room of the path. Like with the miniboss actions, I intend to update it at a later date but it may have to wait until after GDC. At the moment, I’m prioritizing getting the basics up and running and adding more enemies for a bit of variety.
Well, that’s it for this week’s progress update. I hope you’ll be back next week.
Welcome back. Another week’s gone by so it’s time for another update on video game development.
With just about a month to go, I’m focusing on getting a demo version ready for GDC this year and that means getting all of the basic systems for the dungeon up and running.
The first of these was treasure chests with items. These are currently saved for important items like weapons received after defeating a miniboss (which aren’t currently implemented but that’s my first thing this week). After finishing the fight or puzzle that triggers it, the chest appears and it works like another interactive object. Interact to open it and receive the item inside along with a message on how to use it. That little message is also a new addition to the adventure item class.
This was part of expanding the number of Interactive Items. I also created new child classes covering thrown objects like bombs and things like blocks that can be pushed or pulled. I plan to expand it to signs and other things that can be read using the same functions the treasure chest and item messages use.
The second was getting activators and the activated objects they activate implemented as well. Currently, the only activators are pressure switches activated by placing either the player or a block on top of it and they can only activate doors at the moment. I plan on adding in more objects that can be manipulated like that in the immediate future.
These all fed into more additions to level generation. I’ve added in new elements like spike tiles, pushable blocks and the aforementioned treasure chests as well as making additions for the new miniboss rooms.
A simple spike filled room.
For the miniboss, each time a dungeon is created, it finds a room somewhere in the middle of the path between the entrance and the boss room to be the miniboss room. It also selects a treasure from the list of ones not currently in possession of the player and sets it as the dungeon’s treasure. When the miniboss is defeated, a treasure chest containing the treasure will spawn in the room.
As I’ve said, minibosses aren’t implemented currently but I’ve found a few more sprites in my collection that I like for minibosses and will be adding them in as a basic set this week. I also plan on adding in more interactive objects like making spikes or similar hazards controlled by switches that the player can activate/deactivated to try and find a path through the room. This should hopefully culminated in puzzle rooms in the near future.
Well, that’s it for this week. Come back next week and see what new updates await. See you next week.
Monday’s come around again so that must mean it’s time for another update on game dev progress for the last week.
Development of Rogue Lives this week focused mostly on the Bomb item. I added in cracked walls that can be blown up to reveal the doors behind them.
The code for the cracked walls uses the DamageableObject interface to find when it has taken damage and if that damage is of the new DamageType Explosive, it destroys the cracked portion revealing the door behind. That door might still be locked or closed due to other reasons so players will still have to take on all those snakes before they can get out.
I’ve also added in the ability to create doors sealed like this into the level generation algorithm. First, it checks if the player has bombs in their inventory and if they do, when choosing doors to lock, there’s a chance that instead they will be sealed behind cracked walls.
I also started working on an Interactive Item class. If the subtle name didn’t give it away, it is for items that the player can interact with like signs to be read or blocks to be pushed. Currently, it is used for picking up and dropping bombs that have already been placed. I have an idea for how to get bombs to be throwable so they can be used as a long range weapon and I will try to get that up and running in the next week.
I also made some larger changes to level generation. Now, instead of having a list of rooms to represent their connections to other rooms, Rooms have an array of 4 other Rooms set to null and changing when a connection is added. Similarly, their list of doors has become an array of four as well. This allows for easier access using directions to determine which door leads to which room. The previous method had given me errors when things didn’t line up so I’m hoping that this is less prone to breaking.
This allows for easier access using directions to determine which door leads to which room. The previous method had given me errors when things didn’t line up so I’m hoping that this is less prone to breaking.
Well, those were all the big changes for this week. I have some things taking up dev time this week but I should hopefully still have a lot to report about next week. See you then.
I made some improvements to room generation mostly focused on monster placement in water rooms. I don’t want players getting stuck because there’s an enemy on an unconnected island and they don’t have a range weapon to reach it. Therefore, when adding an island during level generation, the function will check if the island is connected to the main path. If the player doesn’t have a ranged weapon, enemies that will not be added on the unconnected islands.
This also meant I had to make changes to items in the game. I game the base Adventure Item class a IsRanged property and added them to the lists stored in game for easy access when they need to be added to the player. They also show up properly in the UI with their own icons that can be cycled through using the Z and X keys on keyboard.
Bow and sword in accord.
I also worked on making the game controllable using a gamepad. I set up the axes using Unity input but was having difficulty with things like requiring a press for things like using a weapon and cycling through secondary weapons until I realized I could use axes with GetButtonDown to detect only the first frame of a press.
The last somewhat big change since last week is the addition of alternate player characters so that it can be changed with each life. I currently have a set of 8 seen below but I hope to add more later and maybe far down the road, add in a system of randomly creating the character’s appearance with each life to better show how each life is supposed to be a new incarnation of the hero.
There were a bunch of minor things as well like the barebones versions of a main menu and a pause menu but that’s it for this week. I’ll keep working hard to bring you another update next week.
Happy Monday, everyone. Let’s get down into this week’s progress update.
As I said last week, I’ve spent time improving the creation of paths in the game. Due to the 2D nature of the game and the cell structure of the dungeons, I could simplify it into calculating the difference in board position and then randomly moving one unit towards the destination.
I’ve also added in functions for simplifying the process of locking doors and they both open at the same time when unlocked.
I’ve finally started in getting the core loop of dungeon->die->upgrade->respawn to dungeon delve some more implemented. I’ve started to separate control of the game function into a manager class so I can more easily control the phases and allow things that were previously tied to the board and/or player to happen whenever they’re needed.
That also led to creating the basics of the upgrade system where player can spend soul xp (name not final) to purchase improvements to the player. I have icons and ideas for a handful but I’ve so far only implemented one to test the basics of buying and accessing the information of the upgrades.
I have also added the ability to hide upgrades until another one has reached a certain length. I might add multiple dependency in the future but I think it would be more chains of upgrades that all require something else.
I’ve also started to improve combat. I’ve changed the “did you come in contact with the player while he was swinging” method of damage with a basic hit scan by using a box cast on the area in front of the player and damaging any enemy in that area. I’ve also added in a basic dodge ability that leaves the player unable to attack but immune to damage as they “roll” out of the way.
I guess I got a bit more done than I expected. I’ll work hard this week to make sure I move everything forward. I’ve got to set soul xp amounts for enemies and have them pooled up so the player can spend them when they die. I’ve got to get respawning in a newly randomized dungeon working and I’m probably going to update combat for certain enemies as well.
Well, that’s it for this week. I’ll see you next week.
J.D. Kelly 