Ok so I really need to get back on the schedule of doing these regularly instead of getting wrapped up in other stuff and forgetting that explaining what I’m actually doing might be important. Last update was all about getting stuff set up for the playtest but after that we needed to focus more on larger scale updates.
For the last month(wow its been almost a month) I’ve been working on getting procedural generation up and running. Surprising absolutely no one there are quite a few ways to do this and a decent chunk of time was spent learning up on them and finding what would work both conceptually and in practice for what I wanted to do. The end result we’re at now generates a dungeon maze out of a set of objects, names each room according to the location of its doors, and then loads prefabs of tilesets matching the same name. With this format it makes a maze that can be traversed to reach a goal and new room shapes can be added in the future by creating corresponding tilesets. At the moment the rooms are all bare upon creation and all that can be really done is walk around but the next planned step is expand the generation program to also spawn enemies, platforms, and potential hazards around the room as well. Currently the code does create a room to act as the goal of the maze but I also still need to set it up to actually end things or move on to a new maze upon reaching the goal.
The current method holds quite a few problems that will need to be tweaked either by altering the room prefabs or adding in additional conditions when the code is expanded to spawn things. At present it is impossible to reach the doors at the top of the rooms(unless your jumping is really really high) so the rooms will either be shrunken, platforms will be set to always spawn in such rooms with a top door, or the tilesets will be edited to add different platforms without editing the code. This is especially important given that the first room you spawn in in dungeon creation can sometimes only have one door and that door is on the ceiling, making the game unplayable. The other main problem goes in the exact opposite direction but will be a lot quicker to fix. At the moment the doors in the bottom of the room are in the dead center, right where the player spawns which can cause you to either fall the second the game starts, or go through the bottom door of one room and then immediately fall out the bottom door the next room if nothing is in your way. This problem though was just an oversight on my part when I was making the tilemap prefabs, either I’ll move the bottom doors to not line up with your spawn or I’ll make a platform you can choose to fall through and put that over the top of each bottom door.
Next up will be fixing those issues with the blank room generation and implementing spawning of enemies and some kind of obstacles. There’s a lot more I want to add to this.
Well its been quite a while since I’ve done one of these. Since the last time I’ve had to move out of my dorm and then ended up with two weeks off because of the plague happening right before spring break. I’ll admit I wasn’t exactly the most productive over this expanded break, mostly just fixing some minor bugs, like the player being able to push the enemies around if you had enough health to survive(which is a concept I may revisit on purpose later because it was kinda fun), and reading through some different methods of procedural generation. However when classes started back up and I needed to start waking up before noon again I got back to work, picking up the pieces of where I left off. After totally remembering on my own that the presentation was coming up, and being annoyed with myself that I didn’t have anything ready to show last time it came around, I spent most of this last week doing a collection of minor tweaks and additions that I had put off until later that I didn’t need on developer end but would make it better to play when shared around.
Much of this was adding ways to access information that I could see from the unity terminal or console but not the game itself. The simplest was just adding some numbers next to the health and stamina bar so you could, you know, see that your stats there were going up. A rather important one that was handled by the console for the longest time but a player just might maybe want to see was creating a notification that pops up when a stat levels up, letting you know your current level. Considering the entire theme of the game this seemed important information for the player to have. At the moment only the most recent level up is visible but later I plan to set it to show the last three or so updates if several stats level up at once.
After seeing how some things went with the last playtest and seeing other people’s games I realized I should probably add some screen to at least show the controls and that ended up spiraling into a pause menus showing your current level at each stat. It does also show the controls of course but later I plan to migrate that onto a start screen.
The final main thing I worked on this last week was actually setting up a level for this playtest. For the longest time I’ve worked in a small test space I made just containing the player, a few platforms, and one enemy since that was all I needed. However that wouldn’t really cut it to show off what I’ve been working on all this time so I spent a while making a larger level to play around in. In order to actually show the attacking and blocking stats I added more than one enemy and added some spawners to create more of them as needed. The rest of it was messing with platforms to create a decent sized space to run across. By the time of the next playtest I’m finally going to have the procedural generation working well enough that I don’t need to handcraft the testing area and everyone can see something a little different at least.
This week was originally planned to be all about starting procedural generation but things didn’t exactly pan out as intended. Given that it’s meant to be the main mechanic of the game and all, I wanted to spend more time focusing on the leveling system and tweaking the values for how quickly the skills level and how much impact each individual level has on the player. I also spent a chunk of time redoing part of my code pertaining to how the levels are stored so it would be easier in the future to add more skills and quicker to check which skill is being referenced by other methods. This was mainly just me making my work make a bit more sense by throwing the level, current exp, and exp to the next level up into arrays rather than keeping a stockpile of individual variables. That may have worked for a quick demo for one skill but it really wouldn’t work for a more finished product. So most of my week was spent on working on those values and figuring out which values for some behaviors should be modified by level. The main one that took the most fiddling was the attack stat. Compared to most of the other stats there were multiple values that could be controlled by the level: attack damage, attack speed, and attack range. I spent a good amount of time experimenting with different levels of modification to each of those values. In the end I decided that by default the attack stat would only affect damage but later saved up levels could be spent on the ability to either flatly increase the other two or have them also scale with attack level.
In some bits of free time this week I also tackled a minor side goal of getting the camera up and running to follow the player around. Not exactly something important for my testing purposes but a relevant feature for anyone else playtesting in the future since I’d want to make a larger testing environment and not have to zoom the camera out really far. Testing the movement related skills, mainly jumping, required a larger area to test in to really see the effects of any variable changes after a certain point.
The biggest challenge I faced this week actually came from that minor side goal of the camera. Following one guide it turned out that it was either using an older version of Unity or just outright doing it wrong since their directions led to the camera shaking whenever the player jumped and causing generally wobbly view. So to fix this I just started over on the camera and pieced together several different things I found online until I got the camera working and not trying to do anything overly fancy. You could also call that main lesson I learned this week to be starting with the basics before messing with too many features I haven’t tried before. I do want to spend more time in the future if I get through any other tasks quickly playing with the camera some more to try and get smoother movement and to see if I could integrate any features of it into a skill. Potentially some ability to zoom out to see things out of sight.
The leveling system is likely to still need more fiddling in the future as I add more ways to test it and other environmental elements but going forward I plan to start on procedural generation going into this week.
For personal reasons I wasn’t able to get the Lvl:2 log in on time and by the time I could work on it I had gotten enough done that I figured it I could just put the two logs together. Between the two weeks I finished the main skeleton of the game as far as I needed for testing the main mechanics and the later procedural generation. Building off what we had at the end of Lvl:1 the player can now attack and block, though unfortunately the free assets I found to be placeholders didn’t come with an animation for blocking, so I’ll need to add a different visual representation to make that clear until I can make my own assets. There is an attacking animation though so that’s something at least. I also added some basic UI elements, a health bar and a stamina bar, that will come into play with combat and other hazards. Naturally what good is attacking and blocking without something to block and stabberize? So the last main feature of Lvl:2 was adding in a basic enemy to play with/against. It doesn’t do anything fancy but it runs at you, damages you if it hits you, and can be killed through blunt force trauma. What else could you possibly need? With that I think we can move on to the progress of Lvl:3, where we go from the basic skeleton of a platformer and start moving into the actual game. The goal of both Lvl:3 and next week’s Lvl:4 is to begin to implement the leveling system, the core of what I’m actually trying to do with this game. In the future I’d like to add a large number of skills to play with, but at present all I have to report is creating a skill for each of the basic functions of the skeleton. The player can get better at attacking, which naturally increases the damage it does, blocking, which decreases the stamina cost of blocking and later down the line will increase the speed the player moves while blocking, health, which can only be raised by taking damage and will play a much more influential role once there are ways to heal implemented, jumping, which increases height, and move speed which increases, well, move speed. At present there is no upper cap which is how I would want things, so the main thing to play around with is how much things increase per level, and how much needs to be done to level up. In Lvl:4 I also plan to expand the UI elements to show when you gain exp in a skill and when a skill levels up. The biggest challenge of this report would actually be the UI elements as that is the piece of Unity I have the absolute least experience with and going from nothing to trying to make a health bar that actually looks good took a decent amount of fiddling.
Starting off the first week of development we got to work on the skeleton of the game. There are still more goals for this first sprint but for the first week I wanted to just get the player moving around and get a better sense of how to use tilemaps in 2d Unity.
The absolute first thing I did was go on the asset store to find some free placeholders to use for the time being, all I wanted to start was a basic set of platform tiles and a player character so I wouldn’t have to use a rectangle for the foreseeable future. Fortunately I found both without much effort, including a player sprite that came with some basic animations like walking and jumping along with things I want to use in the future like attacking and blocking. I still plan to use my own assets at some point in the future but having this to make things look correctly and just to make sure everything works is very helpful. After that I set up a basic character controller script to just facilitate movement, jumping, and crouching. I plan to expand it greatly once I get further into development, mainly during sprint 2 when the leveling mechanics are implemented. So the last step I took this week was learning to set those animations up. It was my first time using an animation controller on Unity so it was interesting to see how little code was involved in that process. I always thought the animations were queued up in the scripts but all that needed to be included there was a few variables for the animation controller to read.
The biggest challenge I faced this week was just getting back into Unity and learning how to use the 2d elements I hadn’t done much with in the past. For the most part all of my Unity work was in 3d and while a lot of the structural elements carry over there were things like tilemaps and sprite sheets that I had worked with before but never had to implement myself.
A good amount of time was spent this week on research on how to do much of what we wanted to do. Fortunately there was no shortage of resources online for this between articles and video tutorials on individual components of unity development. The best lesson I learned this week would just be how specific of resources and guides we could find. I knew there was a trove of information out there but I was still a bit surprised to find something so specific as to “Melee attacks in Unity”. I plan to take great advantage of these resources in the future, especially as I come to more and more complicated processes. Beyond that the main things I learned this week just feed back into learning more about 2d Unity. I had some degree of understanding before going into this, mainly with the initial demo the previous semester, but getting a refresher on some of the most relevant components was very helpful.
Welcome to Lvl: 9999, the Devblog for the game of the same name. The goal here is rather simple, just to document my progress over the course of the semester and hopefully beyond.
To start off our first post here let’s go over what exactly it is I think I’m doing here and how I want to get from point A to point Z. Lvl:9999 is to be a roguelike platformer where every single action the player takes can be leveled. Everything from attacking, blocking, jumping, crouching, to even dying will be an individual stat that can be raised to stupid levels. Grinding for these levels will be tied into the core gameplay loop, needing to reach certain points to access different points of the levels and allowing different methods of play.
My goals for the semester are to start by getting the bare skeleton of the concept set up, with a number of levelable skills, some enemies and traps to interact with/die to, and to then spend the majority of the semester learning and implementing procedural generation. I expect that to take the biggest chunk of time just as I’m starting from zero there.
By the end of the semester I hope to have the procedural generation working to a degree that it can at least create a series of randomized rooms and enemies with sections blocked off until certain skill levels are reached. That being said I would want the demo game at least to be beatable without an unreasonable amount of grinding given the presentation format, so much of the level will probably be structured to show off the leveling mechanics without needing to dedicate too much time for it. Ideally I’d like to have a boss at the end of the run but that will depend on how much else I can get done before that point.
Compared to the typical roguelike game I plan to add in the option to keep some amount of your progress from previous runs, to allow some amount of gradual process rather than just trial and error. This will be done through the aforementioned ‘dying’ stat; the more one dies the higher that level gets and its level determines how much of the previous run’s stats you bring over to the next run.
The other use for levels after a run is completed will be trading. Your leftover levels you don’t get to keep after a run will become your currency to prepare some things you can’t grind for for future runs. At present this is planned to be equipment, shortcuts to later floors, unique skills that aren’t tied to a stat, and maybe even new stats to level in the future.
I hope to keep working on this project even after the semester is over so there’s much more I’d like to do after reaching these goals. This would include, as mentioned above, adding bosses, a wider range of enemies and rooms, and further expanding the level trading system.