Monday, 21 January 2019

Sunday, 16 December 2018

How To Design Minigames

Sometimes when you're working on a cool little video game, you'll come to a point where you're thinking about adding a little minigame to spice up an otherwise boring mechanic.

In my experience and as far as I can tell, usually this happens to bridge a gap in the wider design of your game. For instance, let me give an example using my own game.

In WARP-TEK, the gameplay is basically one really long journey interspersed with boss encounters. This is cool and everything but there is a problem with replayability- if the player is made to replay the first 10% of the game like a thousand times, they're gonna get really bored and run into the same issue that a lot of games, specifically roguelikes, run into- repeating content is not fun, and eventually repeating the same content enough actually becomes a deterrent to be weighed against the promise of something cool happening later on.

So in light of that, I thought a bit about how I would fix this, and I decided that the player would have to be able to skip over areas of the game that they've already played through a gazillion times. Of course I can't give this one to them for free- that'd remove like all of the challenge. So I decided that the perfect thing to fill in this gap would be to add a nice little minigame.

So it took me like two days to actually design and implement this simple minigame- all I ended up doing was making it so that the player can skip to a maximum of 80% of where they left off. There's one of those bars where the fill moves up and down, and the player has to press any key when it's as high as possible. This is still pretty easy but it's simple, quick and feels pretty nice as a little downtime between playthroughs.

If anything, the biggest flaw with this minigame is that it is too easy- with a bit of practice, I'm sure you can reliably hit 80% of where you left off every single time.

For what it's worth at this point - and this is probably a little bit more programmery than you might care about - the fill doesn't move up and down in a perfect sin graph as you might think to implement it. It's actually sin cubed, with a little bias to make it move away from the top values a little bit more quickly than it does the bottom values.

Anyway, back to design. What other considerations were there when making this minigame? Well, it couldn't be too tedious. The whole point of minigames in this context is to break up gameplay and make things a little bit less tedious. I considered doing a continuous "endless runner" type thing initially, where you have to dodge progressively more numerous obstacles until you eventually lose and you're placed into the game at the point that you lost.

This wasn't a bad idea but it could easily become tedious in itself if the player plays it enough. There's really no promise of variety and it would by necessity judge the player based on how long they can survive playing the same thing for maybe 20 or 30 seconds or so. That doesn't sound like much time, but in aggregate it could mean making the player play shitty Flappy Bird for upwards of 5, 10, 20 minutes over the course of beating the game.

There used to be a minigame in WARP-TEK that was such that right before you kill a boss, the camera zoomed in on your ship and you had to run around and activate all 4 power cores to fire a huge laser beam which finishes the big enemy off. If you took too long to do this, the boss would regenerate a little bit of health and you'd have to go again.

It's not a bad idea and I'm still not sure I hate it - I've actually got a switch that just disables it, the code and assets are still in the game just waiting for me to change a boolean value - but it does take a bit of time and it's really just the same damn thing every time. It's not super interesting or varied and while I love minigames conceptually, you have to keep in mind that they have to be either fun in themselves, or so tiny that the player doesn't have a chance to get tired of them.

That's all I've got for this video I guess, I hope you gleaned something interesting from this video. Thanks for watching and stay tuned for more videos about things I'm still despite my best efforts not qualified to talk about. I saw someone do a reddit comment one time saying that all my videos are "weak points" and I beg for subscribers at the end, so I guess fuck that guy and please subscribe to me. Goodbye!

Wednesday, 5 December 2018

Ludum Dare 43 Post-Mortem

I'm kinda jumping the gun on calling this a post-mortem since at the time of uploading this video, Ludum Dare 43 hasn't even finished yet. But hey, I already finished my submission and based on my schedule of uploading a video every 3 days, this is the best time slot to make this.

So for those of you who don't know, the theme was "Sacrifices must be made". I used a word processor to jot down a few ideas, and soon enough I came up with the idea that the player has to protect a small population of people from a bunch of oncoming enemies, but they can also sacrifice a member of the population to get stronger.

And that's the premise of my submission, you kinda have to balance having citizens to protect - if they all get killed or sacrificed, then the game's over - with your own power. Also, the enemies get progressively stronger as the game goes on.

So how did development go? Well, I originally intended for the art to be a bit more interested and varied than it ended up being, I thought hey I can do medium quality art in a relatively short time, so why not? However, by the time I put pixel to... uh... computer screen, I ended up with some real minimalistic sprites.

This proved to not really be an issue since it looks perfectly respectable, and on top of that took me like an hour to create.

As for code, there was a bunch of algorithmic type programming which is my absolute favourite type of programming. For instance, moving the selection cursor between citizens to determine which one to sacrifice was real fun to program, though I did spend about an hour working through one annoying bug which in retrospect, was way more time than I should have.

Another nice one was determining how the citizens should wander around- I went through a few really complicated solutions until the really simple "generate a random point to walk towards, then once they reach that point just generate a new one" system popped into my head.

Overall I'm really pleased with this Ludum Dare submission I gotta say, it's probably my best one yet in so far as its design goes. It's probably got the most replay value, and miraculously the music turned out sounding pretty decent! For the first time since that one music track from Mushroom: The Ruckus... I can't remember what it's called, but it was pretty good.

I also feel like in this Ludum Dare, I paced it way better- previously, I'd have like almost the whole game finished on Saturday, then on Sunday I'd only have audio and a few tweaks left to do. This time, it was much closer to a 50/50 split- probably on account of how much work I had to put into this one as compared to my previous Ludum Dare games. All in all, I put just under 16 hours of work into this Ludum Dare game.

Thanks for watching and stay tuned for more videos about games that I make, some of which are Ludum Dare games and others which are like real proper big games.

Tuesday, 20 November 2018

How To Do Pixel Art With Godot

Some of my videos end up getting a bit technical but let me tell you this isn't one of them. Making pixel art look nice and neat and tidy in Godot is like one of the easiest things ever and I'm gonna have a hell of a job stretching this into three minutes, but somebody commented that they wanted to see a video on this so I guess I'm at the mercy of the people.

So to start with, I'd recommend determining the resolution that you want your game to run at. For most desktop games I'd recommend that this is some nice even fraction of 1920x1080, so that could be 920x540, or in WARP-TEK's case 480x270. All I've done to arrive at these numbers is divide 1920x1080 by 2 and 4 respectively, so that each pixel will take up more space on the screen.

So now that you've made the hardest decision that you're gonna make in this long and tiring process, all you have to do is go to Project Settings, Quality, enable "Use Pixel Snap" to make sure you don't get any weird artifacts when you've moving the sprites, then go back to "Display"->"Window", set "Resizeable" to true, set the Test Width and Test Height to 1920x1080(just to make the game the appropriate resolution when it's scaled up) and for good measure I usually enable "Fullscreen" here too.

Lastly, go down to "Stretch" in the same section and set mode to viewport, and set aspect to keep.

And that's it, you've now exactly recreated the same style of pixel art rendering that I use in WARP-TEK. The advantage of doing it this way is that all things like particle effects, Control nodes, etc will all be pixel-lookin and you don't have to do anything about it.

See? Super easy. I told you I wouldn't fill up three minutes with this. Hmm. So what's up with you guys?

..

Hm, interesting stuff. Yeah. I hope that all works out for you, you know, the stuff you just said. Yeah.

...

Well thanks for watching and stay tuned for really short videos that you too can recommend that I make so that it's your fault that the videos are too short and not mine. Goodbye!

Wednesday, 14 November 2018

Play-Testing WARP-TEK

Recently, I've sent my game WARP-TEK to a few friends for beta testing- so they can help me catch bugs, point out things which are annoying or whether the game is just "missing something".

I'm not really expecting to get unbiased feedback. In fact, I'm almost certain that they all had their expectations a bit unfairly tampered with before they even launched the game. However I do think that their feedback is super valuable- they know the core idea of the game better than random people, so I don't have to own up to the fact that I don't have any tutorial system at all, and I don't have to explain it to them otherwise.

I'm probably not gonna get feedback like "this whole system is broken, ill conceived and I spit upon you and your ancestors". If I get feedback like that at this stage, then fuck me it's a good thing I didn't show anyone this pile of garbage before I fix it. If not, then it's a kind of "go-ahead" to pass it on to the next wave of playtesters at some point who would be people a little more removed from me.

I should note at this point that if you're active in my Discord server, there's a much, much higher chance of you getting a beta key. That's mostly because if you never speak to me, then it's really quite unlikely that I'll even know you exist and I'm not gonna fire some beta keys into the ether quite yet.

But the point is that at the moment, I'm not expecting to get really detailed feedback. One active user in my Discord server - Miles - has given me an extraordinary wealth of things to think about, consider, and tweak. I'm super grateful for this but it's a spell of luck that he did. Fortunately, the overall response seems to be that the game is pretty cool(albeit flawed at this stage) which definitely surprised me for the game being so early on in its life cycle!

The important thing about selecting playtesters is to make sure that they have some kind of analytical and game design oriented mind so as to pick out things that are cool and fun and be able to present them. Even if they don't have the best solutions, if they have anything to say at all then it's your job as a designer to evaluate their feedback and consider whether there is a problem there and whether you can come up with a fix for it.

With less experienced game designers or with completely random people i.e the average consumer, they probably will give you a high amount of garbage advice. They might suggest new features that are incoherent with the rest of the game, they might feel frustrated by something but not realize what it is that is actually frustrating them.

I don't mean to frame it as them being stupid, but it does take a certain level of skill to provide good and useful feedback, and when you're interpreting this feedback you have to also consider the playtester's competence in analysis and design.

Lucky for me, out of the three people who playtested WARP-TEK for me, two of them were analytically-minded game developers. The third was my brother and he didn't give me shit for feedback so I'm going to pour syrup in his bed but the point is, I got some good, trustworthy feedback in the end.

Anyway this video sucks and I guess if you watched this far into it then I kind of feel bad for you but I already missed my last scheduled upload 3 days ago and I can't justify missing another one. YouTube is hard! I gotta think of a cool idea every 3 days? And I got a video game to develop? Yikes!

So yeah thanks for watching and stay tuned for more meandering garbage. Goodbye!