Power Surge ~ Ludum Dare 39 (Running out of Power)

Game: Power Surge
Event: Ludum Dare 39
Platforms: Windows (planned to be expanded soon)
Source Available

Last weekend was everyone’s favourite orgy of sleep-deprived video game development. That’s right, Ludum Dare rolled up in town once more and I couldn’t resist taking part. This time round it kinda crept up on me as I wasn’t aware it was happening until a couple of days prior, but luckily I was free to take part.

The theme for this one was “Running out of Power”, which, of course, spawned several games about electrical power. I’m one of the unoriginal people who did the same thing. Introducing, Power Surge!

ld39-screenshot-4.png

The premise for this game is rather simple – the main generator’s output is slowly falling, and it’s your job to operate three different power generation stations to keep those sweet, sweet kilowatts flowing. Those three power generators each constitute a minigame requiring different kinds of mouse control.

Wind Turbine

The first game involves spinning an eco-friendly wind turbine round by rapidly spinning your mouse around it. So far, the feedback on the Ludum Dare website has been praising the graphical style, especially the background scenery. The depth of field effect emphasises the focal element of the scene, i.e. the turbine at the front of the scene – @maybelaterx says it’s “low poly done very well, and the depth-focus made it all the better”.

However, he also says “I would have liked more feedback on wind power generation”, due to the indirect nature of how the turbine reacts to your input, Rather than spin 1:1 with your mouse input, a torque is added proportional to the amount of spinning you do. That means it’s sluggish to start up and resists slowing down. During the competition, I aimed for the latter effect but did not want the former; I was unable to get the mechanic working satisfactorily in time and decided to move on rather than spend too much time on it.

ld39-screenshot-3

Coal Power

The next game gets you to tear down walls of coal by clicking them with your imaginary pickaxe. Gameplay-wise, this has been the most popular game so far – @thesand says “I really enjoyed the coal mining, there was something [satisfying] about it” and @loktor remarks “I liked the mining part the most :)”. I’m inclined to agree, since I spent far too long mindlessly clicking through the mine while developing and testing the game. It’s the game I spent the most time on, and I believe it shows in the final product – it’s the mode with the fewest gameplay issues.

I think its enjoyability stems from the same vein as games like Cookie Clicker and almost every RPG ever; there’s something psychologically pleasing to watching a number increase because of your actions. It’s a form of operant conditioning – a Skinner box – which is a widely-used psychological phenomenon used to make games more addictive.

This game also requires refinement, however. @thesand “clicked every single coal until [they were] 100 meters down”. Clearly, I need to mention that you can just click and drag over coal to mine it! Even better, I may make it so you merely have to mouse over a coal piece to mine it to avoid causing players muscle strain, or at least include that as the default option.

ld39-screenshot-2.png

Nuclear Power Station

Personally, I think this is the weakest of the three games. It’s the final one I developed and I think you can tell it had the least time put into it. All you have to do is click the inactive uranium sticks to make them glow again. On the left-hand side of the UI, there are eight bars that show how depleted each stick is. Unfortunately, I also forgot to modify the “tutorial” for this minigame; while the other two games have messages that appear when you are inactive for 5 seconds to nudge you into the correct action, this one has the message for the Wind Turbine minigame copied over by mistake, as you can see in the above screenshot.

This caused some confusion. @thesand “didn’t really understand the nuke power”, mostly due to the incorrect tutorial information, while @maybelaterx deciphered how to play the game but thought it was “by far the easiest”. This minigame, more than the other two, would benefit from a more difficult mechanic. Given it is a nuclear power station, a higher level of difficulty also makes thematic sense. @maybelaterx suggested that I “could make it more challenging by focusing on the precision of the task, maybe disposing and replacing the rod without touching any of the other rods”. I think this is the kind of gameplay I’ll aim for in my post-competition version.

ld39-screenshot-5

General feedback

Each of the minigames is a source of shiny gems, which currently act as a points system. Problem is, they don’t do anything apart from sit there on the UI. While the effect is nice – they rotate, with a black border drawing attention to them – they don’t have a practical use, and a few players picked up on this. @wevel “wasn’t quite sure what the gems where for, other than a score system” and @loktor “didn’t really get what the gems were for” either. What I’d like to do is implement a sort of shop for them, so you can buy upgrades for your power generators. I’m not sure what for the upgrades will take yet, but they will likely involve faster energy generation or increased energy caps (each game produces a maximum of 360kW right now).

@milano23 hit the nail on the head though – he “liked the different games” but thought they “became tedious after a while”. I agree. They don’t have much depth (apart from the Coal Mine, it literally has a depth counter) so it’s difficult to invest in each of the minigames. What they really need is a hook – a reason to keep coming back.

This game might work better as a mobile game that you only need to visit for 5 minutes every few hours. It mirrors pretty well how a game like Magikarp Jump works; in that game, I spent a couple of minutes every now and then just hoovering up berries that had spawned and doing my three rounds of training. I’d just need a reason for the player to want to keep their power flowing.

What I’ve learned

Low-poly 3D models have rapidly become my aesthetic of choice, with visually-pleasing results. It’s a style I adopted for my Ludum Dare 37 game, Chemical Chaos, and continued for my last game, Aerochrome. While it was mostly a necessity for LD37 since I wanted to try 3D and didn’t have the time to make high-poly assets, it was a conscious choice for this game jam. I think it’s a style I’ll try to develop in my next few games, too.

ld37-03

I’ve also learned that focusing on a small number of simple games tends to lead to better results in game jams than focusing on a single large idea or more complex minigames. Chemical Chaos also had three different minigames, but they tended to be too complex, especially Flame Test. If I’m to do a similar compilation of smaller games, they each need to have simple and obvious control schemes and rules with immediate and tangible feedback – that’s why Wind Turbine and Nuclear Power Station were harder to understand than Coal Mine.

I think this game has a solid foundation and most of the work to be done is refining the gameplay and expanding the feature set – adding a shop, for example. Apart from that, most of my effort for the post-competition version will be adding detail to the environments.

If you took part in Ludum Dare, do give my game a go and leave some feedback when voting – I’ll try to get around to playing as many games as I can too. If you didn’t take part in Ludum Dare this time around, feedback would be appreciated anyway, even if you can’t vote!

Advertisements

Aerochrome ~ #1: WGD ‘Rainbow’ 48-hour Jam

It’s been a long while since I’ve posted anything, but let’s just gloss over that and pretend I’ve been active. More importantly, Warwick Game Design Society held another 48 hour game jam to celebrate the end of term a couple of weeks ago. So let’s delve deep into the game I made for that and assume January to June of this year never happened.

The theme was initially “Unexpected”, but to spite one of our members who perpetually wants the theme to be “Pride”, we made the secondary theme “Rainbow”. Close enough, right? My game opted most obviously for the “Rainbow” side of the theme, as you might see in the following screenshot:

aerochrome_ver01_01

It’s a strange fever dream of colour.

The basic idea of the game is that you control a spaceship and your goal is to fly into all of the Colour Bits distributed randomly in space to complete the (initially greyed-out) rainbow. Initially I went for one of those dodgy control schemes in which the spaceship flies in every direction without any resistance whatsoever, but that ended up being frustrating to play, so instead I made the ship controllable. There are 100 Colour Bits of each colour, so that’s an enormous 700 collectables up for grabs. At least they’re not Koroks.

It’s not the fanciest game I’ve ever made by any stretch of the imagination, but it is arguably complete. There’s even a win condition! I suppose if you fly off into the infinite void far enough and overflow the position vector of the ship so bad that the game crashes, that counts as a lose condition?

aerochrome_ver01_02

Wheeeeee!

The controls are basic – you can accelerate the ship, use its boosters and rotate in all directions. That’s pretty much it! Since I’m writing this days after making it, I can’t for the life of me remember what the controls are, but you’re smart – you’ll figure it out. It has controller support too if you dislike keyboards and mice.

I plan to touch a couple of things in the game up in the coming days; adding a title screen and a few more objects to float around in space are my priorities. I’ll continue to follow and evolve the low-poly style I’ve adopted. After I’ve done that, I’ll put up a download. Hope you look forward to it!

Goodbye 2016, Hello 2017!

It’s tradition for blogs to look back at the achievements and notable events of the past year. It’s been a particularly turbulent one wherever you are in the world and is sure to be remembered for years to come. I keep joking that we’re currently living in the introduction paragraph of some future textbook on historical events; from all the establishment-smashing stuff that’s happened such as Brexit and the election of Donald Trump, to massive achievements in space exploration thanks to NASA’s Juno spacecraft, SpaceX landing a spacecraft successfully and the discovery of gravitational waves, to several horrifying terrorist attacks on multiple countries and countless celebrity deaths throughout the year, it’s easy to see why 2016 will be remembered as a turbulent year. But you can read about all these events pretty much anywhere else on the Internet and I want this post to focus on stuff surrounding game development, as that’s what my blog is for. It’s probably going to be my longest post ever, so hold onto your hats.

Although if you’ll allow me to get political for just a second, I’m pretty pissed that the happiest person this year is Nigel Fucking Farage, the hypocritical, toxic, lying wart. Man of the people my arse.

A review of my 2016

With that out of the way, it’s time to reminisce over the past year of this blog and then look to the future. First off, some boring stats: I posted 21 things this year, including this post. That’s less than once a fortnight, which makes me a liar since last year I vowed to try to post about once a week. Here’s this gem from my “Happy 2016 Everyone” post:

With that in mind, this year I’m going to try to get out one post per week – if not more – so I don’t fall behind and post nothing in a whole month (for example, December was completely dry this year).

This year will hopefully different. I should have enough to speak about, since I try to make a game for every WGD event I can, plus there’s 48 hour game jams such as Global Game Jam and Ludum Dare to give me an excuse to make games. On top of that, I’ll be putting out more posts about Honeycomb Engine which I hope are interesting for you to read. My posts about games should be more analytical and about reflection, while posts about Honeycomb will, for the time being, be technical explanations of the different aspects of a game engine.

Games I’ve made this year

I made or wrote about 6 games this year, which isn’t really that much compared to other years. That’s partially due to the fact I didn’t take part in August’s Ludum Dare this year and I also didn’t make anything for the whole of summer. On the bright side, I’ve had something to show at most WGD events since then, and I also entered Ludum Dare in December. I may as well list them all off here:

Slower Than Sound, for Ludum Dare 34, ‘Two-Button Control / Growing’ (which was actually in December 2015, but I only posted about it in January 2016)

ld34_01

My aim with this one was a simple game in which you fight spaceships one-by-one in a turn-based manner, but thanks to a couple of bugs and confusing turn indicators, the idea didn’t really work. It was difficult to know what you were supposed to do as I had no real tutorial, and the gameplay itself didn’t really make much sense. I think the art was nice, but that’s what took up a lot of the time from developing the mechanics.

Ritual Quest, for Global Game Jam 2016, ‘Ritual’

ggj16_finished_02

The premise of this game was simple: craft elements until you craft a ritual, at which point you’ve won. It takes heavy inspiration from games like Doodle God, with the exception that you can move around the world in this one, once you’ve crafted life. Then you can find new crafting elements in the overworld. Some of the recipes were very contrived, so if I were to revisit this game, I’d add more elements and refine some of the existing recipes with the new additions so they make a bit more sense. I’d also work on the UI a bit, although it was perfectly fine for a Global Game Jam entry.

Tappy Dev, for WGD’s ‘Fuck This’ 48-hour jam

Screenshot_20160324-191950

Because I’m a satirical bastard sometimes, I made a terrible clicker game about making games. I think it’s supposed to mock the repetitive nature of working in the games industry? Or I guess the game names and descriptions are meant to ridicule the games made by some developers. Either way, it’s a game where you mash your screen with as many fingers as possible as fast as possible, watch numbers go up and then every 1000 clicks you’ve “made a game”. Just your average mobile game, then. I made it as an experiment to see how different it is to make a mobile game than a desktop one, as the point of the ‘Fuck This’ jam is to use a tool, language, art style or platform you’ve never touched before. Using Unity was a bit of a cop-out, but at least I tried out mobile game development.

Shifting Dungeons, for Ludum Dare 35, ‘Shapeshift’ (which I also posted an update for)

press-02

promo-dev-03

The idea behind this was that the dungeons would be randomly generated, and the game would describe them as ‘shapeshifting’. Then I went one further and added powerups that morphed the player into different shapes to give them new abilities, but a couple of them were bugged out slightly so unfortunately it didn’t work out as well as I’d hoped. I did manage to get a few different dungeon varieties into the game, and if I were to continue it further, I’d probably try to nail down the fun factor and make the enemies a bit less bullet-spongey.

Ghost Party, for WGD’s ‘Spooky’ 3-week jam

screenshot_02

This one was fun to make, as I made it in just a few hours preceding the presentation for WGD games that week. I also seem to remember not having had much sleep the night before, so it really was a test of endurance to keep going and get it done. The basic premise is that ghosts flood in from either end of the screen and you have to click them, which makes them fall down. But each ghost had a randomised pattern – all followed a sine wave, but some were faster than others and occasionally a ghost would have an erratic and tall movement pattern that took them off the screen. They also had a z-position, so the ones closer to the screen were easier to hit but spent less time on screen.

If I were to revisit it, I’d probably give each type of ghost a unique movement pattern – some would have a sine wave, some would move linearly, while others might zig-zag and some might fade in and out of visibility while moving.

And finally, Chemical Chaos for Ludum Dare 37, ‘One Room’

ld37-01

With this one, I tried to channel my love of chemistry, although I realise that’s a tall order given how much some people loathe the subject. You’re given a series of simple chemistry tests – a distillation, a sodium + water experiment and a flame test – and it’s your job to keep them all going simultaneously. I wanted it to feel hectic and have lots going on at the same time, so I would have ideally added more minigames to the collection. I liked the idea behind it and think it could be a very fun experience if I polished it up a bit.

Honeycomb Game Engine

2016 is also the year I started on my game engine, Honeycomb, as my third-year project for my Computer Science degree. So far, it’s lacking in a lot of features, but it’s definitely on track for completion by the end of text term (and by ‘completion’, I mean of the features I’ve already planned. There’s no such thing as a ‘complete’ game engine I don’t think). As part of my plans for the engine, I want to make an example game with it once it’s feature-complete, so look out for that! I’m buzzing to see what it’ll turn out like.

honeycomb_logo

Games I played this year

I’ve really neglected actually playing games this year. I was discussing it with a friend the other day and discovered I could almost count the number of games I’ve played this year on one hand. And that’s not even just games from 2016, that’s all games I’ve not played before regardless of release date, excluding game jam games. Worse, the vast majority of them are on Nintendo platforms or are first-party Nintendo properties. I really need to diversify my game collection and maybe dig into my Steam collection in 2017! I’ll give a mini-review of the games I played here.

Pokken Tournament, Wii U

Image from http://www.pokkentournament.com/

I don’t play many traditional fighting games. But when Bandai Namco and The Pokémon Company teamed up to make a Tekken game with Pokémon in it, my interest was definitely piqued. It’s a fun game, even if I’m no good at it. I think its main strength is that it’s accessible to people who don’t usually play fighting games, and that’s definitely one of the reasons I like it so much. It’s also refreshing to see a Pokémon game in which the Pokémon make a bit more contact with each other, and with graphics like the ones on display here I’m excited to see what the future of Pokémon on the whole will bring, especially with the Nintendo Switch on the way. I’d love to see a Pokken Tournament 2, hopefully with a more in-depth storyline.

The Legend of Zelda: Twilight Princess HD, Wii U

Image from nintendo.co.uk

I’ve never played the original Twilight Princess on Gamecube or Wii, but I’d heard it was one of the best in the series. The first Zelda game I played was Ocarina of Time 3D, and I’ve been a huge fan ever since, so this purchase was a no-brainer. And how right everyone is, this game is one of the best games ever made! The dungeons are exquisitely designed and it feels as if every corner of the world had heart and soul pumped into it. The Wolf Link amiibo that came with the special edition is also the finest-looking amiibo to date. If anything, it’s just made me more excited for Breath of the Wild next year.

Star Fox Zero, Wii U

Image from nintendo.co.uk

The Wii U’s last moments could’ve done without a dumpster fire like this. It had some promise, but it let me down on almost every count. It’s boring, hard to control and I honestly couldn’t make it past the first few levels. I was lead to believe in reviews that the two-player mode was pretty fun and made it somewhat worth buying, but that’s a damn lie, it’s still hard to control and it made my boyfriend sad. Don’t buy it, for the love of all that is holy don’t buy it. I don’t care that reviews say it’s fine once you get used to the controls. In 2016, I shouldn’t have to get used to the controls! I would’ve loved a game that used the Wii U GamePad in an inventive, fun and refreshing way, but this game wasn’t it unfortunately.

The Legend of Zelda: The Wind Waker HD, Wii U

Image from amazon.co.uk

This wasn’t from 2016, but I only got it a few months ago. It’s one of the three games I played this year not from 2016! I also haven’t finished it yet, but so far I’ve been having lots of fun with it. The graphical style is unique and, while the Wii U hardware isn’t the most powerful in the world, no-one can argue that this game looks beautiful. I can’t say much else since I’ve not finished it, but the game and dungeon design is so far on par with other Zelda games. And the sailing sections help to break up the action with something a little different to what you’re used to seeing in a Zelda game.

Beat the Beat: Rhythm Paradise, Wii

Image from youtube.com

It turns out this is a great game to take to a university society dedicated to playing Nintendo games. It’s another one not from 2016, but boy am I glad I played this one! I’ve had the soundtrack stuck in my head for weeks and I’m still concerned for the mental well-being of the dev team. Seriously, can someone tell me what the heck is going on in some of these rhythm games? If you can explain what is happening in Donk Donk, I’ll give you a fiver. My personal favourites include Flock Step, Double Date (pictured above) and Flipper Flop.

Miitomo, Android

Image from nintendolife.co.uk

Miitomo is one of those strange little experimental games, or at least that’s what it feels like to me. It’s similar to Nintendo’s own Tomodachi Life in some respects, but lacking in many aspects. It’s a communication app at its heart and integrates well with My Nintendo with daily and weekly challenges, but it sorta got old very quick. Regardless, I had a lot of fun with it when it first launched, answering very strange questions and hearing my friends’ quirky answers. And if any word describes Nintendo’s very first mobile experience, it’s just that: quirky. I was a fan of the costume crossovers with other Nintendo properties – seeing my Mii in a Link outfit or wearing an Inkling hat was pretty cute. I’d love if they brought out a massive update to make this more enticing and bring players back, but I don’t think that’s on the cards unfortunately.

Rayman Legends, Wii U

Image from ubisoft.com

Another game that’s not from 2016 and also great to play with friends. It’s one of the best couch co-op platform games I’ve played in a while, and it lets you ‘accidentally’ punch your friends into a bottomless pit of death, which is always a great selling point. The music levels are especially amazing, with some of the best level design I’ve seen in a recent game. Somehow, a game this creative came out of the maw of Ubisoft! It can be found for dead cheap and it’s been ported to most systems since launch, so I’d recommend picking it up if you can.

Pokémon Super Mystery Dungeon, 3DS

Image from youtube.com

I loved Pokémon Mystery Dungeon: Explorers of Darkness back on the DS. In the midst of the billions of other Pokémon games I had, it offered something different, as I hadn’t played Blue/Red Rescue Team prior. However, Gates to Infinity, the first PMD game on 3DS, left me a bit disappointed, a popular opinion amongst players. It wasn’t bad by any means, and the concept of building a Pokémon Paradise was a fun one, but it just lacked the depth of previous entries for me. Super Mystery Dungeon was different – it has so much content, I don’t think I’ll ever finish it. The combat is as basic as it’s ever been, although some small additions such as emeras and alliances keep things fresh, and I felt the plot was a lot more refined than that of Gates to Infinity. So far, it’s the definitive Pokémon Mystery Dungeon game for me.

Pokémon Go

Image from gameranx.com

You might have heard of this game once or twice. Yes, Pokémon Go is the one game this year that you couldn’t avoid mention of if you tried, and like every other human being on Earth, I gave it a go. While it was fun for the first few days, for me, walking around and catching Pokémon started to get dull. I did have fun while it lasted and it’s wonderful that it got me walking around a bit more in summer than I usually would have. I also took over a couple of gyms for a while despite having few powerful Pokémon (it’s part and parcel of living in a rural town, I guess).

What I like most about Pokémon Go is that it’s made it a lot easier for people to go outside, make new friends and enjoy themselves. And to the countless articles decrying people as pathetic for needing an excuse to go outside, I say sod that; many people find it difficult to work up the courage to go outside because of anxiety problems, or they simply find it boring to go for a walk, and this app has provided what a lot of those people needed – an excuse to open the door. It can only possibly be a good thing that more people are getting active thanks to Pokémon Go and I hope developers jump on the bandwagon of geo-location apps and continue to do good for people’s health in a similar way.

Pokémon Sun, 3DS

Image from ign.com

There’s a lot of Pokemon on this list, and for good reason: it’s Pokémon! When you buy a Pokémon game, you’re almost certainly guaranteed quality, and this year gave us a pair of blockbuster main series entries in Pokémon Sun and Moon. It’s another game I’ve not quite finished yet, but already it feels a lot better than X and Y in terms of story. For one, your friends aren’t made of cardboard and actually have interesting personas, and the story is so far very focused on the island challenge. That’s another plus point for me: the 8-gym system has desperately needed a shake-up for a while, and the island trials do it very well, with the Totem Pokémon being a welcome change from gym leaders.

One thing I’m not a huge fan on is the fact that wild Pokémon occasionally call for help, which is usually not a problem unless I’m trying to catch a Pokémon and it successfully calls for help about 15 times in a row. It took me 20 minutes the other day to catch a damn Caterpie. A Caterpie! And they can do it completely for free, it doesn’t even waste their turn. It’s sometimes good for grinding EXP, so there’s that I guess.

No Man’s Sky, PC

Image from pcgamer.com

Ooooohhh boy. This game sure was controversial, wasn’t it? Well, right off the bat I’m gonna go and make enemies with half of the Internet and say I actually quite liked it. If we’re objectively looking at the game and not the situation surrounding it, I can totally appreciate why the game is not for everyone. It does get boring and there really isn’t much to do, but that’s what I liked about it, crazy as it seems. In a world where every game is vying for your attention by throwing tons of flashy effects and fast-paced gameplay in your face, No Man’s Sky is instead happy to let you sit back and walk around a planet at your own place, appreciating the beautiful pastel-coloured scenery before flying into space seamlessly and visiting another planet to find huge bulks of resources, just so you can do the same thing again.

While the ending was a complete and utter disappointment, I can’t help but feel that this is a game that shouldn’t have had an ending at all. Why would that have ever been a good idea? It’s a game that, at its core, works best when there are no immediate goals or aims, because that’s what made it feel so relaxing for me. I didn’t feel pressured to get to some location in a time limit and was having the most fun when I was idly watching weird creatures run around or just taking screenshots of the breathtaking procedurally generated surroundings. This game really is a testament to the power of letting maths make your game for you.

I’ve not played the Foundation Update yet, but I hear it’s a step in the right direction and I really, really, really hope that Hello Games continue listening to fans and making an effort to communicate, because that’s part of the reason so many people felt so burned in the first place. Oh, and the soundtrack by 65daysofstatic, Music For an Infinite Universe, is amazing and you should go buy it now.

Rhythm Paradise Megamix, 3DS

Image from nintendo.co.uk

If you own a 3DS and like rhythm games, you absolutely owe it to yourself to get a copy of this game. If I were to pick my favourite game this year, I think this would be it. The minigames are so ridiculous, so Nintendo, that you can’t help but love the boundless charm of this game. Each and every game is simple at its core but some are very challenging despite the simple controls and rules. The soundtrack is excellent and it’s stuck in my head worse than Beat the Beat: Rhythm Paradise‘s was. That’s helped by the fact that Megamix is a blend of other games in the series with some original games, so every game in Beat the Beat’s library bar 5 made it into Megamix. If that’s not a selling point, I don’t know what is.

I’ve got almost every perfect on this game, the hardest of which so far have to have been the Left- and Right-Hand Remixes and Lockstep, and I’ve got real close a couple of times with Final Remix, but I don’t think I’ll ever get a perfect on Machine Remix. Fuck the part near the end with the onions.

It’s not just games

Not everything I do is to do with games. Okay, most of it is, since most of my life is playing games, computer science, or the illegitimate child of the two – game development. But more importantly, there are some achievements I made this year that I may as well stick here, since I’ve talked about basically everything else I’ve done this year. First off, I got a boyfriend! He’s called James and he’s absolutely adorable, which I keep telling him just to get a relatively blank face in return. I would put a picture of us up, but he might kill me, so no. I’m also not sure if such a picture exists, we’re both rather shy. Second of all, I’ve continued my successful academic record at uni so far and achieved a first in my second year – a slightly higher first too, up from 71% to about 74%. Since second year is weighted twice as much as first year and both those numbers were rounded, that leaves me at about 73% overall, which is fairly comfortable into a first, although I hope to do even better this year if I can.

We also finally got Nintendo Society recognised as an official Warwick SU society (or, we will be next term). For those that aren’t aware, societies are like after-school clubs basically, and there’s a lot of variety in the types of societies found at Warwick, but one that didn’t exist when I joined was one purely for Nintendo fans. So for about two years now, a few friends and I have been working hard to set the society up, and we’ve been running unofficially for about that length of time anyway, which I think may have swung the SU’s vote. We mainly play Smash 4, but there’s also a lot of Pokemon and other Nintendo games at some of our events. I’ve also unleashed Rhythm Paradise on the society and watched them crumble, although we eventually beat Remix 10 on Beat the Beat. And lately, we’ve diversified our events to include other Smash games, which I’m terrible at. I think I’ll stick to Smash 4 and just Link everyone into oblivion with my dash attacks in 8-player smash instead.

Looking to the future, 2017

Ah yes, the future. I’m not psychic, but I can at least make educated guesses at what 2017 might hold for me. Firstly, I’ll get a version of Honeycomb done. It excites me to no end thinking about how far I might get with Honeycomb, and what sort of games it might be capable of making. It’s running using the Vulkan API, which is basically OpenGL’s baby. Vulkan gives more power to the programmer, which means I’m responsible for setting almost everything up where OpenGL would’ve done stuff for me, but the end result is that games don’t need to rely on bulky graphics drivers quite as much, removing driver overhead and resulting in increased performance. Hopefully it means games developed with Honeycomb end up being fast.

Also in 2017, I hope to make more games than in 2016, since 6 isn’t very many. I’ll aim to enter as many game jams as I can and try to make something really cool over summer this year. Above all else, I hope 2017 can be a happy and successful year for you all, even if 2016 maybe wasn’t the best year for everyone.

Honeycomb Engine: Devblog #5 ~ A Component-Based Architecture

The backbone of a game engine is its architecture. When and how you update the game state can have massive performance implications; as such, a large chunk of the time taken while writing your main loop will be spent making trade-offs that make the engine more complicated but ensure maximum performance. The main loop is something you absolutely need to get right if your game engine stands any chance of running smoothly. Prepare yourself for a particularly wordy post all about Honeycomb’s inner workings!

Many game engines opt for an architecture in which every conceptual object that can go into a game – the player, a chair, an explosion – is modelled by a GameObject. By itself, a GameObject doesn’t do a great deal except hold a list of all the useful snippets of behaviour that actually define what the object does – those are usually called Components. It’s probably the most straightforward way of reasoning about the objects in your game, and that’s part of the reason this programming pattern, aptly called the Component design pattern, is used – GameObjects and Components are intuitive.

If you think of a person in real life, you can easily think up a whole host of behaviours they have and how those behaviours interact with each other – they use their legs to move, their eyes to see and their brain to work out a path from point A to point B. In a virtual environment in which the person were an NPC, the legs would be a movement component and the brain and eyes make up the AI component. But the person also has to interact with a physics component to make sure it doesn’t clip through walls, which would require a collider component to define the physical shape of the person. The movement component modifies the transform component (I’ll talk about those later), then the player’s orientation gets fed to the renderer component so that the game knows how to display them. The person also probably has to deal with an animation component that details exactly how it walks and maybe a sound component if it needs to speak. It’s easy to see how the number of components on a GameObject can snowball!

Usually, the only component that is actually required is called the Transform component. The Transform defines the position, rotation and scaling of an object, which is all data passed to the renderer each frame to calculate part of what’s known as the model-view-projection matrix. Without going into much detail, that matrix is responsible for taking a model as defined relative to itself (how you’d see a model in your modelling package) and transforming its vertices onto your screen. You can see why it’s important – everything has a position and orientation! You could theoretically merge the Transform component into the base GameObject class, although later on in this post I’ll go into a reason you might not want to.

Imagine a world without components. Instead, we just throw all of the ideas I just mentioned into one monolithic class called Player. You can probably already see a couple problems with that, such as:

  • You end up with a lot of code to trundle through if you want to modify any of the person’s behaviour, since all of the person’s behaviour is clumped together.
  • Every single piece of behaviour is coupled to every other piece of behaviour. Physics engine code relies on audio code, which relies on the renderer code, and so on. If you want to change how the renderer works, you might need to think about how the change affects the audio engine, which is obviously counter-intuitive.
  • If you want two different types of person that differ only in one small aspect, for example they use different AI components but the rest of their behaviour is the same, you’d have to copy and paste almost all of the code and change the tiny bit that differs. You’re not exploiting the features of object-oriented programming very well.
  • It’s really difficult for a different object to hold references to some part of Player. For example, if we have an Enemy class too, the enemy probably needs to know where the player is. With components, we’d just hold a reference to the Transform component, which holds all data related to the position and orientation of the Player. But without components, all we can do is hold a reference to the entire Player and hope there’s a sensible way hidden in the tangled mess to find just the position data.

By using components, we eliminate these problems. We can use the object-oriented principle of inheritance to make two components that are mostly similar and differ only slightly, then we can use polymorphism to interact with the common portions of instances of those objects as if they were one of the same. We can hold a reference to just the AI component of a Player GameObject and be reasonably sure it has the relevant functions you’d hope to find in an AI. And best of all, you don’t need to think about the audio engine while you’re writing rendering code, since they’re nicely encapsulated in separate components.

It’s worth noting that organising your game this way may incur a performance hit; however, it’s a reasonable trade-off to ensure that your game is easy to program and extensible later on. This is just one of the many instances of needing to make compromises in programming. And like any programming, there are ways to minimise the performance cost or even leverage features of your hardware to your advantage.

One way in which the hardware can actively make your program more efficient when using a component-based system is by utilising the processor cache. I won’t go into a great amount of detail here, but whenever you access some address in memory, the processor will grab not only the memory it needs, but a bunch of memory adjacent to it too, and it gets put in the cache. The cache is essentially ultra-fast memory – it is built directly onto the processor chip – so as you can imagine, anything in the cache gets processed blindingly quickly.

If your components are organised in memory contiguously, when you access one component’s memory, a bunch of other components stored next to it will get pulled into the cache too; hence, by storing all of one type of component together, we can process them all super-fast when we iterate over them serially. That’s much better than having all of our behaviour lumped into monolithic classes, because in that case we’d have to pull a lot of redundant data into the cache every time we call update() on a component and we’d get a cache miss when we try to access the next component. This is also a reason you’d want to separate out the Transform component from the base GameObject class, because you might want to do something with all of the GameObjects that doesn’t involve their Transform data. By ignoring the Transform component, you can exploit the data locality of the GameObjects fully.

This is just one of the things I’ve discovered while developing Honeycomb. Modern software development contains so many more considerations to make than I would have ever imagined! Who knew that the order in which you create objects could have such a profound impact on the overall performance of the software, or that random-access memory isn’t really random-access any more? Stuff like this makes software development complicated and ridiculous, but that’s also what makes it fun for me. This post is rather lacking in colour and is just a 1,300-word block of text – apologies for that, hopefully the next devblog has some nice screenshots and diagrams in it!

Chemical Chaos ~ Ludum Dare 37 (One Room)

It’s been over a week since the last Ludum Dare competition ended. This time round, the theme was ‘One Room’, so naturally I made a game about a bunch of chemistry experiments that you have to run around and keep going. This decision was somewhat motivated by the fact that everyone I’ve ever talked to loved chemistry at school and would do anything to do a titration again. After all, knowing your market is half of the battle in game development.

The idea I was going for was a game where the player would be constantly running around, getting one experiment in working order, to find that another couple are starting to fail. It’d ideally be a very hectic game made up of several really easy minigames. For maximum effect, I’d need to create quite a few different experiments; however, I only had enough time to make three to a decent level of completion. I’d also have liked more time to polish some of the game’s aspects, mainly some smaller details like particle effects and other signposting to make it easier to see the status of experiments from afar.

ld37-01

Don’t ask why it turns from blue to red.

The first experiment was a distillation – in real life, you do this experiment to separate some liquid from a solution (you probably used it to purify water in school). The controls are simple – just mash the mouse buttons or controller shoulder buttons to turn down the temperature, as shown by the thermometer. When this experiment fails – when the thermometer is full – there’s a large explosion for no apparent reason.

explosion-01

The most important part of development – particle effects.

There’s a couple things I’d like to improve about this minigame. First of all, the apparatus should probably start to smoke and rattle around a bit as it’s getting close to exploding. And on the subject of explosions, I think the explosion needs to have more impact – sure, all the equipment goes flying and there’s a bit of fire, but I might add more flames that stay alight for a while on the table, and possibly violent screenshake when the explosion actually happens. On the plus side, I was very happy with the ‘reaction cam’ that pops up in the corner when an experiment fails.

ld37-02

John is the best video game character this year.

The second experiment was the good old sodium-in-water one, which as we all know, causes fire. The gameplay for this one involves pressing left click/LB to decrease the amount of sodium and potassium that materialises above John, the water tank, and right click/RB to spawn more. If he gets too little metal, he’ll get bored and will fall to sleep and if he gets too much, he’ll get scared then eventually die. Please try not to kill John.

There are a couple of problems in this screenshot – first of all, the sodium blocks sort of clip through the bottom of John instead of bursting into flames on the surface of the water, something I didn’t catch happening before submission. I’m also confused what may have caused it as I touched none of the relevant code for this between getting the feature working and submission. Secondly, the instructions for this experiment are incorrect, as I seem to have put up the instructions for experiment 1 instead; this was probably just an oversight. They’re both easy-to-fix problems, but they could have easily been avoided.

ld37-03

I’ve left my mixtape in all three of these Bunsen burners.

The third and final experiment is the Flame Test, which tasks you with carrying different elements into three flames. Each flame expects the element that makes it burn in a particular colour, as dictated by the chart next to the Bunsen burners and the base of each burner. All other elements go in the bin; if you’re too slow trashing elements, you’ll fail the game, and if you put the incorrect element in a flame, that flame will go out and losing all flames results in failure too.

In hindsight, I should have made the Bunsen burners explode when you get things wrong. It’s basically the only thing wrong with this minigame.

ld37-04

For the flame test minigame, I invented new elements so I could make more interesting flame colours. There’s a line of posters along the wall with short descriptions of them all. Given how long it took me to think up the new element types and make posters and models for each of them, I would have liked to make more games that utilise them all, but unfortunately I didn’t have enough time. One game idea I had was a solution-mixing table, which had a bunch of coloured solutions and you had to make the requested colour. However, it’s not really an experiment that’s easy to make hectic and if you’ve ever dealt with transition metal ions yourself, you’d know that this type of colour change chemistry can be a little complex. For the two people that got that tortured chemistry pun, I’ll see myself out.

I was, however, pleased with how the game came out graphically. The only issue I had was trying to make a roof and windows; doing that messed up the lighting, and any amount of time trying to work out Unity’s area lights and baked global illumination seemed to be wasted in the end.

You can give the game a go by visiting the Ludum Dare page, where you can vote if you took part in the competition, or directly on my Google Drive.

Honeycomb Engine: Dev Blog 4 ~ Plans for the Holidays

Term 1 is now over. While I still have some coursework due in at the start of next term, for the most part, I’m done with work. That means I’ll have tons of time free to get a good chunk of Honeycomb and Honeycode out of the way! I’ll just be outlining the most important plans in this post, so it’ll be a fairly short one; I wanted to get something out since I’ve been quiet for the past few weeks.

Honeycode

First off the bat is Honeycode, the scripting language that will accompany the engine. I’ve made a little progress with Honeycode, but perhaps not as much as I’d liked, so the first task for the holidays will be to finish a working version of Honeycode and its compiler. I think the fun part of creating the language will be testing it out to see what actually works or not – I have so many potential concepts I want to try out and I’m not sure where to even start. The core feature, as always, will be ease-of-use.

Saving and loading mechanisms

This bit might not be quite as interesting to most people, but a weird programmer type like me should find this fun – organising save data on disk. I’ll likely use JSON to save files, both in-game and in-editor. In tools like Unity, it’s often the case that the built-in saving mechanisms aren’t as robust as you’d like (for example, Unity PlayerPrefs aren’t designed for saving all game data, so you need to build a custom solution), so for Honeycomb I want to make sure a good saving system for game data ships with the engine. The in-editor saving system will only need to make sure that scene files and assets are saved properly, so I can use roughly the same sort of system for both use cases.

The Editor

This is the largest task left. The editor will be the main window in which users create games, so it’s arguably the most important remaining feature too. This task encompasses countless other small tasks, so it’s going to take a while. It’s the task I planned mostly for term 2, so any progress I make on it during the holidays is sort of a bonus; however, I think it will be crucial to get as far through the development of the editor as possible to give myself some slack during term 2 in case any major setback occurs. At the very least, I’d like to make the skeleton of the editor by the end of the holidays.

The renderer

While the renderer is somewhat functional, I want to improve it in a few ways. First of all, it can only render one object at a time currently; this is due to my relative inexperience with Vulkan, the graphics API I am using. When I figure out how to order my requests to the GPU properly, and hence get more than one model on screen, the next task is to work on the lighting engine since Honeycomb currently only supports a very broken diffuse lighting shader. The sooner I can work on fancy shaders, the better!

Honeycomb Engine: Dev Blog 3 ~ Quaternions for Rotations

Quaternions. The mere mention of these mathematical constructs would’ve sent shivers down my spine a couple of years ago. They’re really weird and complex. However, when you’re making a game engine and you have to model the rotations of objects, you’d be crazy not to use them for several reasons.

The easiest way for people to think about an arbitrary rotation in 3D space is to think of three separate rotations around the x-, y- and z-axes respectively. This way of representing a rotation is commonly known as Euler angles. The advantage is that it’s easy for someone to reason about a rotation represented in Euler angles because they’re so simple – I just rotate around x, then y, then z, it’s that easy. However, this brings a couple of problems with it too; namely, it’s inefficient to do three separate rotations for every single rotation you apply, and Euler angles can run into a problem called Gimbal lock.

In a system where three gimbals each provide an axis of movement around a central point, it is possible to lose one degree of freedom by rotating one of the gimbals 90° such that its axis converges on one of the other gimbals. When this happens, the other two gimbals will rotate along the same axis. The word ‘lock’ is a tad misleading, because you can fix the problem simply by rotating the first gimbal back, but it still leads to weird behaviour sometimes. It’s best explained through an animated diagram.

Quaternions fix both of these issues. Firstly, Euler’s rotation theorem (Yes, Euler got around a lot) tells us that we can represent any rotation or sequence of rotations around a fixed point as one single composite rotation around some axis through that point. As it turns out, we can model rotations around an arbitrary axis as a quaternion!

img_20161109_003123

Rotating around an axis rather than three rotations around x, y and z axes.

To understand how this works, we first need to know what a quaternion is. I’m not going to go into too much detail, because I want to keep this post relevant to how we can use them for rotations. At their most basic level, a quaternion, q, is made up of four real numbers, x, y, z and w, where:

q = w + xi + yj + zk

Here, i, j and k represent versors, or unit quaternions. Don’t worry about what they mean too much, because your head might go nuclear trying to wrap your brain around them. What we want to do is represent x, y, z and w in a way that’s useful to us. Luckily, it’s really simple: take our axis to be a three-dimensional vector (a, b, c) and our angle to be θ. Then our quaternion’s real number parts are:

x = a * sin(θ/2)
y = b * sin(θ/2)
z = c * sin(θ/2)
w = cos(θ/2)

Now we have a quaternion that represents an angle-axis rotation, immune from the problem of gimbal lock. To apply the rotation to an object, we multiply the point we want to rotate by the rotation quaternion. To figure out what the quaternion is doing, we can take x, y, z and w and calculate the angle and axis from them – first of all we can find the angle:

θ = 2 * cos⁻¹(w)

Then, we can use this angle to figure out what the rotational axis – a 3D vector – is:

a = x / sin(θ/2)
b = y / sin(θ/2)
c = z / sin(θ/2)

With this in mind, it’s a little easier to reason about what quaternions are doing. Keep in mind that all these rotations are about the origin, so if you want to rotate around an arbitrary point, you’ll need to translate your object by the inverse position vector of the point, do the rotation, then translate by the position vector of the point to undo the first translation.

rotation-by-translation

This image is about 2D translations, but the general idea still applies.

To make a rotation by compositing two different rotations, we can just multiply their respective quaternion rotations together, paying attention to the order:

new_rotation = second_rotation * first_rotation

The other great thing about quaternions is that we can mix between two rotations really easily, with more believable results that using Euler angles. Whereas we’d use a regular lerp operation (linear interpolation) to move from one rotation vector to another if we were using Euler angles, we can use the more sophisticated slerp (spherical linear interpolation) technique for quaternion-based rotations.

To imagine the difference between these two techniques, imagine you were stood on a completely flat world, whether it be in 2D or 3D, and I asked you to walk from point A to point B on that surface in a straight line at a constant speed – that’s you using a lerp. Now imagine doing the same, but on the surface of a perfectly spherical meteorite instead – of course, walking in a straight line would end up with you inside the meteorite, which is impossible, but if you walk across the surface directly to your destination, that’s what a slerp is doing. Super simple stuff!

on-top-of-the-world

The flag looks like the USB logo, but it’s supposed to be an angle-axis diagram.

That rounds off pretty much all I know about quaternions and how much I could be bothered to look up online. If I got anything wrong, please do tell me because it’s definitely possible. Remember, if quaternions start to hurt your head, which happened plenty of times to me, keep in mind the most important thing: Don’t Worry About It™. You don’t need to know them inside out to be able to use them.