Posts Tagged ‘game dev’
-
Flash Game Dev Tip #9 – Dealing with a lack of motivation to finish your game
2nd May 201110
Tip #9 – Dealing with a lack of motivation to finish your game
You are not alone
Everyone suffers from this problem at one point or another: You simply can’t face the thought of working on your game. This is especially hard when making the game in your “free time”. It’s all too easy to think “what the hell” and double-click that Team Fortress icon instead of FlashDevelop. And even days when your head is saying “let’s code!” all that motivation can vanish the moment you open the source and realise that its been so long since you were last here it’s like staring at a foreign language, or a giant brick wall and you have no idea what to start first.
There is no “single solution” to fix this. It’s extremely personal. Your reasons for not wanting, or being able to code will be as varied as the number of people reading this. But as I said at the start you are not alone – so I posed the question of how to deal with it to 13 fellow game developers and collated their replies. Hopefully somewhere in these insights you’ll find a technique or suggestion that helps you out. And if you have one that you personally use, not already mentioned, please post it into the comments.
I’ll kick things off …
Richard Davey / Photon Storm
I’ve come to realise that I’ve a game development mana reserve. When I start work on a game, my mana reserve is full. But as coding begins this reserve drops faster and faster. Sometimes if I hit a particularly troublesome spot in a game it can be enough to utterly wipe-out what reserves I had left, derailing the project entirely. But there are also the “wins”. Getting a significant part of the game finished, or adding something really cool. That helps re-fill my mana reserves and keeps motivation high. It’s a constant battle. To get the game finished before enthusiasm is depleted entirely, yet to have enough wins on-route that they keep things in balance.The “wins” however cannot be artificially placed into the project. They have to be unexpected and grow almost organically as a result of working on the game. Equally the hits to my morale are never expected either. I never start coding expecting to stump my toe on a bug from hell, but it happens.
There are two issues here:
1) Having the motivation to continue working on a game
I think like a lot of people I’m most excited about a game during the very early stages of it. The feeling of bringing something to life, of getting the idea out of your head and into code – that’s a real achievement in and of itself. I enjoy the task of getting a working prototype up and running, often with really crappy code driving it. The thing to do at this stage is to try and work out for yourself if you should stop right now, and not even attempt to carry on.
Use those prototypes
There is nothing wrong in building a prototype and just leaving it at that. Of course if you’re in this for the money it’s not going to get you rich, but if like me you do this for fun then you shouldn’t feel any sense of “guilt” for having made just a prototype. If by this point you recognise that your enthusiasm is on the wane already then don’t just file it away for another day, thinking you’ll come back to finish it later on. Because almost certainly it will never happen. If you don’t have the enthusiasm or excitement at the end of this stage to take the game further, then you never will.
Don’t waste it though. Think about how what you’ve made could be useful to others. Perhaps it’d serve as an interesting “I made this little demo” post for your blog or a forum. Or maybe it could be turned into a tutorial for a development site with little modification. You may be surprised at the response. I’ve had people see “demos” of work who suggested just one change, that radically altered the course of the game, resulting in it being finished and released. As I mentioned at the start, “mana refills” can come from anywhere, sometimes the most unexpected of places.
Do something other than making games
Making complete games is hard, there’s no doubting this. Even the most simple of games still require quite tedious boot strapping to make them suitable for release. But that “rush” and feeling of sheer joy you get when you finally publish doesn’t always have to come from making a game. As readers of my blog will know I work on a lot of game development projects such as my Flixel Power Tools or tutorials. I do this because I enjoy writing, but also because I remember what it was like being fresh to development – how I was a sponge, soaking up every last piece of information I could get my hands on.There is a real thrill in authoring this type of content too, and publishing it. So you don’t feel like making a whole game? No problem – could you make a demo that showcased how to make a sprite jump from platform to platform? The scale is significantly smaller, but the end result could be extremely useful to your fellow developers. And their feedback can be enough to spur you on during the more laborious development work you need to do.
Of course the downside of all this writing is that it takes your time away from making actual games, as Ilija will attest to 🙂
Public Beta Tests
We ran a public beta test of a game called Kingdums. We just put a build of the game onto a web page with a big feedback form below it, and shouted the URL onto twitter. It was live for a week. The feedback we got was fantastic, because it under-lined a significant flaw in the game (that was in the back of our minds anyway, but made it prominent) and reaffirmed that actually, this flaw aside, people really enjoyed playing it. Other developers use public beta tests for similar reasons – lots do it to find out if their games have bugs they’ve missed, but it doesn’t just have to be about that. Sometimes you’ll get suggestions that highlight issues you didn’t see, and sometimes it’s just a good morale boost.
It’s not just code that can be tested – you could post-up screen shots, character bios, even basic story arcs. All things that feed back into the game overall.
Enforced Time Constraints
Some people don’t understand the point of making a game in a limited period of time. Others relish the challenge. Personally I fall somewhere in the middle. I haven’t yet had a chance to take part in something like Ludum Dare, because I have a family life that stops things like that happening over weekends. But the times that I have made a game in a limited period of time (we’ve done it 3 times now) it has always worked for the better. Todo lists get cut down dramatically. Only the essential game aspects are given attention, and the time limitation really does focus your mind. Try it, it may appeal to you.
Using a To-Do List
You’ll see this suggestion raised time and again by the other devs below. Ilija and I use the free software Wunderlist. I like the fact I can add items from my iPhone or PC and have it all sync-up properly. We don’t have lists for prototypes, only for games deep in development. I find it pointless starting a list with “make an enemy manager”, that feels too early-on in the process for us.
2) Dealing with “getting stuck” while coding
This is the easiest to solve. If you have a coding problem, then you ask for help. If you don’t work in an environment where you can ask fellow coders for suggestions, then there are hundreds of really great game dev communities online. And you should join one and really participate with it. Help out other people suffering problems you may already solved, and post your problems up there also. More often than not someone will help, or at least direct you onto the right path that leads to solving the problem anyway. If you can’t solve the issue within a couple hours of trying, and can’t think of another way to approach it, then you need a bring a second brain into the equation. The longer you delay in asking for help, the more chance you have of never finishing.
Don’t feel guilty
You’re only human. Human’s need a fine balance between work, rest and play. And developers are terrible at balancing those three elements. There’s a famous producer graph showing “Price – Speed – Quality”, with the mantra that you can only ever have 2 of those 3 things. So “Speed + Quality comes at the expensive of Price”, or “Low Price + Speed means low Quality”.I feel that developers do the same with “Coding – Resting – Playing”. By “Playing” I mean taking time out from coding: watching a movie, spending time with your significant other, reading a book, playing Xbox, etc. Too much coding but the right amount of sleep usually means you give-up your “play” time. If you’re burning the candle at both ends, holding down an intensive day job and then coding all night, your Rest and Play can be sacrificed. If when you sit at your computer you find the code just isn’t flowing then stop. Don’t battle it, don’t trudge through. Just stop and do something else entirely (ideally non-computer based). Then try again the next day. If you’ve been working like mad all week, getting a few hours sleep a night, then pay off that sleep debt.
Development is a roller-coaster of highs and lows. If you recognise you’re on a coding streak then enjoy it and use it to your advantage, but when it ends (and it will end) switch track quickly and work on something else. Then switch back again. The quicker you learn to recognise your “moods” the more useful you can make them. I’m not perfect at this yet, not by a long shot. I still have lots of “unfinished” games, indeed the artwork I used to illustrate my text above is all taken from games I’ve not yet finished, and there are plenty more. But I never sit idle. I do at least work and release. If I’m not making a game, I’ll write, and if I’m not writing I’ll help out in a forum. If I’m not in there maybe I’ll be playing a little Counter Strike. The point is that I feel I do balance them well, one doesn’t over-power the other. I just wish I had more hours in the day 🙂
That’s me done with, now onto 13 other developers for their views on this subject …
-
The Essential Guide to Flash Games: Book Review
6th Sep 2010
Update: For a 25% off Discount code read to the end!For the sake of transparency I just want to state: Friends of Ed offered me a free copy of this book for the purpose of reviewing it. However I declined as I had already pre-ordered my copy from Amazon, as I’m a great fan and friends with the authors Jeff and Steve Fulton. That doesn’t mean I’m going to treat this book with kid gloves or sugar coat my review however.
Dissecting a mammoth
Jeff and Steve Fulton, the pair responsible for the ever popular 8-bit Rocket web site, home to many tutorials on Flash game development, decided to combine their collective knowledge into one single tome. And this is the end result.
The book is split over 12 chapters which make up the majority of its 630+ pages. The chapters are split into two parts: Basic Game Framework and Building Games. It kicks off by going through their “Second Game Theory” which basically says your first game will always be utter tripe, and things only really start getting interesting from your second game and onwards (or if you are like me, your 10th game onwards). But it does cover some basic concepts such as proper object-orientated coding, but always in a game context. That is what I like most about this book, every snippet of information relates to making games, not some random computer science terminology you’ll never care about or commit to memory.
It then dives head first into building a game framework, including a solid and re-usable state machine, game timer and event model. By page 15 you have finished coding your first game, and while it’s a simple click counter it all runs from a well defined framework that is re-used and expanded upon throughout the rest of the book.
The second game is “Balloon Saw” in which you control a spinning blade with the mouse, and must take out as many floating balloons as possible. Again it’s simple, but it introduced more important new concepts: level progression, player controls, collision detection and scoring. By page 30 it’s all over, the lessons are learnt, you’ve another game under your belt and they waste no time in jumping into the 3rd game: Pixel Shooter.
Once Pixel Shooter is over you’ve got a complete space invaders style game finished, and more importantly they don’t dwell on every aspect of it – but only those aspects that differ from the previous game. I’m a big fan of learning through iterations, and that is certainly how this book approaches things.
Once you hit Chapter 2 it’s all about strengthening the framework you’ve already put in place. They add lots of powerful new features such as Custom Events handlers, a Basic Screen handler, Buttons and a Score Board (which is more the in-game UI for scores, not a Mochi Leaderboard type affair). Several pages are dedicated to the package structure, creating the game stub (which is done via FlashDevelop) and just setting your project up in a nice and clean way. Again I’m a big fan of this approach, and I have my own “template” project structure that I roll-out for all new games I write which matches theirs very closely. You don’t have to follow their structure to the letter (although it would be useful if following all of their game builds in the book), but by all means take from it the parts you find most useful, and settle on what works best for you. But the final message is the same: don’t be messy.
By page 100 the framework is in place. This is quite a hard-going chapter, and while vital for the rest of the book I can see a lot of developers getting that glazed look in their eye as they pour through page after page of class set-up and variable declarations. As important as it is I can’t help but feel that it may have been better to keep up the earlier frenetic pace of game building, and drip-fed more of the framework in the same manner.
Once the framework is in place Chapter 3 creates the “Super Click” game, an iteration of the very first game made in the book. It starts off by getting the reader to create a really brief game design document. All it asks you to do is write a very short snippet about what the game is, and define the basics such as the name, the objective, a description of play and creating a list of required assets/logic/variables.
It may seem long-winded to be doing this for such a simple game, most of which you argue you could just “remember” rather than write down. But GDDs are a tried and tested practise found in the industry. Any game developer I have working in my team will all have to write GDDs before they touch a line of code, and Jeff and Steve are the same. So if you plan on making Flash games as a “pro”, don’t skip this part.
Taking some Flak
As you may expect by now Chapter 4 is all about creating yet another game. This time a homage to Missile Command only with boats and planes. Jeff and Steve are children of the 80s and the Atari blood runs deep through their veins. You’ll see this scattered through-out the book, not least of which is a whole page dedicated to the history of Missile Command and it’s variants opening this chapter! As a fellow Atari fan I loved these sections, but I can see why the younger developers reading the book may care a lot less.
Flak Cannon, and indeed all remaining games in the book, use sprites from Ari Feldman’s now infamous SpriteLib collection. It also gets all sound effects from the SFXR app. So sadly it’s going to look and sound quite dated before it’s even left the gate. Now I’m a massive retro gaming fan, and I have utmost respect for the “classics” and reinventing them in Flash. But even I don’t feel that SpriteLib is a strong enough graphical resource for a book like this. Jeff and Steve would have benefited massively from employing the talents of a real pixel artist, who could have created something beautiful for each of the games in the book. I don’t think that visually any of the games portray just how solid and robust a framework is powering them. My concern is that developers will take one look at the games on offer and visually dismiss them, asking why they look so “old”. This is a crying shame, as internally they are as fresh as can be, employing all of the modern tricks and techniques you need for a flash game these days. It’s just the surface gloss that doesn’t match.
Work your way through the Flak Cannon game build and at the end you’ll have a really powerful Sound Manager class added to your arsenal, along with an understanding of vector movement and angles in Flash. This is where my second biggest criticism of the book stems: there are many absolute nuggets of code gold buried in the 630 pages of this book, but they require some serious digging to extract. Although the index and contents do a good job of explaining when you’re about to learn a new technique, such as Line of Sight, AI or 2D Cameras, being able to extract those techniques out from the game in which you’re learning them is not an easy task. There’s very little “throw this code into the IDE and see”. For example the minimax-styled AI routine used in the game Dice Battle is so tightly ingrained into both their framework, and the game itself, that you’d have a harder than necessary time extracting it for your own project.
It’s all about post-retro, baby!
The love of all things bitmap starts with the Flak Cannon game, and really doesn’t let-up from there on. By the time you hit Chapter 6 (“No Tanks!”) you’re well down the road of tile editors, Mappy, sprite sheets and blitting. There is no denying that this is the fastest way to shift graphics around in Flash, but it’s not the only way. And it may feel very alien for devs coming direct from the Flash IDE to even bother with the likes of a sprite sheet and non-timelined animations. The tilemap system introduced in chapter 10 is again all about the blit and “old-school” tilesheets.
Personally I don’t have a problem with this, but I think it’s important for devs to realise that when coming to this book that is the approach they are going to be taken down. And while it’s a tried, tested and very fast route to pursue, it’s also not the only one. There were many times reading this book that I felt it should have been called “The Essential Guide to Building Bitmap Blitted Games in Flash”, because quite frankly there is no other book that covers this subject in the kind of depth the Fulton’s do. And I doubt there ever will be (unless they publish a 2nd edition!)
Towards the end of the book Chapter 12 deals with a host of important topics that you rarely see mentioned in any other Flash game book. They cover making money from your game, via both Mochi Ads and licenses / sponsorships. Securing your game with site locking and encryption, marketing, pre-loaders and Mochi leader boards. I thought this was a really nice touch, it just makes it all seem more “real” – as these are all the kinds of things that new Flash game devs will go through, and may not yet be aware of.
Game Over Man, Game Over
I truly admire Jeff and Steve for having had the balls to even write this book in the first place. I know just how much hard work it was, and how much effort they put into it. Does this cloud my judgement somewhat? Perhaps, but ultimately it’s up to you to decide if this book will be a “good fit” or not. Personally I’m a firm believer that you can never have too many game development books, and this is one that certainly has a place on my bookshelf. There are quite a few typos and spelling mistakes to be found (“MoveClip” being a popular one!), and even their game Super Click says “Click the blur circles” at the start (it should be “blue”). But I can overlook these small things. Hopefully they don’t extended into the source code too!
Yes it’s very “hardcore” about the approach (blit-mapped to the max), but only because they care about performance. They cover a lot of advanced game making topics, and a lot of subjects that no other book even looks at. They teach you and they teach you rapidly, pulling no punches, and without much filler.
If you’re the sort of developer who just “dips into” books, and extracts only the bits you need at that point in time, then you’re going to have to work a lot harder with this title. The content is there, but mining and then refining it into a usable state will take longer than perhaps should be necessary.
If however you have the tenacity to work through this book from start to finish, then I have no hesitation that you’ll come out the other end knowing a great deal about game development in Flash. You’ll have a whole ammo case full of fantastic routines to use, all sitting on-top of a solid and easily expanded framework. And to me that’s worth the cover price alone.
Buy the paper version from Amazon
Special Offer: Buy the PDF eBook version and get 25% off by using the code PHOTONSTORMECN
-
The 8-bit Rocket auto-biography is out
15th Mar 201020 man months of work.
Copious amounts of writing, editing, re-writing, re-editing and editing once more.
Stacks of demo games and hundreds of lines of quality source code.
All to make this the finest 650+ pages of AS3 game development ever commited to dead tree.
Jeff and Steve, the 8-bit Dynamic Duo have done it! Their book is finally out …
The Essential Guide to Flash Games: Building Interactive Entertainment with ActionScript
Despite having a slightly odd title (how many games have you ever played that weren’t interactive?!) this book looks awesome. I’ve pre-ordered my copy from Amazon UK and will give it a proper write-up when received. I have major respect for people who hold down full-time jobs / families, and still manage to produce such a mammoth book as this.
There is a bit of blurb on the Friends of Ed web site about it, although not as much as I would have liked. For example no contents listing, no sample chapter, a poor quality cover image and no index even. Given how many books on web development FoEd produce it begs the question why their own site is so shit. But I digress (and hopefully they will update this page over time). So for now the best place to learn about the contents is from the horses mouth so to speak, here on the 8-bit Rocket.
Congrats Jeff and Steve – I wish you all the best with sales. All you have to do now is stop calling my games advergames and the world will be perfect 😉
Hire Us
All about Photon Storm and our
HTML5 game development services
Recent Posts
OurGames
Filter our Content
- ActionScript3
- Art
- Cool Links
- Demoscene
- Flash Game Dev Tips
- Game Development
- Gaming
- Geek Shopping
- HTML5
- In the Media
- Phaser
- Phaser 3
- Projects
Brain Food
