Showing posts with label concept post. Show all posts
Showing posts with label concept post. Show all posts

Tuesday, 11 April 2017

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.

Sunday, 19 March 2017

Well-Executed Derivative Ideas Are Better Than Poorly Executed Unique Ideas


Take two.

So look, before anything else I want to say that by no means am I saying that totally unique ideas are bad, or should even be discouraged. Games such as “Papers, Please” would likely not exist if the developers had not put thought and effort into creating an innovative game mechanic.

However, much more importantly to “Papers, Please"'s success was the strong art style and the emotional impact it makes on the player. These were instrumental- without them, I find it hard to believe that the game would have made it very far at all. If you don’t believe me, you can verify this by looking at two or three reviews for the game. The majority of them hardly praise the passport-checking mechanic at all, especially given that the rest of the article is usually focused on the art style.

This brings me to the main point of this post: unique ideas are cool and often helpful, but it’s a lot more important to execute a given idea well. Any poorly executed idea is not likely to perform well. I have first hand experience in this, as I once created a very poorly executed game called “Don’t Be Still”.

The unique idea at the core of this game was that you had a “stillness meter”, and any time you spent being still or taking damage from enemies would deplete this meter. I think I can safely self-assess here to say that this idea was fine and a suitable game could be built on this mechanic. Unfortunately, I did the exact opposite of build a suitable game. With about 3 seconds of graphical design and no more than a day or so of programming, I threw together something which I cringe to call any more than a prototype. This idea was executed dreadfully, and as such it suffered at launch.

Ultimately, the execution of an idea comes down to a mixture of skill, effort and personal tendencies.

“Don’t Be Still” was primarily gated by the first two, as I can’t speak much to personal tendencies for an engine I was just beginning with. This engine was the Phaser engine. Phaser is a Javascript framework which easily integrates with either WebGL or the HTML5 Canvas. Point is- “Don’t Be Still” was the first project that I’d ever made in Phaser, and I was still getting to grips with how it worked.

Needless to say, I effectively had no idea how Phaser worked even after completing Don’t Be Still, hence why the game is the actual dumpster that it is today. Partly because of the aforementioned and partly just because I was enamoured with the idea that hey- I could make games now, I only spent about a week on it in total before uploading it online.

The take-away from this post (assuming you’ve read up to this point) is that if you’re a newer game developer or if you’re struggling, don’t chase a single unique idea, because in all likelihood it won’t make a bad game good. Take a small idea and polish the hell out of it until it’s something that you’re proud of.

If you have done, thanks for reading.

Also, holy shit I have been lazy for the past week two weeks three weeks. If you're a repeat reader, thank you but more importantly, be sure to keep an eye out. I have something to say about the fate of Solasi, and it isn't good.

Thursday, 2 February 2017

The sequel to "Homogeny"

Some of you may be aware that I recently released the game "Homogeny", which a few people seemed to enjoy. Seeing as I have an inability to not constantly have a project running, I've got a sequel in progress, named "Banality".

Unsurprisingly, this is in the same vein and art style as its predecessor. Devoid of particularly interesting mechanics, but saturated in analytical value and artistic expression.

Hmm.

I was going to continue this post with an explanation of Homogeny's themes, maybe detailing some of my influences, maybe even an early screenshot of Banality.

I'll leave that for another day.

This post is now about my view on artistic expression in video games.


"Artistic Expression" in Video Games

Followers of my work might have realized by now that I am one of the strongest subscribers to the idea that video games are art, perhaps to a fault. 

I say "to a fault" because the games I have produced so far have been primarily walking simulators - not very marketable to most. Of course, games like Proteus or even Dear Esther have been successful, and to varying degrees have earned their successes. 

The games I have and will continue to create are saturated in cryptic interpretations and messages, some more obscure than others, as anyone who has played Homogeny or Yet Another Puzzle Game can attest to.

The question most worthy of debate, "How much of this avant-garde bullshit artistic saturation is too much?"

First, let's explore the term "artistic saturation" and what I mean by this. I am referring specifically to the kind of avant-garde bullshit cryptic messages and implications that are placed in certain video games.

A fairly popular example is that of Bloodborne, which is highly inspired by H.P Lovecraft's work, and unsurprisingly shares the theme of demonization of humanity. 

In Bloodborne, this is conveyed by the ways the beasthood curse is explored -- exact examples of this are left as an exercise to the reader, in part because I don't want to spend half of this post talking about Bloodborne and in part because I believe the game is best interpreted by the individual on a very personal basis.

The most interesting part of the question are the words "too much".

What exactly defines "too much" artistic saturation? Is it when the mechanics of the game are compromised for the art's sake?

Surely, the reverse situation is just as unacceptable - this leads us into a terrible paradox, where neither can coexist. 

Maybe it's not about compromise of other components of the game. Maybe it's instead about its accessibility to the players?

This comes down to the game's purpose. If the game is designed to be mass-marketable and should be accessible to its players, then this becomes a consideration. However, if the game is made by a small hobby indie team, it has no obligation to be mass-marketable, assuming they are not financially dependant on it. 

Ultimately, it seems that there is no such thing as "too much". What a pleasant result, given that the way I develop games is nearly Souls-like in the way it tells a story or narrative while rarely directly divulging information. It requires analytical thought and some imagination to create a story that can be truly enjoyed.

I suppose that what I'm trying to say is quite simply that I'm developing the Dark Souls of walking simulators.
^this is sarcastic


In any case, if you have done, thanks for reading. Stay tuned for more avant-garde bullshit interesting content.

Thursday, 22 December 2016

Preventing Burnout

This is a legitimately useful post that I'm making, rather than highly subjective musings. Enjoy!

I am very prone to what is called "burnout", a term referring to a developer getting tired or otherwise dissuaded from continuing to work on their project. This has been problematic, considering that it's caused me to kinda abandon two other projects in the past, so I've decided to share some tips that I've either come up with or seen somewhere else online.

One of the most useful things I've noticed is that it's important to pace yourself - even if you don't want to. This means that you shouldn't try to work more than 4-6 hours on your project per day. Of course, this is coming from the perspective of someone who has to go to school regularly, so perhaps 6-8 would be a more appropriate number for someone who otherwise has no other preoccupations.

The feeling of "I want to work on this project but I can't" in my own experience helps to keep the enjoyment of working on it fresh and lively in my own mind, which means I'm less likely to experience burnout.

Another thing that helps more than I would have expected is keeping an hour count. I use the Godot editor on Steam, which automatically records your hours spent "playing" any particular application and by now I have about 90 hours on record. This helps just for the sake of a number ticking up being somewhat satisfying. Maybe this won't work for you, but it's worth a go.

A pretty useful tip that I use a lot is that if I discover a bug or something that I really don't want to do, I schedule it for either tomorrow or the day after. The most important thing is that I do it then, procrastinating sets a bad precedent for the future. This can be difficult, but it's very useful. If you can suppress thoughts like "ugh I don't want to do this" or "grr this is going to be so much trouble" in lieu of thoughts like "I can make this bit blue" or "where can I add dithering", it helps a lot.

Something that helps quite a bit is making a post on your devblog - provided you have one. If you don't have one, make one and post it to /r/devblogs or something similar. There's another whole post to be made to talk about devblogs and how they're helpful, but just trust me, seeing the "All time views" number tick up slowly is tremendously satisfying.

This is something that I've seen is commonly suggested but somewhat underrated. If you're stuck on something, shut your eyes for a few moments and picture it in your mind in as much excruciating detail as you can. Besides the beneficial side effects of exercising your imagination, this helps you with design, as well as allowing you to recognize the potential of what your game could be if you do everything exactly right.

One last thing that is tremendously useful; if you're not feeling motivated, think of one very small thing that you can do to your game. Bonus points if its very menial or repetitive and doesn't require creative effort, because while interacting with your game in any way you might start being able to think of ways to tackle other problems, whether they're how to recreate something graphically or how to tackle a tricky bug.

Even if you plan on working for 5 minutes, you will often work for much longer once you start. Sometimes the hardest part of something is to start it, and then the rest becomes quite enjoyable.

Anyway, that concludes my list of (hopefully) helpful tips, and if you have done, thanks for reading!