Frostbitten Devlog
Devlog #5 - More Battle Animations and Code Restructuring
Hello everyone, it’s been a while! There are a couple of reasons for that: I got sick yet AGAIN (probably the 5th time this winter), I spent a lot of time doing “invisible” updates to Frostbitten which aren’t easy to show off and finally because life can be unpredictable sometimes (lol). Anyway the only interesting thing to show off today is a new status animation I made but I will pair it with an explanation of the changes I had to make to the game’s code to implement it.
Anyway, first things first. Have a paralysis animation:
(I’m testing all of the status animations on the bleed status haha)
This animation is part of a new system I implemented which allows animations to be more complicated than single sprites! Actually, it was already partially implemented before now but I’ve added more variation to what’s possible. For example: my new system allows animations to be drawn as overlays on top of enemy sprites, something I am using for status up and down effects (think pokemon). This update is not the restructuring I was talking about, though.
When I started thinking about adding these animations into the game, I realised my battle system, as it was, was not very new-feature-friendly and that it would be somewhat difficult to add new features without some kind of change to the general system. You have to understand, the old system was like a trusty old car that had broken down and been fixed several times over so it wasn’t exactly compatible with the newest gadgets. Anyway, the simplest solution was a major restructuring to allow additions to be easier in the future, and that’s what I did.
So, in order to understand the restructuring, I have to first briefly explain how the old system worked. In both the old and the new the vast majority of game logic and rendering is handled by a single object called “battleController” (if you’re unfamiliar with how GameMaker’s objects work, think of it like a class in another language). This object had a bunch of events (sections of code called under predefined trigger points that are automated by GameMaker) that controlled the flow of combat. I’m sure in the beginning this seemed like the simplest way to do things but as time went on and I added more and more features and the different ways that the state of combat could change was not handled very well. They were quite messy. Plenty of very specific outcomes were hard-coded into events rather than represented by a more dynamic system (as you can see in the image above, some of the functions I defined had comments noting that they corresponded with 2 object events, which is only the beginning of the messiness). Due to this, if I wanted to add something as simple as another point in which an animation played, I’d have to create a brand new event or some other way of representing it and slot that in to what was already there. Without realising it, I had created a nightmare and I knew I had to change it before I moved on. Enter: the new system!
It’s not very complicated or clever but it is very effective. Any discreet state that combat can be in is represented by a “phase”. These phases are defined by functions and the battleController can move from phase to phase freely and dynamically. The phases themselves are also far more generalized. E.g: instead of an event that handles specifically the animation of a specific move, now there is a generic animation phase which can animate anything at all (The “animate_status” phase above sets up the generic animating phase so I suppose its actually more like a hybrid approach lol). And if you want to insert another animation phase in between the flow from one phase to another, that’s completely possible without having to change anything else. I think it works somewhat like those animation flowcharts often used in 3d games with lots of different animations that flow in and out of one-another. Anyway, yay status animations! They get slot in at various points depending on the status (if paralysis stops you from moving, its animation plays at the start of the turn, if bleed deals damage, it plays its animation at the end of the turn, etc). This new system will also make it very easy to add in any new combat phase I might want at any point in the future. To be honest, I thought I had already completed the engine aspects of this game but I suppose you don’t always realise what it is you need until content creation forces you to. Perhaps when I start creating level designs for future levels, I’ll realise there’s something missing from the exploration part of my engine (let’s hope not haha).
That’s all for now! Next time: probably more animations, they take forever :’)
Devlog #4 - Battle Animations and Minor Additions
Not much to say this week. Just lots of animating and adding moves into the game. Here’s a showcase:
(Sneaky mouse lol)
I lied, I actually do have some things to say. SFX animation is really hard! Actually all animation is hard and SFX animation might be a little easier for me personally than animating say, the walk cycle of a wolf. But when animating something real - as with drawing it - its easy to take inspiration from real life. I find animals and people much easier to draw than creatures from my imagination for this very reason and struggle with monster design. Similarly, one might imagine me struggling with organic animations. Regardless, animation is a new skill for me and it takes a lot of concentrating and trial and error for me to create something at a standard I can stomach. I think these results are fine but I would like to improve my skills further to make things that look even better!
For an interesting little tidbit: 2 out of these 6 animations had components animated via code rather than manually - is it obvious which ones? Yeah, animating lots of lines moving in a singular direction can obviously be achieved very easily with some simple code! So the lines moving toward the center in animation 3 (not the outwards moving, er “spikes I suppose you’d call them) and the outward moving lines in animation 6 were handled via code. This made the process relatively pain free! I’m also planning to do some animations dynamically, via a particle system for example. The end results should still be true to the graphic style of Frostbitten but doing them via code means I can play to my strong suits and cut down on the time it takes to complete animations - which is a lot! Although surprisingly not as much as I would have thought going into it.
Just like pixel art in general, working at relatively small resolutions takes some of the “guess work” out of the artistic process. There are only 192 x 192 positions to put pixels after all. If I want a shape to move in a particular direction, there are only so many choices I can make for that. Working at higher resolutions makes this a little muddier. But at the same time, minor mistakes are less noticeable. You could debate it. For me I prefer small resolution work! Haha.
Anyway, once all the animations are done and added in, I’m thinking of planning ahead with some new events too! I’m waiting until August before I start charging forward with level design (for reasons secret for now) so I’m mostly just trying to add as much to the game as I can without actually moving ahead in terms of playable content too much. By August I will tell you why this is but for now, look forward to some new event images next time!
Devlog #3, Temperature and Other Additions
So, as I mentioned last time, the next feature I wanted to implement was some kind of temperature system, and that’s done now! Essentially, the way it works is that depending on where you are on the map, your location will have a certain temperature value, indicated by the bar on the left on the image below.
However, simply walking into a cold area will not immediately reduce your own body temperature, instead it will reduce gradually the more you explore colder areas. And of course certain kinds of armour will reduce the impacts of the cold to make it easier to explore cold areas, but even then, some areas will always be too cold to explore for very long.
Finally, staying in the cold for too long will give you the eponymous status: Frostbitten! This will have various affects and is something you’d really rather avoid in most circumstances. I have also coded in heatstroke as an opposite ailment however given the nature of the game, I don’t think this status will show itself very frequently. I do have some plans for it though.
Other than temperature, I have mostly been adding small updates over the last week or so. Here’s a list to keep you updated:
-Over-encumberment effects have been added - as, before now, being over-encumbered didn’t actually do anything.
-The way players and enemies take movement turns on the map is now more dynamic so that different entities can move around at different speeds.
-Skill Levels have been added to the skill tree, which is mostly a future proofing addition for now but you can upgrade some of the existing skills.
-The way HP and damage works has been changed slightly (although this will mostly be invisible on the player side of things).
-A status buildup system has been added so that repeated attempts to inflict the same status in a row increase in likelihood.
-And finally, TONS of glitch fixing around statuses and a change to how stamina cost and recharge works (to allow statuses and skills to affect them more easily)
I have also spent some time planning out a bunch of new skills to implement into the game which is planned to be my next big adventure. I’ll also be looking to add more battle animations so hopefully, by next update, I’ll have some visually interesting things to show off. All this is in favour of building a solid base to play around with as I move forward into level creation and enemy design, but we’ll get to those things in due time.
Until next time,
-June
Devlog #2 - New Demo Release!
Frostbitten has a new demo in 2024!
There’s not a lot to show this week unfortunately, or perhaps not unfortunately, because I’ve spent the last 2-ish weeks heartlessly crushing bugs under my boot in order to bring you all this new demo!
It’s been over a year since the last one and with one released project under my belt and a shiny, brand-new perspective, I wanted to bring the game up to a new standard. For any stragglers who’ve somehow managed to hold out for this project since PGF 2022, this new demo is pretty much exactly the same in terms of content as the old one, so don’t flock to it expecting some new juicy hints to the mystery. Instead it is a smoother, more stylish and more bug-free foundation on which I can build what I am confident will be, a fantastic game. If you want to re-experience Frostbitten with a new coat of paint, this demo is for you!
For those of you who have never played before: now’s your chance! This game is a fusion of several ideas and as such it can sometimes be hard to explain to people. Give the game a play for yourself and I’m sure it’ll “click” with you! After your done, feel free to let me know what you think. All feedback is good feedback and is greatly appreciated.
So what’s next? Well - remember those new survival mechanics I mentioned last time? Yeah I should probably get on those now.
Devlog #1 - UI and Texture Updates!
For those not in the know, Frostbitten was a game I started making in early 2022 inspired by a particular mobile game I had been playing on the long bus ride to my partner’s house as well as classic dungeon crawlers from my childhood (especially Shin Megami Tensei). I displayed Frostbitten at PGF 2022 and had great success and lots of positive feedback! It was at that point I finally considered following game design as a career option, something I had been interested in since I was very young but always assumed wouldn’t be possible for me. Due to the ambition of this project however, I decided to spend a year working on a project with a smaller scale to hone my skills and especially learn more about the game development process but unfortunately this lead to Frostbitten being put on hold. Now, over a year later I have finally returned with my newfound knowledge ready to bring the projects original vision to life!
I’ve spent the last 2 weeks or so preparing Frostbitten to move forward in development but before that could happen, I wanted to update a lot of what I already had to fit in more with what I have in mind for the project now. The first of which was upscaling all of the existing textures!
The first Frostbitten devlog is finally here! And its a long one.
For those not in the know, Frostbitten was a game I started making in early 2022 inspired by a particular mobile game I had been playing on the long bus ride to my partner’s house as well as classic dungeon crawlers from my childhood (especially Shin Megami Tensei). I displayed Frostbitten at PGF 2022 and had great success and lots of positive feedback! It was at that point I finally considered following game design as a career option, something I had been interested in since I was very young but always assumed wouldn’t be possible for me. Due to the ambition of this project however, I decided to spend a year working on a project with a smaller scale to hone my skills and especially learn more about the game development process but unfortunately this lead to Frostbitten being put on hold. Now, over a year later I have finally returned with my newfound knowledge ready to bring the projects original vision to life!
I’ve spent the last 2 weeks or so preparing Frostbitten to move forward in development but before that could happen, I wanted to update a lot of what I already had to fit in more with what I have in mind for the project now. The first of which was upscaling all of the existing textures!
In the original version of Frostbitten, I was creating assets exclusively for a cave environment and as such, didn’t have much of an issue with the smaller scale. But when I started moving on to the outdoor environments of later levels, especially textures for nature, I found it more difficult to achieve the fidelity I wanted to have. So I decided to upscale my old textures in order to be able to fit more detail into them and I am glad I made this decision! These new textures make the environments feel much more open and less claustrophobic to me and allow the cross-hatching shader, that I made to emulate rudimentary shadows, look much nicer. However it did take a while for me to get comfortable with the new size when creating textures, hence the middle images above being updated to those on the right. I feel I’ve really gotten the hang of it now though!
Afterwards, I decided to revamp the UI elements as well. But before I got the time to, I made the unfortunate mistake of deleting all the data for the original level 1… (don’t ask me how).
Luckily, I did still have the build I made for PGF which allowed me to still play said level! So I had to go through the admittedly not-as-time-consuming-as-I-thought process of recreating it. I did this by taking screenshots of the minimap at various points throughout the level (shown above) and stitching them together into a level 1 map (shown below).
I then had to go through and label all of the items and events in the level before I was able to finally settle on the finished blueprints.
The finished blueprints are flipped because the level layouts are mirrored in my level editor (due to a small mistake in coding I made early on and decided to just keep in haha.)
After creating this blueprint, recreating the level was relatively straight-forward. Small things like the placement of rocks and stalactites are different in the new version, however, as placing all of those details exactly as they were was not a huge concern of mine.
Finally, I remade most of the UI elements with new designs meant to fit in with the comic book aesthetic that inspired the iconic black and white look of the game (no, I was not inspired by Undertale as some people had guessed). Most of them are shown off below, however the differences in the inventory screen need further explanation.
As it happens, I picked up a new influence in the year or so between the inception of this project and now and that influence is expressing itself through the inventory system.
In the original version, I didn’t put very much thought into how the inventory system would work. I knew I wanted to make a game with survival mechanics but didn’t think about how that could be expressed via the inventory, instead simply implementing a weight system like many other similar games. Enter: Resident Evil, a game series which I fell in love with in the interim of 2022 and now. Influenced by those games, which challenge the player with strict inventory management, I decided to do something similar with Frostbitten and I think it fits the game perfectly!
Carry weight is still a thing but all item types have been synthesized into one inventory rather than the separated “Item, Weapon, Armour” system of the original. The amount of space you have to carry things has been significantly reduced as well (but it can be increased by equipping bags). This makes item collection much more of a gameplay feature rather than having players simply horde huge tons of rocks. It synergizes well with the crafting system as well as it encourages players to actually craft items they need as they can’t carry the ingredients around with them forever.
So what’s next?
Now, we move on to adding new content, starting with some additional survival mechanics (namely a temperature system as well as hot and cold clothing options)! My goal will be to update this blog weekly with my progress, however I might reduce this amount the further along I get, as I don’t want to spoil the game before its released!
See you next time,
June.