Another week, another Monday and another progress update for game development.
Due to outside commitments, I didn’t have as much time to work on Rouge Lives as I would have liked but I did manage to get a few of the things I wanted done.
The first things I added were keys and coins that the player can pick up by moving over them as well as the UI to display the number of keys and coins the players have in their possession.
I’ve also added in a basic loot system where a room of enemies will drop an item when all of the enemies are defeated. I’m planning on applying this to individual enemies this week as well.
I spent the rest of my time last week working on improving level generation as well as generation of the path through the level. I’ve made it so that the entrance can be on the left side of the dungeon as well as the bottom. In addition, the boss room can be anywhere as long as the room is further than a set value (currently two squares).
Side entrance
For generation of the path through the level, I’ve been trying to improve my algorithm to guarantee a path is found. Currently it looks for all the possible neighbors that aren’t already on the path and then selects one randomly.
If it fails, it goes back and chooses another neighbor and if it fails entirely, I’ve added in a function that looks for the shortest path between the entrance and the boss. Currently, that can fail to so I’m in the middle of figuring out what’s wrong with that. I’m considering removing the end of the dungeon room and putting any end of level loot in the boss room.
Well, I think that’s it for this week. I’ve got a lot to work on for the next week so make sure to come back. See you then.
Happy New Year! I know it’s a bit late but I’m finally back. It’s time for the first update of the year.
You may have noticed a certain word missing from the title. That’s because as of the first of this year, I’ve decided to put PrincessCape on hold as I work on other projects.
I had a lot of fun improving on the version I had created in grad school. I added in a level editor that worked both in the Unity Editor and in the game itself allowing me to create and test much faster than before. I also updated my cutscene code allowing me to have multiple things going off at once. Showing all of this off at GDC and getting feedback was a really good experience.
I like what I’ve got but I feel I’ve got too caught up in getting certain parts of it perfect that I’ve neglected to develop content for it. I feel like I lacked a clear direction on where I wanted to take the project so I just wound up spending too much time refining things that were already functional. That’s why I think I need a fresh start for this year so I’m moving onto other projects.
I’ve mentioned another project I was working on Rogue Lives in my last post. The idea is kind of a Zelda-inspired roguelite where each run is the life of a legendary hero attempting to defeat the big bad gathering soul power to get stronger with each new life.
I’m currently working on getting the procedural generation of basic dungeons working. It’s at the point where it can generate rooms, connect them and add enemies to certain ones.
I plan to add in locked doors and keys along with item drops from defeated enemies so the player can refill ammo and gain money during a run. After that, my plan is to work on the upgrade system and finding a way to make the game slightly more challenging to keep it from becoming a cakewalk.
I’ve also begun working on another game idea. It doesn’t really have a name at the moment. It’s a competitive platformer kind of like Duck Game or TowerFall Ascension where each player has a grappling hook that they can use to pull objects and move themselves. I’ve been working on the very basics of the grappling hook mechanics and I think I’ve got a very basic working.
As I expand that, I’ll also look into the elimination mechanic. I currently like the idea that all the players are rival thieves/spies after the same item and by dragging an opponent into the light, they get caught and eliminated and you win by being the last one standing or the one to retrieve the McGuffin and get out.
I don’t really have any links to show off my work yet but I hope to have some more updates on my work next week. I hope to see you then.
Welcome to the final update on the development for PrincessCape for 2018. I hope the year’s been good for you and the rest of it and all of the next are good too.
This week was a lot of relatively minor fixes mostly centering around the camera and centering it properly around the player. I changed how camera panning works to use a timer and made the camera follow the player’s current position rather than their old position. I also fixed an issues that would cause the camera to jitter when the player would move between floor tiles.
The cause of another camera error was an issue with how the cape handled activating and deactivating while on the ground. It used to be that the cape on deactivated in the air or when the player hit the ground. If the player activated the cape while on the ground and deactivated it, it wouldn’t be registered as deactivated meaning the camera would follow as if they were floating the next time they jumped. I removed the need for the player to be in the air and that took care of the issue.
There wasn’t much else this week so I’d like to take some time to talk about two other projects I’ve been working on recently.
Let’s start with a game I’m working on for the Extra Credits Holiday 2018 Game Jam: Two Weeks Until Christmas. This jam started on Thursday and ends tonight at midnight (or tomorrow morning at midnight if you’re me and want to be all technical) and the theme is ‘Present’. I ran with that and took some inspiration from real life and came up with the idea of an unemployed game developer (sounds familiar) volunteering at a gift wrapping station to earn tips to pay for gifts for his family.
The gameplay is fairly simple. Customers come up to you with their orders like “I’d like a doll wrapped in brown paper with a red bow” and you open the menus on the left and click on the item you want to make it appear on the table. Repeat for the wrap and bow and then drag everything together. Make sure to put the wrap on before the bow and then hand it to the customer. Repeat for any other items the might have ordered and when you’re done, you should receive a tip that you’ll use to buy presents. Keep doing that until the end of the day and you’re sure to have enough to get a great gift for everyone!
I know. It’s beautiful. I can’t believe I made it myself.
After that, you stop by the gift shop to buy presents for your family and girlfriend. There are four different presents at four different prices for each person and each gift has a different set of description and results.
Oh man, ‘Item Name’ for only ‘Price’? I’m in.
This repeats the player buys gifts for everyone or Christmas day, whichever comes first though the player can choose to keep working if they want. New options for gifts, wrapping paper and bows are added as the big day gets closer and as people get more rushed to get things done, they start bringing in more gifts to get wrapped. But the bigger challenge means a bigger reward as well. Can you get all the best gifts for your family? Play and find out. (I should have it up on Itch.io by the end of the day. I’ll make sure to come back and put a link for it here.)
Finally, I believe I’ve mentioned another game I’ve been working on but never really shown. Well, here’s an early gift for you.
The game is currently called Rogue Lives as I try and think of a better title. It’s a roguelite game inspired by the classic 2D Legend of Zelda games.
You play as the mythical Hero destined to defeat the big bad evil guy. You were foiled in your first attempt but the forces of good have reincarnated you to finish the job. With all of your stuff gone, you’ll have to journey through a series of procedurally generated dungeons and acquiring the magic treasures within. Each time you die, you reincarnate and must begin your adventure anew. However, with each life, your soul power grows allowing you to buy upgrades that will apply to all future lives.
Well, that’s the plan at least. I’m still in the early phases of prototyping it. I’m working mostly on getting dungeons to look right at the moment. Here’s an example of what one looked like in a recent test.
The green room is the boss room and the solid purple room up top is the treasure room at the end.
I’ve got the basics of generating rooms of different types. I’ve been working on making interesting looking water rooms that are still traversable lately. I’ve also got rooms with random monsters that all have to be killed to exit. The one piece I’m still wondering how to due it to make puzzles. I might make a few stock ones that can just be added to regular rooms but I’m interested in finding .a way to due them entirely procedurally.
And, if you’re wondering “Why does this look so much prettier than PrincessCape?”, the answer is that I started working on this to make a game using entirely art assets from the recent Humble Game Art Bundle. While most of the art was made for RPGMaker games, I’ve found it works just as well for this kind of game in Unity.
I’m definitely enjoying making this and as it gets closer to a state I feel like I could show it in, I might shift my focus to it instead of PrincessCape at least until I can find (and afford) an artist that can do the style I want for that game.
Well, that’s it for this update and this year. I won’t be back until January 7th so have a happy holidays. As always, you can check out the most recent updates to PrincessCape on GitHub and download the most recent demoes on Itch.io.
It’s Monday again so it’s time for another update on the development of PrincessCape.
My goal for this week was to get a new demo for the game up and running and that meant finding a lot of bugs I didn’t know were there before.
After fixing an issue with dialog last week, I discovered that there was an issue which caused the dialog boxes to stay visible after the cutscene had ended. In addition, I fixed an issue that caused cutscenes to play twice by adding in a variable to cutscene trigger which tracks whether or not a cutscene had been played already.
With that done, I started out trying to make new levels using the level editor and discovered that I was feeling restrained in the small window. I thought I had added in zooming based on mouse scroll before but I apparently hadn’t. I made adding that in a priority and got the basics of it implemented. I might still want to work a little more but it will be in the next demo version.
I also found a few errors in the level editor. It was possible to accidentally destroy a ladder or other segmented tile object by reducing its number of links to 0. While maybe not a bug, I discovered that there was no simple way to go from using a specific tool in the level editor to using no tool. This was another thing I thought I already had. I fixed it by adding in the ability to press the shortcut key for the active tool to go back to no tool.
With those fixes implemented, I built the game and found there were some errors that only occurred in the standalone version but I had no method of really figuring out what was causing it. The big one I found was that the opening cutscene was not playing. I couldn’t recreate the error in the editor so I had to find a way to find where it was breaking in game. I decided to create a kind of console that I could use to log things as they happened. It can be revealed with ‘~’ and dismissed by pressing it again.
A short demonstration of the tool I used to fix the errors.
I did this for every part of the process of the opening cutscene until I finally found a place where the things I tried to log stopped appearing. It ended up being an error caused by Cutscene Actor’s properties not being initialized properly in the editor. I fixed this and now, I’m going through the process of testing the rest of the standalone version to make sure there are no other major issues before I upload it to Itch.io.
Well, that’s it for this week. I’ll be back next week and then that it will be it for the year. Until then, you can check out the latest updates on GitHub demos (which should hopefully be updated soon) on Itch.io. See you next week.
Well, it’s been such a long time. I think I should be writing an update on PrincessCape so let’s take care of that right now.
I hope the two weeks from the last update have been good for all of you. I had a good Thanksgiving and the week after was pretty good as well.
Work on the game slowed down not only because of the holiday but also because of I’ve been working on another project. It helps me stay productive when I feel like I don’t know what to work on for PrincessCape. I’m hoping that I might have enough to show off after the new year.
But that’s an entirely different matter. Let’s get back to PrincessCape. I’ve update some of the sprites in the game using ones from the recent game art Humble Bundle. They’re not really the style I’m looking for but they’re closer than the crude programmer art I have.
I know it’s hard to tell which is mine. It’s the one in the middle.
I’ve also made more fixes to the cutscene and cutscene editor script to make it easier for elements of the cutscene to get the objects they are affecting. There was also an issue with the dialog not being properly displayed when a cutscene started.
I will need to do a few tests of these fixes to make sure everything is okay and then, I’ll move on to developing new levels with a new focus on using the things I haven’t used yet like keys and locked doors. I think this will bring the game in a different direction and I’m excited to see where that goes.
Well, that’s it for this week. It wasn’t much but it definitely felt larger than that trying to fix it. I’ll try to have even more ready for next week. Until then, you can check out the latest updates on GitHub and download the latest demos on Itch.io. See you next week.
It’s Monday.Somehow, the fact that this is the week of Thanksgiving eluded me but as promised, here I am with another development update on PrincessCape.
As predicted, this week once again focused on the development of the cutscene editor from previous weeks. As with last week, I spent this week trying to remove as many editor only classes as I could while still keeping everything understandable both in code and in editor.
Over the week, I removed the CutsceneElementStruct struct and replaced it with creating an appropriate CutsceneElement and populating it to pass on. I also removed the cutscene info class which held all the information for the cutscene in the editor and moved its properties and functions into the base Cutscene class so cutscenes now store the scene in which they take place, their name and allow for saving to JSON and plain text.
This led to a few problems with game classes needing to access variables and function that were originally in editor classes. Luckily, I was able to move most of these to the cutscene as well and the things like functions and variables that answer “is this actor in the scene?” definitely feel more like they belong in the actual cutscene class than the editor.
I also fixed a few more bugs that had popped up. Many of them seem to be related to my incorrect assumption that there would always be a gameobject in the scene matching the name passed in. I knew it was wrong at the time but forgot to program for another case so I had to add that in. I also somehow forgot to add Cutscene Enable to the switch statement that creates elements in Cutscene Parser.
I don’t expect to make any updates over this week but as always, you can check out the latest updates on GitHub and download the latest demos on Itch.io.
Well, that’s it for this week. I’ve got holidays to prepare for. I hope anyone celebrating any this week has a good time as well. I don’t expect to have an update so have a happy Thanksgiving and see you in two weeks.
Well, it’s that time of the week again so it’s time for another update on the development of PrincessCape.
Last week ended up being a much busier week than I had intended so I didn’t have nearly as much time to put into development as I wanted. However, I did manage to finish integrating the Cutscene Elements directly into the cutscene editor instead of having classes just to display and store them in the editor. I’ve done my best to make it look just like it used to while also making sure to get GameObjects directly instead of names to make it easier to visualize things.
I also renamed the functions for saving cutscene elements from SaveData for JSON and HumanReadable for text to ToJSON and ToText. I don’t really think I need to explain which does which. The functions for loading have also been renamed to CreateFromJSON and CreateFromText.
The cutscene element base class now has a function called CreateTimer to simplify the creation of times and make sure they work the same across all elements.
That’s it for this week. I apologize for not really having a lot new to show off for the last few weeks. The work on the preview is going along well and I should hopefully be able to show it working next week.
As always, you can check out the most recent updates on GitHub and download the latest demos on Itch.io. See you next week.
Welcome back, everyone. I hope you had a happy and safe Halloween. Now, it’s time for another update on the development of PrincessCape.
I hit a few unexpected roadblocks this week so development is going a bit more slowly than I had expected. I spent all week continuing development on the Cutscene Editor especially getting the ability to preview scenes straight in the editor working.
One of the first things I did was squash a few issues related to saving and loading the game level the cutscene takes place in from the file. For whatever reason, the variable that stored that information in the editor wasn’t being set properly. That was a quick fix. In addition, I realized I hadn’t added the functionality to the JSON files and that was fixed just as quickly.
With those done, I finally got to move on to getting the preview up and running. This was about as complicated as I expected. First, I had to write code that would allow me to skip over any previous steps in the cutscene so that all the elements would be in the proper place and state. This was fairly easy and some elements like dialog could be ignored completely and things like movement could be handled by just doing it instantly instead of over time.
Speaking of time, that ended up being one of the tougher elements for me to figure out. Ultimately, I decided to create an alternate to the TimerManager that runs in the editor as a MonoBehavior. Timers now have checks to see if they’re being run in the editor and if they are, they reference the new manager instead of the old one when adding/removing themselves. Nothing has changed for classes outside of Timer.
One of the problems I was having with cutscene preview and development in general was that the game’s UI would block important things in the level meaning I would have to deactivate it when I started working and reactivate it when I was done. I think I finally found a solution where the UIManager runs in the editor and when it does, it deactivates all of the parts that block my view and reactivates them when the game starts playing.
Finally, the biggest change this week came on Friday afternoon when I decided that I didn’t need CutsceneElementEditors so I would just move all of my editor code to the Cutscene Elements themselves. I thought it would take like 30 minutes. It took about 2 hours before I even had code that didn’t give me errors but I don’t regret it. I think this will make saving and loading the elements a lot easier to coordinate along with making sure that they run consistently between editor and game. I still need to put some more work into this to make sure everything is working fine so this will be the focus for the first part of this week.
Well, that’s it for this week. As always, you can check out the latest updates on GitHub and download the latest demos on Itch.io. See you next week.
Welcome back to another PrincessCape development update. Let’s get right into it.
This week was entirely devoted to improving the cutscene editor. The first set of issues I fixed were all related to the structure of the text files that contained cutscenes. To put multiple events into one step, the word “and” is added to the end of the command so something like “move-x Elwynn -2 1.5 and [newline] Elwynn: Kidnapped by another dragon?” would simultaneously move Elwynn to units to the left and display the line along with a textbox attributing it to her. This caused problems with parsing because for some commands that have variable lengths, I would get the last element by doing “arrayofelements[length – 1]” and I forgot about the possibility of that being “and” so I had to go back in and make checks for all of the areas where I used that.
As I was working on making sure text cutscene files were loading properly and using the opening cutscene as the example, I was frustrated at how difficult it was to view some of the steps towards the end even though I had made steps collapsable. To remedy this, I added in a scrollbar to allow me to scroll through all of the steps while also keeping the important scene information on top.
Speaking of scene information, the cutscene editor now keeps the name of the cutscene and the game level at the top allowing for them to be changed directly from the editor. In addition, the name of a text file is used as its cutscene name and the first line of the file will now contain the name of the scene the cutscene takes place in.
I also took a look at how elements are stored in a cutscene. Previously, I had used a list of lists of cutscene elements and looped through them as each one came up. I decided that I liked the structure I had come up with for the editor better and created a new class called CutsceneStep (the editor class previously named that was renamed CutsceneStepEditor) and moved the handling of running all of the elements into it. This has cleaned up a bit of the code in cutscene and helped me find an error that was keeping the opening cutscene from finishing.
Finally, there were a few other minor changes. The game will now load the test scene and change the level to match the one the cutscene’s setting. I’m hoping this will allow for easier creation of previewing cutscenes directly in the editor. I also added in functions that allow the editors to find game objects more easily so I can show them in the editor instead of just their names.
Well, that’s it for this week. As always, you can check out the latest updates to the game on GitHub and download the latest demos on Itch.io. See you next week.
Welcome back to another update on the development of my video game PrincessCape. It has once again been a busy week for development.
Development was entirely focused on the Cutscene Editor and creating a way for it to save and load human-readable text files in the style the original cutscenes were written in. For example, a cutscene that looks like this in the editor
Simple cutscene step in the editor
and like this as JSON
Same cutscene in JSON format
is a lot more easily readable like this in the text file.
And finally, in a text file.
To get saving working, I went through all of the element editors and added in a new property called HumanReadable that as would be expected of the name, returns a human-readable representation in the old style.
Loading was a bit trickier because I wanted all of the old cutscene text files to still be usable in the editor so I had to support styles that aren’t used directly in the editor like “move-x” and “move-y”. Those two examples were fairly simple. All I needed was a check for the presence of “x” or “y” in the first element and replaced the value of the other with 0 when populating creating the movement vector.
Other than that, it works similarly to the parsing of the text files in the Cutscene class just replacing the elements with the editor version.
I also made a minor change of moving all the editors for cutscene elements into the same files as the cutscene elements themselves. This allows for easier lookup of things related to the elements and if I ever change something, I can get to both without having to worry what tab the other is on. While doing this, I also split up elements that had been grouped together like Movement and Rotation into their own files.
That’s it for this week. There are still some issues with saving and loading which I’ll be fixing up as soon as I can. I’ll also be looking into adding the ability to see what the cutscene would look like at that step but that might take longer than this week.
As always, you can check out the latest updates on GitHub and download the latest demos on Itch.io. See you next week.
J.D. Kelly 