Just last week I hit a big milestone – one year of blogging my experiences in developing Ambience! It’s been a really exciting, rewarding, and sometimes frustrating journey so far, and I’m sure that’s set to continue. As I reflected last week, it’s amazing to think how far things have come since I started working on Ambience.
Over the past year I’ve also chronicled many of the biggest hurdles I’ve overcome during my gamedev experience. And so, for my one-year bloggiversary, I decided to go down memory lane and pick my personal top five “Gamedev Grievances”.
This was actually a really hard list to compile, simply because there were so many potential contenders for the top spots! But in the end, I finally managed to pick out five grievances I look back on with pride. (Or dread.)
In Ambience, players have the ability to manipulate weather conditions to dry up rivers, blow away leaves, and open up new passageways and shortcuts. I’m actually kinda proud of how this mechanic opened up so many new gameplay possibilities and made Ambience just that extra bit more interesting to play. That being said, however, it was somewhat of a pain to implement – especially in tandem with my line of sight algorithms (but more on that later.)
Every time I look back on this one, I can’t help but smile wryly (while screaming internally and wishing I could bash my head against a wall). The goal: implementing a new menu system. The problem: activating Ambiences simply wouldn’t work after the new changes. After hunting through my code for a while, I eventually found it by accident: GM:S was treating an integer argument as if it were a string!
What’s even more interesting is that after I published that post – complete with my rant about dynamic typing in GML – I received a bunch of messages from people telling me about all these other programming languages that also use dynamic typing. (Python! JavaScript!) This led to the unexpected, and very valuable, realisation that I could learn a lot from the broader community of game developers as well as from my own experiences.
As an engineering student, I love it when I get to use maths in my gamedev stuff. One notable example was when I was designing the attack animation for characters with hands. I spent a lot of time (and had a lot of fun!) working out how to make the player’s hand travel along the loop of a polar curve. I also varied the angle of the held weapon as the hand swung along its trajectory to make it look more like a vicious slash.
Not only was this really fun to implement, but I’m still using this fundamental code in the current version of the game as it stands now. (And it also showed that the maths you learn at school and uni can come in handy, after all!)
If there’s one thing I keep saying on this blog, it’s: “I Am Not A Pixel Artist!” Needless to say, as a solo indie game developer, pixel art eventually becomes a necessity to get a game up and running. So when I decided it was time to make some new mugshots to suit my new character designs, I decided to document the results and evaluate how I, a non-pixel artist, fared doing my most dreaded past time: pixel art.
The resultant write-up became my most viewed post of all time.
I’m not quite sure why this post became so popular. Most likely, people just wanted to see how I went – or more realistically, how badly I did. The funny thing, though, is that I don’t think I did that bad a job. Even the above screenshot of Zephyr’s mugshot, which I’ve since improved quite a bit, didn’t turn out as horrendously as I thought it might.
In any case, the readers seemed happy, and I was happy. Win-win.
Now, before I announce the number one gamedev grievance of the past year, I also thought I’d draw some attention to another very popular post:
Though not a Gamedev Grievance, I thought this post also deserved to be on my list of highlights. At first I always found it a bit weird telling people that I’m an indie game developer, but over time I’ve come more to terms with that idea and am more comfortable talking about it. You can read more about it in the original post (link above).
Now, without further ado, the award for number one Gamedev Grievance goes to…
Oh, man. This thing practically gave me PTSD – especially when it came to the days and weeks of debugging that followed.
The aim was to design a line of sight algorithm that could reliably deal with non-rectangular rooms in dungeons. I eventually came up with an algorithm that worked by drawing expanding concentric rings around the player, which generally worked okay…
Okay, that is, with the exception of a million bugs and some very strange results that appeared in room after room after procedurally-generated room…
And then, when I implemented dynamic terrain and had to work out a way of integrating it with the line of sight algorithm, things became even messier…
Procedural generation can be both a blessing and a curse. It’s a blessing when it gives the player a huge range of different scenarios to handle, keeping gameplay fresh and exciting (and also making the whole “level design” thing much easier). It’s a curse when it gives the player such strange results that gameplay becomes confusing, frustrating, and at worst unplayable.
As the game developer, the power of proc-gen is in my hands – and with it, a great and terrible responsibility has fallen on my shoulders. That responsibility is, simply put: “Don’t mess up.”
It’s harder than it sounds.
Rhombus Game Dev 