Sunday, 30 April 2017

Why Ludum Dare is important

The tri-annual Ludum Dare event is a very useful (and hopefully, fun) resource for almost all developers, indie or otherwise.



 The first half of Ludum Dare


As a developer who recently took part in his first Ludum Dare event- I can say that at least for me, it was pretty damn fun. It's hectic, but a very good lesson in how to handle project scoping. Additionally, it's very good at teaching you how to handle realizing that your project is a bit rubbish but making the most of it in the short time allocated.

As someone who has had some problems in the past with adequate scoping, I feel that picking something moderately tiny - "run around a planet, shoot things, protect things" - was appropriate. Surprisingly, it came out quite well! However, talking about my experiences isn't quite the focus of this post.

Ludum Dare puts you under a lot of pressure to finish your project. 48 hours is a deceptively short amount of time.

"Oh, I only spent about 50 hours making this other game and that turned out fine!" is a very convincing reaction until you realize that those 50 hours were spread out over a week or two. Once you factor in sleeping, eating, taking breaks to prevent death, and then the inevitable burnout period when you just want to watch one more Youtube video to help you wake up, you begin to realize that realistically you only have about 20 hours of functioning work time maximum.

Even then, the sheer number of hours put in does not make a good game. Some of that has to be planning, a lot of it has to be prototyping, and a lot of it has to be polishing. All those hours you thought you had very quickly disappear. I spent about 3 hours working on a sand texture. Even now, I'm not particularly happy with that texture. However, I've learned from that to not get bogged down tunnel-visioning on one thing just to make the minimum viable product.

That lesson at the end is so much more significant if you have tangible proof of having learned it. My tangible proof is the existence of the game I made for the event. Just reading the sentence "don't spend all your time trying to make sand not look like noodles" does not mean that you fully understand it.

Hopefully by now, I've sold you on the benefits of creating a game for Ludum Dare. There is, however, the other half of Ludum Dare.

 The other half of Ludum Dare


There were a hell of a lot of games made for Ludum Dare 38. In fact, just under 3000 are published on the ldjam.com website. These games are made by developers with a wide range of abilities, and it can be equally useful to play them as it is to create one.

In particular, you need to leave feedback after you play the game. Constructive criticism can be very useful for the developer, but it's underrated just how useful it can also be for you. Trying to understand why a gunshot feels weak or why the art style doesn't sit right is one thing, but trying to articulate and explain it can be very helpful to your own understanding.

Also, if you want to improve your writing, giving feedback can be some quick and easy practice. Write two or three hundred words on how that game made you feel, what you liked, and what you didn't like. Over time, it will add up.

As an added bonus to all these, each user on Ludum Dare has a "coolness" factor. Your game will show up more prominently if you've rated and given feedback to a high number of other submissions. Currently, voting is still not enabled and neither is the coolness system. However, the website aptly named "Feedback Friends" is a solid substitute in the meantime, so there's no reason not to start commenting right away!


I hope you found this informative or otherwise motivational, I've been putting off writing this post for about 2-3 days now. It feels good to finally get it done, despite the fact that I'm exhausted. If you're one of the people who religiously check my blog every 3 days and give me a small view spike like clockwork even when I haven't posted- thank you, but god I feel bad about not posting when that happens.

Tuesday, 25 April 2017

Ludum Dare 38 - How Polar Protector came to be

Ludum Dare 38 was my first experience with a game jam, and overall it was a damn good one. As expected, I found myself under a lot of pressure to avoid over-scoping, and I think I did so successfully. I ended up finishing the game about 10 hours before the deadline for the compo.



I woke up at 6AM on Saturday morning. The theme was announced 2AM prior, but I decided that waking up early rather than staying up late would buy me more time during the event.

Despite the fact that I'd just woken up and was effectively dead for the next few minutes, I rushed to my computer to find out the theme - "A Small World".

After spending 20 minutes puzzling, drinking tea to wake me up and then puzzling some more, I had an idea. I would create a game where the player stands on a small world and fights off enemies. A few iterations later, I had the core concept for my submission.

I decided to name it "Polar Protector", since the aim of the game is to protect the poles at each end of the planet. Not magnetic poles, but rather actual metal poles jutting out from each side.

I spent most of Saturday programming and drawing up graphics. I worked for 13 hours straight(from 6AM to 7PM) and came out the other end feeling significantly less than alive.

I would estimate that out of these 13 hours, I spent about 8-9 hours on the art and 4-5 on the programming. For someone who barely scrapes passable when trying to make art assets, I think that's more-or-less expected.

I took Sunday a bit slower, since the bulk of the game was finished by that point. I only had to make some sound effects, music, and stick a load of particles everywhere. I made the sound effects by recording myself making noises and then messing with it in Audacity, save one sound that I made in sfxr. Try to guess which one!

I made the music using BeepBox, and I put the particles everywhere and removed the ones that didn't make any sense. All in all, it was a successful venture.

If you're intrigued by the final product, you can find it (along with its source code) on Gamejolt here:

http://gamejolt.com/games/polar_protector/251600

I also recorded a short timelapse of the game being created. Unfortunately, I forgot to record the final 10% where I added the particles and the music, but most of it is there. You can find this timelapse on Youtube below:

https://www.youtube.com/watch?v=G__q-WFoLeI

Thanks for reading, and I hope you enjoy playing my submission!

Thursday, 20 April 2017

You are in dire need of new perspectives

If you're making games, you're making experiences. Each element of your game in some way contributes to the overall experience, whether it's graphics, story or a certain sound effect.

It subsequently comes as no surprise that in order to understand how to effectively craft an experience for the player, you need to understand how a specific element makes a player feel. Whether you realize it or not, game development is a game of empathy.

As the developer of your game, you are the worst critic of your game. Your perspective is the most likely to be warped from hundreds of hours spent thinking about or playing with it, as well as the knowledge of all the past iterations and even the original vision for the game. These all contribute to making your opinion of your game nearly useless. I'm not saying that you shouldn't play-test your game, because you definitely should. Some things are universally recognizable. The point I'm making is that there are innate biases in a developer's perspective.

Simply put, you need new perspectives.

You need players to tell you what is wrong with your game as well as what is right. You need players to tell you what the game makes them feel. You need players to tell you what other games make them feel. You need to read what other developers are saying. You need to listen to stories from other developers.

Without all of this, it's going to make developing a game very hard. The worst thing you can do is fail to empathize with the people who will be playing your game.

Of course, it's not just the players. You need to be able to empathize with the stories of other developers, especially if you're just starting out. Without being able to get a comprehensive view of the industry and how it treats people, you're in for a rough ride. The next time you're listening to a talk at GDC and the developer spends the first 15 minutes introducing themselves, stick with it and listen to them. Chances are that by watching this, you're understanding the biases and path through the industry by which the developer came to be.

No two people live the exact same life. Even if they did, it would be exceedingly rare. Making a game for yourself is great and I don't mean to say I discourage it, but if you're expecting other people to listen you have to make a game for them too. This applies doubly if you're selling your game.

Next time you're drawing a sprite, writing a plot twist or composing a soundtrack, try to find someone who you can ask about it. Ideally, don't have this be friends or family, though if you're in dire need of a new perspective they'll do. Do this as often as possible for as many iterations of your game as you can. It will help.

I hope you found this informative or otherwise enjoyable. Thanks for reading!

...and good luck with Ludum Dare 38!

Monday, 17 April 2017

Shoehunt is now released!

Check it out on Gamejolt here:
http://gamejolt.com/games/shoehunt/250195

Shoehunt is a game I made in about 2 and a half days to test the boundaries of what I can do in a similar timespan to the upcoming Ludum Dare event. It's not exactly a complex game, but I thought it's worth releasing into the wild regardless.

Enjoy!

Composing music for your game is not an impenetrable, monolithic task

I've seen a lot of developers take music composition to be nigh impossible. This is, of course, not the case. With the sheer quantity of online resources at your disposal, it's difficult to justify not being able to at least attempt to make your own music.

I'll preface this by saying that I'm not actually trying to ruin the lives of professional musicians. What I'm describing below is how to achieve the bare minimum in order for your game's soundtrack to not actively bottleneck the rest of the experience. I'm not explaining how to recreate the same amount of emotion in the OST to FTL: Faster Than Light, nor the same amount of energy in Super Hexagon. I am only describing how to just about get to this level, possibly with better mixing.

1. LMMS

The first preconception you may have is that you need to either invest or pirate some expensive software like FL Studio. This is certainly untrue. In fact, LMMS is a relatively simple piece of software which allows you to synthesize sounds, sample sounds, add a myriad of effects and install plugins. It's got a bit of a learning curve, but it's reportedly less steep than FL Studio's so hey- maybe LMMS is better for beginners after all*!
*I have no experience nor authority regarding FL Studio

At this point, it's quite likely that you will install LMMS, turn 360 degrees and walk away. If you don't, great! I'm glad! LMMS can be very powerful if you're willing to put in the time and effort to learn it.

However, if you were part of the former crowd, there are easier options. At this point, I'm going to focus on chiptunes in particular. LMMS can make chiptunes, but it's also used for making many other kinds of music.

2. Famitracker

Famitracker is a wonderful piece of software. It's incredibly powerful for making chiptunes, and a lot of people who make chiptunes professionally still use this software. Depending on how closely you follow this blog, you may be asking at this point "Alex, how do you run this program if it's Windows-only and you're running Linux?". The answer to this is that it runs remarkably well under Wine. It runs almost as if it's native. I've encountered no bugs nor crashes in my time using it. Even if you're running Linux, I would recommend giving it a try.

If you install Famitracker and freak out even more than you did with LMMS, don't worry. It's a very intimidating program, but when you get to know it it's very easy to use. There are a few core principles which are outside of the scope of this project that make it a million times easier. I would personally recommend watching some of Ben Burnes' "How to use Famitracker" series in order to get you started.

Failing that, not all is lost. There is one final level of simplicity to drop down to. It's what I used for Super Displacement, and I'm fairly proud of what I did with it.

3. BeepBox

Rather than being an application, this is a website- BeepBox.

BeepBox is probably the easiest thing to use in the world. It's not very flexible, but compared to its simplicity it's more than permissible. If you are at your wit's end and don't want to spend more than 2 minutes to learn how to use a program, then BeepBox is where you should go.

Even if you are a die-hard Famitracker fan, BeepBox is good for sketching out some simple songs which can be more powerfully adjusted in Famitracker, or even LMMS.

Regardless of your preference of software, I hope you found this post informative or otherwise enjoyable. Thanks for reading!