Why Ludum Dare is important

Find the video version of this post here: https://www.youtube.com/watch?v=IfhstX9kUHY


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

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.

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!

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!

Why Godot 3.0 is something to be excited about

With Godot 3.0 soon reaching stable builds, it's time to get excited. A number of improvements and new features are on the horizon.

In particular, a new audio engine is on its way. Anyone with experience of Godot 2.1's audio engine knows that this alone is some incredible news.

Godot 2.1 currently uses samples and streams as two separate concepts. This gets a bit messy sometimes, given that some things such as music, dialogue or other "one-off" effects benefit from being set as streams while other things may benefit from being samples. Keeping track of both a SamplePlayer and a StreamPlayer can get confusing.

Godot 3.0 is simplifying this process by only supporting streams. This isn't as detrimental to performance as it sounds, as the appropriate optimizations for each are still being made.

Additionally, Godot 3.0 is adding functionality for much easier integration with C++ modules. This is coming by way of GDNative(formerly known as DLScript), a kind of bridge between external libraries and the Godot engine itself. This is also huge, given that now recompiling the engine is no longer necessary for the sake of integrating with things like Steamworks.

Image courtesy of AlisterCat

On top, they are re-writing the rendering engine to be both faster and more versatile. Particles can now be GPU accelerated! For those of you who don't know- this is another incredible feat. This means that particles are now very cheap to render en masse!

There is even some experimental functionality to export to WebAssembly. This is the feature that I am most excited for in Godot 3.0.

Right now, Godot can export to HTML5 in Javascript. As it is now, it's pretty rubbish. It's not particularly well optimized compared to other games made in such frameworks as Phaser, though that is to be expected- transcompilation is not always the most effective task. With WebAssembly, these layers of interpretation are removed, making webgames built in Godot faster and hopefully less buggy.

Of course, that's not to say that Godot 2's HTML5 export option is unusable. It's not. I ported my game, Super Displacement, to HTML5. While it does work, it is notably slower than the desktop edition and sometimes the scoreboard inexplicably doesn't work. You can check this for yourself below.

http://gamejolt.com/games/super-displacement/244666

Shameless self-promotion aside, I've been using Godot 3.0 straight from Github. It's a little bit buggy sometimes but damn, it feels good to be able to make use of the above features! If you want to, it's fairly simple to compile it from source. You can find the instructions here!

http://docs.godotengine.org/en/stable/reference/_compiling.html

Warning!

The instructions to compile Godot 3.0 on Linux/BSD are wrong if you are using openssl version >= 1.0.0. Trying to compile using a simple scons platform=x11 will result in an error. In fact, you need to use scons platform=x11 builtin_openssl=yes use_llvm=yes.

All in all, Godot 3.0 is going to bring with it an up-tick of popularity, which means an up-tick of documentation and community, which helps to alleviate one of Godot's largest criticisms at the moment- that it has a small userbase.

If there ever was a time to get excited about the Godot engine's success and getting it popularly counted alongside Unity and Unreal, this is that time.

Either way, thanks for reading! Check back in 2-3 days' time for a post on why composing music for your game is not an impenetrable, monolithic task.

How to accept criticism of your game

Accepting criticism of your product is hard, and if you're reading this you probably don't need me to tell you that. Every artist - regardless of whether they're a painter, game developer or musician - will eventually have to take criticism of their product, and it's important to know how to take it properly. Hell, even if you don't consider yourself an artist at all I'm sure this post would probably still be helpful if you have trouble taking criticism.

Understanding the difference between "you are bad" and "your game is bad"

One of the most important things to realize is that as the developer of a game, you are not the target of criticism. It's very easy to take critique too personally, or take it to mean that you are "bad at making games", where in reality what a critic might mean is just that "this game you made is bad".

One of these two interpretations involves an attack on your person. It suggests that you are incompetent at doing the thing you are so passionate about, and that really sucks to think about. The other interpretation involves accepting that you simply made something that wasn't good enough, and to leave it at that. Extrapolating this basic concept to imply that actually you're a terrible artist, a terrible programmer, a terrible mathematician, a terrible composer, or the myriad of other things which you can be terrible at is actually tremendously harmful to your willingness to work.

Of course, taking a simple criticism as what it is at face value is much easier said than done. It takes active effort to keep yourself from continuing the spiral of rapidly diminishing self-esteem, but you have to take my word for it that it's worthwhile to do.

Now, don't misunderstand. I'm not telling you to ignore criticism just because it makes you feel bad. Feeling bad sucks, but it's important for the learning experience. Without a disincentive to keep making rubbish, you would hardly improve at a reasonable rate.

What I am saying is rather that you should never view your own skills as being absolute. In Western culture, there is a lot of worship of the innately talented musician, a repressed "hidden talent", or even that of the noble savant. The truth is that the first two are all but non-existent and the third is exceedingly rare(and its usefulness is questionable at best).

Your skills are fully malleable and constantly evolving balls of amorphous goo. They will never be stable for very long, perhaps a year or two at most. From there, you're bound to either improve or become unfamiliar with them. The point I'm making is that if you think you are innately not good at something, you are wrong. It might be more difficult for you to improve or to learn than it is for others, but it is certainly never "gated" beyond your capabilities.

As stated, your skills are malleable and they usually do not define your character. It's important to understand and admit that you're bad at something if you're bad at something, and separating yourself from your skills is a large component of that.

Criticisms do not exist in a vacuum

Criticism is full of bias, and could be argued to not exist without bias. It quite easily follows that what one player perceives to be true about your game(unsatisfying controls, unappealing graphical style) might not be true to many others, or vice versa.

The important thing to realize here is that if you are receiving a criticism that you believe to be unfair, it is possible that it is unfair. Whatever you do, do not go crazy with this idea. It's something to keep in mind, but it's to be used incredibly sparingly.

On the other side of the coin, you as the developer may also be biased. I'm not talking just about the idea that the developer may be so highly protective of their game to the point of ignoring criticism, I'm also talking about the developer genuinely believing that their game is good because it aligns perfectly with what they want out of a game in that genre. However, it's also possible that what you want out of a game in a given genre is simply not what many other people want out of a game.

It's no secret that some developers want to make or have made games which are almost entirely inaccessible to the audience. Even among games with cult followings such as Dwarf Fortress, this is a common criticism.

Every piece of criticism is an opportunity

Every time someone suggests an improvement or tells you something about your game which you didn't want to hear, you gain a little bit of insight. Even the most benign "This game sucks 0/10" comment can help you to understand a perspective which you could never otherwise begin to comprehend.

This sounds very flimsy, but it is tremendously important. So much conflict is based off of simple misunderstanding of each other's views. Any opportunity to gain insight into another person's perspective is a valuable one.

If you truly want your game to be the best it can be, then you have to consider as many perspectives as you can. You have to take in every piece of criticism and evaluate it as fairly as you can. Of course, this isn't easy. It's both cognitively and emotionally strenuous to accept and work out flaws in your game.

Then again, no one says that making a good game is easy!

As usual, if you have done, thanks for reading! Stay tuned for more semi-regular posts.

Preparing for Ludum Dare 38!

At the time of writing, it is precisely 13 days and 2 hours until Ludum Dare 38 starts.

This is also going to be the first Ludum Dare which I actually participate in! I'm making a post here as a kind of "promise" to my kind readers so that I don't back out like I did for LD36...

As expected, I have little idea what to expect. I have no idea as to how well I'll perform over such a tight deadline. Obviously, the scope of the project would be considerably smaller than anything I've done before(well, I say that, but...) while on the other hand I'd be working a lot harder and faster.

Also, as of right now the theme selection should have started 24 hours ago at the latest. This is good.

Amidst the tremendous amount of uncertainty, I have a schedule for how I'm going to split my time over the weekend. Rather, I have a plan to make a schedule. I'm still evaluating the advantages and disadvantages of staying up until 2AM local time to find out the theme, or wake up at 8AM and find out the theme.

Additionally, by now my experience with the Godot engine has made it very easy to set up a simple top-down or sidescrolling base, on top of which I can put any necessary theme-specific developments.

I've also come up with a vague formula for the format of the game. Once the theme is released, I'll take it and try to make a scenario out of it. From this scenario, I can take a simple goal out of it and make that the overall goal of the game.

Since what I'm trying to say is coming out horribly unclear, I'll provide an example. The developer Pixel Prophecy made a game called "6210 B.C.". This game was a very simple slice out of the relationship of two competing tribes of cavemen. The details on the game can be found by either watching his post-mortem on 6210 B.C. or by visiting the game's page itself, linked in the description.

Of course, what is life without some form of substance abuse? Having eroded(if not totally shed) my caffeine addiction, I should be more susceptible to the focus-enhancing and fatigue-eliminating qualities of large quantities of coffee.

As usual, thanks for reading!

Quick and easy ways to add "game juice"

If you're in a hurry, I'll just give you a list of the things I'm going to cover in this post.

• Use screenshake
• Use particles
• Add bass to your sound effects

Okay, so for those of you who are not in a hurry, I'm going to take this a bit more slowly.

There are some methods of "juicing" a game which are so common and versatile that they can be applied to most arcade-y or action-oriented games.

Tip #1: Use screenshake

Screenshake can be incredibly effective if used correctly. Randomizing the camera offset every frame for even a tenth of a second makes explosions and high impacts feel considerably more powerful.

However, one thing to be wary of is that it can cause motion sickness if overused. I've never experienced this, but I've heard several anecdotal reports that excessively shaky screens can make some people a bit unwell. The easy solution to this is to either add an option to disable screenshake, or to limit it to only during certain explosions and only for very short(less than 0.2 second) periods.

Tip #2: Use particles

Fewer things make a game feel more flat than killing an enemy only for it to unceremoniously disappear. If you are graphically limited(as I was in the development of Super Displacement), particles are incredibly useful. If you're going for a lo-fi art style, large and blocky particles can be tremendously helpful. They can be used (conservatively) for a collision, for an enemy death, or anything that you think looks kinda bland (provided that you choose the right colours and speed for the particles to travel at).

Again, there's a catch to using copious amounts of particles. It can seriously lag older computers.

Warning: Don't try to turn down the number of particles for the sake of larger particles, because more often than not this doesn't work. In most systems, the GPU makes a calculation on each pixel that is occupied rendering a particle. This means that if you're balancing the same number of pixels that are being rendered as particles by just increasing the size of each particle, you're not really saving the user any performance. Instead of this, I would recommend a button to turn all non-essential particles off entirely.

Tip #3: Don't be afraid to add bass to your sound effects

This is applicable to a lot of games, and it's something that I've seen a lot of beginning hobby/indie developers fail at. If your sound effect sounds a bit toss, chances are it just doesn't have enough bass in it. Go to audacity, open your sound effect and apply a bass boost. Even if this doesn't immediately make your sound effect amazing, it'll help most of the time. Of course, if you're an audio engineer then you already know that what I'm saying is mostly rubbish.

If your sound effect doesn't fit the game, just don't use it. This isn't really about "game juice", but sound effects make a massive difference to how a game feels.

Rami Ishmael, the public half of Dutch independent studio Vlambeer, often recounts how in SuperCrateBox players would be more inclined to play aggressively, get higher scores and proceed to enjoy the game more if the sound effect to the gun was more powerful, keeping the graphics and the gameplay identical each time. This is a perfect example of sound effects affecting the game in more ways than can often be predicted.



Regardless, I hope you found this post useful. This is probably going to all seem very obvious to the seasoned veterans of indie development, but personally, I would have loved to see this post about a year ago.

If you disagree with anything on this list, or if you think that I've missed out on something super obvious, leave a comment. Otherwise, if you have been- thanks for reading!

Lessons Learned from Super Displacement

Super Displacement is a hectic, arcade shooter where the player must shoot an onslaught of aggressive quadrilaterals and avoid being bounced into the walls.

In the past two or three weeks spent working on this game, I've learned some valuable lessons on how to produce a suitable working project- the first project that I can confidently say I'm proud of.

The key point to Super Displacement is that the scope is very small, even for a one-man project. When I started it, I intended it to be a remake of a previous project, "Don't Be Still". Of course, over time this changed to the point where I had to change the name given that the central mechanic was no longer needed for the game to be a fun experience.

The reason that I removed the "don't stand still or you lose" mechanic was not exactly born of great design principles, it was actually due to the fact that moving fast made the collision detection go a bit... iffy. The easy fix(before realizing that using Godot's _fixed_process function made collision detection easier) was simply to make it so that the player only hits the wall once per gameplay, i.e they lose when they touch the wall. At this point, forcing the player to keep moving seemed tacky. It would have overloaded what is designed to be a very simple game.

After adding a copious amount of particles and screenshake(both of which seem to be very effective for some easy-to-apply "game juice"), I decided that a similarly easy way to apply some extrinsic reward is by adding a high score system.

As many of you may be aware, I used the GameJolt API to add a public, synchronized high score system. I think that this was a large help in terms of replayability, otherwise the game gets somewhat repetitive. As someone who has spent about 20 hours testing the game over and over again- dear god does it get repetitive, and I've only been working on it for a couple of weeks.

In a similar vein to Super Hexagon(though the comparison seems egotistical), Super Displacement encourages the player to keep retrying to beat either their own high score, or to earn a place on the leaderboard. I believe that this could be aided had I made it easier to lose more quickly, as currently individual matches can last several minutes.

Also, graphically the game wasn't particularly impressive. However, I believe that it looked just acceptable enough for the graphics to not bottleneck the overall experience. This was a large part of why I feel this game was - if nothing else - a personal success. I've successfully achieved a semi-minimalistic art style without it looking too rubbish. Having said that, the background started a placeholder and (sadly) evolved into a defining piece of the game's identity.

Either way, I hope that you can take some lessons from what I've succeeded and failed at doing in Super Displacement.

You can download and play Super Displacement at the link below:

http://gamejolt.com/games/super-displacement/244666

Since I'm unlikely to continue to update this project, get hyped for my new one- and if you have done, thanks for reading!