从Game a Week规则中学习如何创造游戏
经过几个月的努力，Vlambeer的Rami Ismail建议我尝试“Game a Week”。“Game a Week”规则是关于我将采取一个全新的理念并花一周时间去探索它。我将从周一早上开始，并于周天晚上将自己所完成的一切内容放在我的网站上—-即使只是一个不完整的内容。
有时候我会觉得自己的大脑中隐藏着另一个秘密的大脑。这“第二个大脑”中便装着所有被我抛弃的半成品理念—-就像是我的理念绕着这一大脑旋转着，将真正的大脑带离它本应该面对的任务。“Game a Week”推动着我空出所有的“假设”理念。有些是有趣的，有些却不是，但最重要的部分是当我能够空出所有的这些理念时，我最终将看到全新且更有趣的理念。如果没有了这些早旧的理念，我会觉得自己变得更加集中了。
我不能明确地说出“Game a Week”到底带给我的游戏开发多大的影响，我也没有足够的数据点去评价这一规则。现在我还只处于第15周，从个人来讲，我已经看到区别了。对于我来说，一周便足以从某种程度上去探索一个理念/机制，在此我可以看到它是否如我所期待的那样运行，尽管因为时间太短我还未能完全投入于理念中。我也对接下来的37周时间能够带给我哪些变化充满好奇。
什么是对的：几乎没有。然而这是我的第一款“game a week”游戏，并且我清清楚楚地创造出了某些内容。我创造了一些你能在理论上进行互动的内容，并且与最初的理念有着非常紧密的联系。
理念：我个人真的很喜欢单机多人游戏理念，以及推动实体互动的游戏理念。关于这些游戏的一些典型例子包括Game Oven的《Fingle》，Kaho Abe的《Hit Me！》以及Doug Wilson的《J.S.Joust》。这是我对于这一行动的小小贡献。这是每个玩家都需要按压键盘上的任何按键的双人玩家游戏。其目标是第一个人破坏所有的组块。
理念：经过证明这款游戏非常糟糕。我一直纠结于该怎么通过音乐去影响人们的感受和体验，而这便意味着需要进行模仿。几周前我到Boston House of Blues看了CHVRCHES，在xxyyxx表演的时候，有个人在舞台上用自己的macbook pro创造出非常棒的音乐体验。我希望这款游戏能够传达出这样的感受。我想要在iPad上创造出玩家想要通过音乐与屏幕上的事件进行互动的体验，就好像你在创造自己的音乐体验一样。有点像是DJ模拟器与《Fantasia: Music Evolved》的结合。
理念：本周我尝试了一些新内容。我越来越厌烦自己的能力很容易被扰乱的情况，并也想要尝试一个新工具。结合了这两点我创造了自己的第一款Twine游戏，名为《Game Dev：The Game》。我经常拿基于游戏难度去创造游戏。我并不是一个舞文弄墨者，所以对于我来说创造一款Twine游戏真的非常艰难，但我已经决定好要在一些不擅长的领域去挑战自己。
什么是错的：我并未留给自己足够的时间去探索这点。因为刚好与Steam Dev Days在同一周，我将本周的游戏开发推到了周末，即在所有有趣的事件结束之后。
什么是错的：随着Global Game Jam的逼近，我甚至不能用一整周的时间再次探索这一理念。因为如此，游戏的结局非常匆忙，甚至与其它游戏内容不是很搭。鉴于前面及部分非常有趣，如此的结局明显太过敷衍。
遭遇另一次失败。本周非常奇怪，因为我创造了多款游戏/原型。但是却没有一款游戏/原型掉进“Game a Week”咒语中，因此从技术上来看我遭遇了失败。在本周的一开始我参加了Global Game Jam，然后有一个前同事/现在的合作者来科罗拉多找我并与我共同致力于一个全新的项目中。我们完成了这个全新项目，并在Global Game Jam上获得了很棒的体验，但这过程中，我甚至忽视了“Game a Week”的游戏。
什么是错的：我并未创造“Game a Week”游戏。
因为在几周前面对了Global Game Jam的主题，所以移动方向与玩家视角相关。这意味着如果玩家1听到指令后向左移动，那么玩家将相对于自己向左移动—-而无需涉及到玩家区域的方向。
就像你所看到的—-在这十四周的“Game a Week”中，我失败了2次。我为这两周想出了所谓的“有效借口”，但说实话，任何借口都只是借口。
就我个人而言，每当我遭遇“失败”时，我都要承受巨大的打击。对于我来说失败将直接反应我作为人类的价值以及作为社会成员的价值。例如，在“Game a Week”中的失败会让我这么想：“你甚至不能在7天内创造一个简单的原型？你真是个糟糕的游戏开发者，这样你永远都不可能获取成功的。”
理性的Adriel：“记得你致力于《Rock Band Blitz》的时间吗？”
在Steam Dev Days，与另外一名开发者的交谈让我印象深刻。他正致力于一款我个人觉得非常出色的游戏。这款具有创造性的游戏已经获得了来自其他开发者以及新网站的许多赞许，并成功在Kickstarter上募集到资金。在我看来，这位开发者幸运地拥有了一切。但在与他交谈时，他向我述说了自己所遇到的一些情况。他感叹着因为未能创造一款成品游戏而质疑自己是否适合站在这里，以及因为未能获取“成功”而纠结是否能够与其他开发者进行交谈。他甚至认为我是比他成功的人之一。这便是自我怀疑肆虐于我们产业中的典型例子。
“Game a Week”的整体主题只是关于开始创造某些内容。思考某些内容与真正落实行动具有巨大的区别—-每一周的经历都在向我证实这点。你可以将这一教训带向生活中的许多不同方面，对于我来说，这便是一个需要牢记于心的重要理念。
Make Many Games: Learn Many Things
by Adriel Wallick
When I first left my job and started traveling around, I had assumed that all my newfound freedom would allow me to work non-stop on all of the “awesome” ideas that I had floating around in my head.
Unfortunately, as someone once put it, “It’s hard to think outside of the box once you no longer have the box”. Without any constraints, I felt myself losing the ability to do anything. Total freedom was much more difficult to deal with than I ever thought it could be. I knew it would be hard to stay motivated with zero constraints, but all the foresight in the world couldn’t prepare me for the total paralyzation of my mind and abilities in this situation. I basically hit “game-developer’s block”.
My first few months were spent mentally recovering from a rough year. A lot changed for me in 2013, and once I really had time to process it all – man, it was hard to work. Every time I sat down to work on something, I would inevitably browse reddit and buzzfeed for a few hours before giving up in total frustration. Where did all my ideas go? I spent the last few years engrossed in thoughts of all of the amazing games I would work on once I had real time, and now that I was faced with the chance – nothing. I would start a prototype only to throw it away a few hours later. The number of mostly empty “New Unity Project” folders on my desktop was steadily growing, and my motivation/perceived self-worth was dwindling proportionally.
After months of me struggling, Vlambeer’s Rami Ismail suggested trying Game a Week. The rules of Game a Week were that I would take one new idea and explore it for one week. I would start Monday morning and put whatever it is that I have accomplished on my website Sunday night – even if it was an incomplete piece of junk.
Finally, I had some accountability. I had a goal to work towards, and deliverables that I had to achieve every week. The first few weeks were full of me trying to “cheat” the system in a way.
“Oh, well, I’ll give myself a few extra hours on Monday to finish this idea up”
“If I fail this week, I’ll just make two games next week”
“Maybe I’ll spend this week re-visiting an idea I had a little while ago and started prototyping”
I’d be lying if I said I could have done this as successfully without tons of external motivation at the inception of this challenge – Rami would consistently shoot down every one of those cheats and stringently encourage me to stick within the constraints – pick one new idea, develop it, explore it, finish it, don’t touch it again. Over time it became easier to push the “cheating” out of my way of thinking and focus on the games.
Each week I learned something new and each week I accomplished something. Even though 80% of the games I created were absolutely terrible, I finally had the reassurance of seeing something that I created appear every week. The accountability of having to put the games on my website for all to see was incredibly daunting and one of the other major reasons that I stuck to it. I can actually feel myself improving every week on various aspects of my game design skills. I won’t say I’m amazing at any of it in any way, but now that I’m forcing myself to think about new ideas every week, and critically explore my mechanics and game creation approach, I can definitely see the improvement.
I sometimes feel like my brain has a secret second brain hidden inside of it. My “second brain” is where all of my half formed ideas get stuck – it feels like a place where my ideas swirl around and distract my real brain from all of the work it should be doing. Game a Week forced me to empty out all of “what if” ideas that were caught in there. Some were fun, some were not, but the most important part is that once I was able to empty out all of those ideas, I could finally see new and more exciting ones. Without all of the old ideas floating around, I could feel myself becoming more focused.
I can’t talk enough about how much Game a Week has affected my game development – I also don’t have enough data points yet to definitively make an assessment on this either. I’m only now on my 15th week, but personally, I can see the difference. For me, one week is long enough to be able to properly explore one idea/mechanic to an extent where I can see whether it works as well as I think it should, yet short enough that I don’t become completely invested to the idea. I’m curious as to where the next 37 weeks will bring me in this.
Recap of Weeks 1 – 14
Idea: I tried to start small with my first idea. It was a game where you had to simultaneously control a number of circles and place them in a certain area to score points. I had no real direction in my head for this, it was just something “easy” that I thought could be “fun”.
What went right: Almost nothing. However, it was my very first game a week game and I definitely made something. I made something that you could theoretically interact with and had a very loose connection with the original idea.
What went wrong: I started WAY too late in the week. I think I started this game on Friday (honestly can’t remember, I just know it was way later in the week than it should have been). I also didn’t think my idea through before hand. I had a concept, didn’t put much thought into how to interact with it, and just made it.
What I learned: I need to start working on my game a lot earlier if I want to give myself ample time to properly explore the current week’s idea.
Idea: I personally really enjoy the idea of local multiplayer games and games that force a physical interaction. Some good examples of what I’m talking about are Game Oven’s Fingle, Kaho Abe’s Hit Me!, and Doug Wilson’s J.S. Joust. This was my little contribution to that movement. It’s a two player game where each player can potentially have to press any key on the keyboard. The goal is to be the first person to destroy all of your blocks.
What went right: I started this game as soon as I finished week 1. Taking my lesson from the previous week, I was able to really give myself ample time to explore this idea. The final product turned out almost exactly like I pictured in my head, and I finished it on time.
What went wrong: It wasn’t a super fun game like I had hoped. I didn’t really take into account how unbalanced the physical part of this game could be. Testing it with someone stronger and much larger than I am felt extremely unfair, as it was easy for him to bash on the keyboard and keep me away from my keys. Though that was somewhat the point of it, it became very not fun for me very quickly.
What I learned: The physically interactive games that I like tend to not be easily skewed based on size and strength – they’re more easily manipulated by skill and technique.
Idea: This game turned out frustratingly bad. I’ve always had an affinity towards how music can affect a person’s feelings and experiences, and this was meant to emulate that. I saw CHVRCHES in concert at the Boston House of Blues a few months ago, and the opening act, xxyyxx, consisted of one guy on stage with his macbook pro making wonderful musical experiences. This game was meant to be my interpretation of what that would feel like to do. I wanted to create an experience on the iPad where the player would interact with events on the screen in time with the music in order to feel like you were creating the musical experience yourself. Sort of a DJ-simulator meets Fantasia: Music Evolved.
What went right: Almost nothing. This game turned out nothing like I envisioned and was one of the ideas that I had poured over for a long time in my head. It’s hard to to see an idea that you’re super excited about die a horrible horrible death.
What went wrong: I did not take into account how difficult it was so craft an experience exactly like it is in your head.
What I learned: Ideas should be explored as soon as possible. I need to stop building up an idea in my head as a wonderful concept if I have no real proof that it will be an experience that I’m able to create.
Idea: This week had an extra constraint of trying to create a direct interaction with the game. The first three weeks had very indirect interactions, and it clearly wasn’t working well for me. I wanted to make a puzzle game based controlling two different characters. Sort of a one player Ilomilo meets Flow.
What went right: I was able to create a direct interaction with the game like I had set out to do. I also learned how to create music directly inside of Unity. I focused a bit more than normal on the game feel for this and was able to get a nice thing going for the game
What went wrong: I only made one puzzle and the music was very jarring.
What I learned: I am not very good at creating puzzles. I struggled even creating the one puzzle level that made it into the game.
Idea: One of my favorite games so far. This game is based on creating a tower as high as you can, while not letting it tip over. This idea is another one that I had in my head for a while. I like the idea of a simple balancing game (inspired by Eyezmaze’s Vanilla), and have been wanting to try my hand at something like this for a while.
What went right: I really enjoyed how this game turned out. It worked almost exactly like I had pictured in my head and most of the things that I had to change from my original vision were things that I was able to critically think about and produce in a way that actually had thought-out game design and purpose.
What went wrong: A few of my solutions for design issues were cheap. To stop the player from simply building straight up forever, I made it so that you couldn’t build on blocks in the center. There’s no reason for that other than a cheap solution to a bad design problem.
What I learned: Simple ideas are easy to explore. I need to stick with one mechanic/one idea and explore that one thing fully instead of focusing on an entire experience. It helps to talk through the reasons behind design decisions and to ask yourself “why” you chose to create the interaction that you’re creating.
My first failure. I started my game this week based on a memory of an old game from my childhood. I ended the week with zero interaction complete – just a sprite of a pegasus on a backdrop of pixel clouds.
What went right: I thought a lot about a game that I have fond memories of.
What went wrong: Well, I didn’t finish a game this week. After spending a few months in the Netherlands, I was faced with flying back to the US and couldn’t bring myself to work on anything because I was too busy moping around.
What I learned: I need to not let my emotions get in the way of my development. There was no reason to mope around and not create a game. Not creating a game didn’t stop me from having to fly back to the US, and instead just made me feel worse. It was a lose-lose situation all around.
Idea: With the surge of local multiplayer games, I wanted to explore an idea I had related to that. When I play Samurai Gunn, I spend all of my time on the character select screen wall-jumping while waiting for the other players to choose their character. I love wall jumping and think it’s an interesting and fun interaction. My idea was to create a battle setup where each player had to constantly walljump while fighting each other. Obviously, the concept changed a lot throughout the week. The result was a one player wall jumping game where the point was to get as high as possible without hitting an obstacle.
What went right: I started this game early in the week and adapted my idea to my time constraints.
What went wrong: I didn’t think through the design of this game nearly enough. There’s no purpose to a lot of the interactions, and there’s no real feedback letting the player know how well they did or what the point of the game even is.
What I learned: Wall jumping is hard to program. I spent the majority of my week working on that and it left little time to explore other parts of the game. I need to not let myself get hung up on one problem for the whole week. If I’m stuck, I need to move on and revisit later.
Idea: Another attempt at a local multiplayer game. Unlike Week 2, This one wouldn’t focus on the physical aspect of it, and just rely on the interaction between the two players. This idea was inspired a lot by Hokra. Hokra has such a simple mechanic that works very well. I wanted to create a game where you could play defensively and/or offensively and really think about the strategy behind each type of play style.
What went right: The finished product was close to what I had envisioned and the experience is generally what I wanted it to be.
What went wrong: It wasn’t actually that fun to play with two people. The gameplay was a bit too slow and the interactions were not as intuitive as I had hoped.
What I learned: Playtest. Playtest. Playtest. Playtest. I personally thought it was a fun game to play once it was finished. Not quite as action packed as a game like Hokra is, but I found enjoyment in it anyway. However, I only ever played it with myself. I didn’t have many people around to playtest it for me, and I didn’t send it to friends soon enough to get any useful feedback. A game like this is impossible to develop without constant feedback.
Idea: I tried something new this week. I had become increasingly annoyed at my ability to be easily distracted and also wanted to try a new tool. I combined those two things into creating my very first Twine game called Game Dev: The Game. I often joked about creating a game based on how hard it is to actually make a game, and this was my attempt at portraying that. I’m not much of a wordsmith, so creating a Twine game was an incredibly daunting task for me, but I figured that I might as well challenge myself at the things I’m not good at.
What went right: Twine is awesome. It’s a great way to organize your thoughts and simultaneously create a game. I’m proud that I successfully worked with a different tool and feel like I got the general feeling that I had intended across in the game.
What went wrong: I didn’t give myself enough time to explore this as much as I wanted to. With Steam Dev Days being the same week, I pushed this week’s game towards the end of the week after all the fun and excitement was over.
What I learned: Putting new challenges onto yourself is fun. I need to work more on my ability to create beautiful prose, and, again, I need to start earlier in the week if I really want to explore an idea fully (how many times have I “learned” this lesson by now?).
Idea: By far my current favorite game to work on. Back at Game City in Nottingham, me and Joonas started talking about an “oculus text adventure” game. I loved the idea of using a technology that advanced to make such a primitive experience, and he loved the idea of creating an experience almost entirely based on sound design. I decided to use this week to explore how a first person text adventure would feel at all.
What went right: A lot. A first person text adventure is something that I found to be very fun and different. The environment that it creates feels amazing and forcing people to use their imagination is something that I really miss about text adventures/choose your own adventure novels. I feel like I was able to create an experience that was somewhat unique and entertaining, and even created a few puzzles that I was quite proud of.
What went wrong: With Global Game Jam approaching, I didn’t have the full week to explore this idea again. Because of that, the end was entirely rushed and didn’t feel like it fit into the rest of the game. Whereas the first few sections were interesting puzzles, the end utilized a cheap “gotcha” with a creature chasing you and felt very forced.
What I learned: Out of the box ideas are fun. Using a technology not quite as intended leads to things that are interesting and novel. Sound design is important and I’m getting a little better at words and puzzles!
Another failure. This week was a weird one because I actually made multiple games/prototypes this week. None of them, however, fell into the Game a Week mantra and thus, I technically failed. I had Global Game Jam (you can see my team’s game here) at the beginning of the week and then had a former co-worker/current collaborator was out visiting me all week in Colorado to work on a new project. We got a lot accomplished on this new project and Global Game Jam was an amazing experience, but between that and the 3 feet of fresh powder we got in the mountains, I didn’t even start a Game a Week game this week.
What went right: I got a ton accomplished in a lot of other aspects in my game development life. The new project I’m working on is going amazingly well and I’m extremely excited about it. Also, I had the best snowboarding week of my life. I spent most of my days back in the back bowls of multiple great ski resorts in the rockies and managed to not hurt myself (while snowboarding).
What went wrong: I didn’t make a Game a Week game
What I learned: A failure is a failure. I let too many other things get in the way of the one thing I said I would accomplish every week. I need to prioritize my time and not waste the the spare time that I have.
Idea: I decided to try my hand at a non-digital game this week. Because I rely so heavy on technology in my daily life, I figured it would be a fun challenge. And, as I was in Las Vegas for DICE, I decided that the only logical course of action would be to make a game using a deck of cards. There were a lot of constraints with using only a deck of cards to create a new game, but I ultimately settled on a two player game where you had to get your token from point A to point B. Each card in the deck would represent a distance and direction that you had to move and each player would attempt to reach their opponent’s joker card first.
I used the value of the card for the distance you could go (dividing the value by 2 since the movement value would be way bigger than the playing area size otherwise) and the suite of card as the direction you moved.
Playing off of the theme of the Global Game Jam a few weeks ago, the direction of movement is relative to the player’s viewpoint. This means that if player 1 is told to move left, then that player moves left relative to his or herself – not in respect to the playing area’s orientation.
I ended up making a custom deck for the game, as the rules were incredibly confusing when told in the context of playing cards. This means that I actually ended up making a card game that works much better NOT as a card game, but at least it’s non-digital as originally intended.
What went right: I set out to create a non-digital game, and I did so.
What went wrong: Again, I learn the lesson of playtesting. I had been working on this game on and off all week while at DICE (in between meeting with people and writing emails), but by the time I got it to a playable state, DICE was over and I was alone in a hotel room in Denver. I tried to play the game on my own, but it’s borderline impossible to play a two player game (which relies on strategy involving hidden cards from your opponent) all alone. I’m still not even sure if this truly works as a two player game – even after reaching out to the all-mighty internet for playtesting help.
What I learned: The more constraints I have on my tools, the more I’m forced to be creative with a mechanic. I’m not saying that technology is bad (I would NEVER), but it’s nice to put various constraints on yourself to see what you can come up with.
Also, writing the rules to a non-digital game is incredibly difficult. I had it all worked out in my head, and on paper, how it would work. However, creating a text that would explain to someone NOT in my head how to play this game was very VERY difficult. I have a new found respect for people who write the instructions for non-digital games.
HUGE THANKS to the ever-wonderful Andrew Gleeson for surprise making cards for the custom deck that are way more beautiful than the piece of junk I whipped up.
Idea: Inspired by a few of the more popular casual games out at the moment, I was curious to see what kind of experience I could create if I only allowed the players to perform one type of action. I settled on a simple mechanic based on your reaction speed and ability to make two things be the same size. I had some larger visions for this game when the week started, but I de-scoped until it was just one shape that you filled up over and over again.
After creating the core mechanic of the game and the basic loop, I realized that I didn’t actually find the game to be very fun. I then decided – what better way to make something fun than to add a little friendly competition to it! I salvaged an old leaderboard system that I had in another game that I worked on last year, plugged it into this week’s game, and POOF instant success (well, after 4 hours of refactoring and debugging an issue that only seemed to happen on the web build).
What went right: I was able to de-scope a lot of extra ideas earlier in the week. Also, the addition of the leaderboards at the last minute was a great last minute boost to the fun aspect of the game.
What went wrong: AGAIN, I learn the lesson of playtest. I didn’t post the game at all until Sunday night, and while I was sleeping I got a lot of really great feedback. Because of my self-imposed rule that I don’t work on any of the game a week after their week is up (at least not as part of game a week), I don’t know when/if I’ll be able to test some of these suggestions out.
What I learned: Competition is fun, and I need to really start posting a version of the current week’s game by Saturday at the latest.
Idea: This week didn’t actually start with a solid idea. I wanted to play around with a few features that I’ve neglected in Unity, so I simple started messing with a hinge joint to see what I could make it do. After creating the simplest of things (a hinge joint with an arm attached), I decided just to make another multiplayer game based on swinging an arm around to shoot balls into your opponent’s goal.
What went right: The game ended up fairly fun. Also, I learned a lot more about how joints work in Unity!
What went wrong: I didn’t get to add any sound effects or anything to this week’s game. By the time I reached that point in my development process, I was in Los Angeles, CA staying at a hotel that didn’t provide free wi-fi. Because paying for hotel wi-fi is incredibly silly, I was using a karma wi-fi device to connect to the internet instead. To save some data, I decided that downloading a bunch of sound files wouldn’t be the smartest thing in the world.
What I learned: How to use joints in Unity. In addition, after playtesting, there were two things in particular that I changed which made the game MUCH more intuitive and fun.
1) Originally, the game worked in such a way that you would shoot the ball into the goal that corresponded with your player’s color. This means that you started out by a goal of your color and you would shoot the ball back into that goal to score a point. Because I’m not much of a “sports person”, this made sense to me in the respect of collecting the ball into your own basket. However, the rest of the game really lent itself towards more soccer or football feel. By switching it around so that each player was aiming to throw the balls into their opponent’s goals, the game instantly became much more intuitive. The lesson learned here is that even if you’re not particularly in to a type of game (i.e. sports), you should still pay attention to the various mechanics of what makes sense to the larger audience.
2) Skill vs. Luck based gameplay. Until playtesting, the arms of the players were about four times as long as they currently are. This resulted in two things. First, the player could swing wildly around and still generally make goals. Secondly, the player could easily block the entirety of the goal effectively preventing the other player to EVER score. By shortening the swinging arms to their current length (and increasing the goal size a bit), the gameplay instantly turned much more skill based as the player had to actually aim to hit the ball and aim at the goal.
As you can see – out of the 14 weeks that I’ve been at Game a Week, I’ve failed on two of them. I have what I would normally call “valid excuses” for those two weeks, but in all honesty, any excuse is just that – an excuse.
Personally, every time I “fail” at anything, I take it hard. A failure to me reflects directly on my self worth as a human being and a contributing member of society. For example, failing at something such as Game a Week causes me to think: “Wow, you can’t even accomplish one measly prototype in seven days? You are a terrible game developer and will never be successful at anything ever”.
Obviously, this is an entirely counter-productive way to think, but when you’re laying in bed trying to sleep, it’s hard to keep your mind from wandering where it tends to go. I know a lot of people out there struggle with self-doubt and impostor syndrome, but even so, my mind still wonders “When is everyone going to realize that I have no idea what I’m doing?” (according to The Onion, it’s today).
I try to remind myself of all the things I’ve accomplished but, I generally end up rationalizing to myself why they don’t count as real “successes”:
Rational Adriel: “Remember that time you worked on Rock Band Blitz?”
Irrational Adriel: “Yeah, well, that was years ago and I was fumbling around in the dark and no one noticed. I actually had no idea what I was doing and can’t believe that no one picked up on that. I only really was hired because they were desperate for more programmers”.
Rational Adriel: “What about Train Jam? That got pretty popular.”
Irrational Adriel: “There’s no proof yet that it will be fun. Plus, I’m probably just making this organizing thing way more complicated than it needs to be. Someone else could have done way better with much more ease. Also, I’ve screwed up a lot of this along the way – it could be so much better.”
Rational Adriel: “Sooo, you do know that you wrote code that will go to space, right?”
Irrational Adriel: “So what? So did plenty of other people. That is a job that I objectively had no idea what I was doing at – I can’t STILL believe I worked there for that long without anyone noticing how stupid I was.”
Rational Adriel: “Okay, well how about [X]?”
Irrational Adriel: “It doesn’t count because of reasons [Y] and [Z]”.
It’s a constant battle in my head, and a battle that I’m actively trying to remind myself is untrue and unhelpful.
At Steam Dev Days, I talked with another developer (well, I talked to A LOT of other developers, but this one is relevant to the proceeding story). He’s a developer who is working on a game that I personally find to be awesome. It’s creative, has received praise from other developers and news websites, was successfully kickstarted, and has been greenlit. In my eyes, this guy has everything going for him. After a bit of talking, he began to open up to me about his insecurities. He lamented about how he felt out of place because he hasn’t produced a finished game and how he doesn’t feel like he can talk to the other developers because he’s not “successful”. He even referred to me as someone who is more successful than he is. Here is someone that by all units of measure is further along on something real than I ever have been, wallowing in his non-success to me. This is such the quintessential example of the self-doubt that runs rampant in our industry.
A good dose of humility is a quality that I consider to be important, but it’s dangerous when it starts crossing over into a territory where it messes with your self-worth. It’s something that I’ve been actively trying to recognize when it’s happening to me and push the negative thoughts out of my head. These thoughts do nothing to help me accomplish the things that I want to, and are counter-productive in every way.
It helps to talk to other people both inside and outside of the industry to process these thoughts. Seeing others have the same doubts, the same insecurities, is almost reassuring in a way. If everyone could see how scared everyone else is, maybe we wouldn’t all be quite as afraid to try something new.
I’m trying to live my life in a way where I simply just try to do things things – no matter how scary and how big the risk of failure is. If you don’t try, you won’t know, and in my eyes, not knowing is worse than failing.
If you see something that should exist where it doesn’t exist – make it exist. If you have an idea that you can’t stop thinking about it – explore it. If you don’t like something that is happening in your life – fix it. If you want to do something but haven’t for one reason or another – please, just find a way to do it.
Failure is a part of any meaningful endeavor in life. If you’re not failing, you’re probably not taking enough chances. You should mitigate against the fallout from failure, but you should not fear it. You can learn from success, but I find that you learn much more from failing.
The overall theme of Game a Week has been to just start making things. There is a HUGE difference between thinking about something and actually doing something – and this experiment has only proven it to me more and more each week. You can extend this lesson into a lot of different aspects of life, and for me, it’s been an incredible concept to take to heart.
You can play all of my game a week games here on my website, or follow me on twitter to keep up with the whole development process.(source:gamasutra)