Since it has short ears and no dark markings, I guess it’s a rabbit, not a hare.
from reference
Hot Coils
Cool! An article using one of my Creative Commons pictures.
How to Calculate the Surface Area of a Coil.
This is exactly why I allow some of my art to be used. Here’s the image link on flickr.
The source is an circle extruded along a NURBS path in Maya, the shader is Blinn with a ribbed diffuse and bump map, plus a chrome environment map. I set the camera to a wide angle for the extreme perspective effect and used the depth of field setting. I brought the rendering into Photoshop and hit the center with a color mapping layer set to a blackbody palette. It was an experiment to recreate the Organic Steel look of the X-Man, Colossus.
Roosting bird
I indulged myself by getting a new art pad and some pens.
It’s certainly easier to pull an autotrace line from a clean original.
Even with a handheld iPhone. Still need to work larger than my habitual 2 inches across. Bad habit.
A bird’s nest
- has a bowl shape
- has thick walls
- is made of many short, straight sticks tangled together
To really sell it, throw in some eggs.
Game Art Regeneration Sprint: a mini post-mortem
At the end of October I started on a sprint to regenerate and rework all the game artwork.
Partly to upgrade to Retina resolution and partly to match the character art more closely to the user interface style. Less retro pixels & more children’s book illustration.
I estimated about 100 items of work that would take a week if I did 12 items a day. It took nearly 5 weeks. Doh!
What went wrong?
Disorganized source files. My asset organization system was a mess. I’d started out with neat nested folders but as the game evolved, the original categories made less and less sense. If I needed to do some exploratory art development, I’d put the files in a temporary location, then pull some of those into the game as a concept gelled. Some art needed extensive batch processing steps, like rendered animations. There were photos, scans, Illustrator paths, 3D files in several formats, render files and presets. Even so, it just got worse over the months and I knew I’d eventually have to overhaul the whole system. Eventually became now. Luckily I’m a digital packrat and rarely delete intermediate files.
Rusty illustration skills. What can I say, all the money I’m living on while I write THE OCTOBER GAME came from digital retouching, graphic design and 3d rendering. Yet I’ve let my hand-drawing skills deteriorate in a quite shameful fashion. It took many, many hours of painful scribblings before I got something I could live with on screen. I forgot how long it took to warm up the drawing muscles. I also forgot that if you’re not working from reference, you’re wasting time.
Work-like activity. In an attempt to stave off burnout, I sometimes took a few hours to practice UI design, prototyping and programming with little side-projects. It might be a game mechanic or maybe implementing a particle system. The things I learned weren’t a waste of time per se but I could only stand to be on the computer for so long each day and these projects burned up that time. These activities feel like work but they shouldn’t displace work. I’ve resolved to do game tasks before any other kind, going forward.
Low overall efficiency. Besides getting 60% as much done as I would predict, I typically underestimated complex tasks by 4X! The result? An exhausting number of things to do and a demoralizingly long list that grew over time instead of shrank.
What went right?
Getting better at planning. I’ve made great strides with the maxim “Measure twice, cut once” and “Third time’s the charm”. Before writing code, I write the problem down and I come up with at least three ideas. I break the work down until I can clearly visualize each step, then I try to predict how long it’ll take. I’m getting better at it each month.
Logging everything. You can’t improve what you can’t measure. Each and every day since July 6th, 2010 I move the cursor down to a line that reads “eliolhan work done – “. If I’ve moved my business forward, I put the information there. If not, I type “none” and I resolve to do better the next day.
Increased software writing skills. The code I’m producing now is significantly shorter, faster and has fewer bugs than work I did six months ago. Bug fixing now takes hours where it used to take days. I don’t throw away all that old code, though. I refactor and rework it.
What I learned?
Clearly I have to plan better, estimate better and work smarter. I’ve started by tracking efficiency on a daily, rather than monthly basis. I’m also tracking more fine-grained time estimates to build up a better baseline for later analysis. In the last ten days I’ve done as much work as the previous month, by keeping a closer eye on how I spend my time in front of the computer. We’ll see if it’s sustainable.
Next steps
I’m currently extracting the core classes in the game and placing them in a fresh app template. Along the way I’m doing some cleaning up and lots of bug fixing of older code.
Work blocks: Their causes and remedies
I listen to the Merlin Mann podcast Back To Work. One topic was Getting Unstuck (time 1:18:00 to 1:20:15). I recognized some areas where I’ve made progress. Let me show you them.
Too many options
I list options on paper to take them out of my head. Then I quickly prioritize them. After about an hour, I review the list and pick an item to work on.
Expectations are too high
I have to remind myself that I’m nowhere close to being an expert after only two years of coding. I give myself permission for a crappy first draft, knowing I’ll do at least two more passes to polish the work.
Can’t see the core or the real story behind the work
I make a quick mind map to find nodes with high connectivity. That quick brain-dump is usually enough for me to re-focus.
Can’t trust your own motives
I list the first five project justifications that come to mind. Then I list some more. This lets me drill down past my surface thoughts to the underlying motive. I’ll take a look at my Core Values statement and compare them. I’ve learned the hard way that a subconscious, unexamined conflict is an endless source of self-sabotaging behavior. You can’t exert your full effort if the work isn’t compatible with your values.
Afraid of mistakes
The road to confidence and expertise is paved with mistakes. I record mine to document my flawed thinking process for later review. I also use them as fodder for blog posts. Hopefully, it’ll help someone improve their own processes. In this way, I extract value even from my errors. There’s no avoiding mistakes, so you might as well make them pay rent.
Afraid you lack some needed skill
It’s impossible to know what hidden talents you may have. Time and again, tasks I thought would be difficult turn out to be easy. While I don’t expect this to happen every time, I have less anxiety about it than I used to. It never hurts to dedicate a single whole day to trying something new. If you’re lucky, you’ll discover a hidden aptitude. Or you might be able to generate a useful approximation on the fly. Or you might find a weak area that can be shored up by a short course of study. Or you find an area of permanent incompetence that has to be routed around by outsourcing or avoidance. In any case, you can’t predict the nature of these unknowns in advance, so just try first.
Take it easier on yourself
Pathological Perfectionism is Private Pride. Deep down you think you’re like the protagonist in stories. Born with a destiny. Hidden superpowers. Unlocked after the first exposure to the Grand Challenge. This is especially true if you were recognized as a gifted child. It turns out you can substitute a Destiny for Greatness with stubborn, obsessive, sacrificial, relentless, aggressive, perceptive, repetitive, bare-knuckled, savagely-controlled effort. Did I say take it easy on yourself? I meant, get over yourself.
Now get back to work.
Posted in iDevBlogADay, philosophy, process, rants
Tagged back to work, core values, crappy first draft, getting unstuck, mind map, perfectionism, pride
2 Comments
Rejected Elaborations
Rejecting features is a vital phase of the game development process. Skip it and you risk the all-too-common failure mode of Overwhelming Complexity.
While THE OCTOBER GAME has grown in scope, there were plenty of features I deliberately didn’t include. There’s a Steve Jobs quote, “Innovation is saying no to 1,000 things“. Which is great, but the real reasons I rejected a feature were less high-minded: Uncool, Too hard, Unnecessary
Uncool – it annoys me when other games do this:
- Cut scenes and cinematics before gameplay
- Leaderboards that pop up before gameplay
- Integrated tutorials that interrupt gameplay
- Social media integration that let you bug your friends and spam your followers
- In-app purchases that destroy game balance
Too hard – too little return on investment:
- Save games
- iPad layout (universal app)
- Instant replays
- Multi-player
- Localization
Unnecessary – complicates the game:
- User-created levels
- Extra lives
- Enemies that take multiple hits
- iPod playlist support
- Video-out
- Power-ups
Every single element I did include turned out to be 10x harder than I predicted. How much worse would my situation be if I’d included features that I didn’t even want? You should also be aware of the Sunk Costs trap. Once you start working on a feature, it’s very hard to bring yourself to abandon it. Not only do you have to discard real effort, you also have to exert energy to undo the work. You’re far better off if you don’t even start down that road. That means minimizing features or at least doing the cheapest possible work (planning and documentation) first.
How do you decide which features to reject? The answer isn’t simple but what I do is have a set of core values and strong opinions on games and the development process. I also recognize the constraints I’m working under. These all act as filters to reduce the game project to an appropriate size. I have a bias toward reducing because I’m a solo newbie with more time than money & more ambition than brains. You’d better know yourself and you’d better do your planning upfront. Also leave yourself a line of retreat.
If the project was a:
- turn-based, multiplayer board game
- ten-person team on their 5th project
- with a firm, 6-month deadline
- at the $2.99 price point
- targeting iOS 5-only
the feature mix would be much different. For instance, there would be a greater need for viral, social features and the case could be made for a universal app. You could justify video-out if someone on the team could figure it out quickly. You get the idea.
That all said, any rejected feature can be revisited after the game is ready for user testing and after first release. Only a genius could predict everything upfront.
Posted in Uncategorized, philosophy, process, rants, traps
Tagged complexity, core values, features, sunk costs trap, THE OCTOBER GAME
Comments Off
Switching gears to get unstuck
Last week I finished a long-overdue upgrade to Lion, Xcode 4 and the latest cocos2d. After I got THE OCTOBER GAME running again, I turned to updating the artwork that I talked about last time. The work wasn’t hard, but I just couldn’t bring myself to focus on it. I think I’d worn a dent in my brain.
When I get blocked or burnt out, I take one of my other game ideas and work on it for about a day. It’s good practice and it resets my head. I had the vague idea of joining parts together to make a rocket, that would then aim itself at some enemy mothership. I wrote the concepts on 3 x 5″ index cards so I couldn’t bog down in detail:
The idea wasn’t totally stupid, so I elaborated on more cards. This forced me to think through the interactions and the cast of characters.
Most of my game ideas only make it to the index card phase. This idea had promise, so I scanned the cards and put the info in a text file. I made a short design document identifying the theme, hooks and play mechanics.
Then I stripped the idea down to it’s core: Joinable parts that turn into ships, that fly at an enemy. This would make it easier to test the basic concept. I was having trouble visualizing the mechanics, so I got some physical components and acted out the play pattern. Coins were joined to clothes pins, which became cups (ships). The ships then flew into the enemy (stacked cups). I made sounds and everything. Pew pew.
Eventually I had to make the visuals more concrete so I did a quick Photoshop mockup from my clip-art stash. This would be a landscape-oriented, iPad-sized game:
I made a minimal app from this concept, to see if it felt right. I gave it the code name Montador, spanish for “assembler”.
Except for the icon and the space background, I strongly resisted the urge to generate real graphics, and just built with colored squares. Graphics and animation are a huge time sink & a temptation to noodle around.
This took 16hrs in total. My long-term skill goal is to go from napkin to working app in a single work session. I may or may not revisit it. Or I might incorporate some elements into another prototype down the road.
The next day my art block was gone and I wrapped up another chunk of the game.
Posted in Technical, Uncategorized, creative, iDevBlogADay, process, traps
Tagged burnout, stuck, switching gears, THE OCTOBER GAME
Comments Off
GameOver, man
Feature evolution: The Game Over Display
I build art for THE OCTOBER GAME in stages:
- Sketchy art – just as a placeholder
- Draft art – ties in with the game theme somehow. There are multiple cycles as the style evolves
- Final art – polished versions plus high-res for the iPhone Retina display
Originally the game just ended and displayed your score and final level.
But that was too straight-forward. I thought you should get some idea of how well you played overall, like a rank. I checked an early design document and found some rank labels.
Then I felt just displaying these as text was lame. Show, don’t tell. I wanted some token graphic to signify how well the player did. I originally thought coins or medallions but the metal artifacts didn’t fit in with the organic theme.
I needed some item that had connotations of rank and status, that a kid could understand and a cartoon frog might be seen with. I came up with…hats. They’re cheesy but they fit the bill. Western cultural bias noted, shut up.
I colorized them for more visual separation.
Later I whipped out some 3d hats in ViaCAD so my eyes would stop bleeding. I posed and colorized them in Photoshop CS4 Extended, which lets you work with OBJ files.
I did just enough work to allow me to plop them in the game and move on to another area. But just showing a graphic seemed too abrupt, so I tried a map view where the player could see their overall progress thru the levels. Notice the quick and dirty sketchy art.
Then I realized how horrifyingly late the game was and switched back to the hats. My time was better spent working on fixing bugs & improving graphics performance.
Then for deep-seated psychological reasons I revisited this area because the player would see it every time they lost all their lives (cue evil laugh). I made some blobby stand-ins when I realized I didn’t know how to draw frogs. At all.
Eeesh! I never had much interest in drawing animals as a kid and here it came back to haunt me. Sigh. When you don’t know how to draw something, you grab reference from the internet and draw it over and over until it starts to sink in. I also sculpted it in clay to build up the forms in my head.
Luckily this is a video game, not a field guide so I had lots of leeway. In my opinion you just have to include several core “froggy” attributes and you’re good to go. If it’s green and oval-bodied with wide-set eyes, then it reads as FROG. I also re-illustrated the hats in a more cartoony style.
There’s still work left, like improving the pose, the mouths and shading details. Also making a “Loser” version and 6 kinds of hats. But this works better than the rather abstract hat icon, don’t you think?
Other parts of the game have evolved similarly. If I had it to do over again, it would go faster but there’s a certain irreducible amount of work and rework to get a polished feature into THE OCTOBER GAME.
Posted in Technical, creative, iDevBlogADay, process
Tagged artwork, cheesy, draft, frogs, gameOver, hats, illustration, polish, ranking, show don't tell, sketchy
Comments Off
The Game Deadline Problem, part 3
THE OCTOBER GAME was taking longer to finish than expected. Since I was unwilling to abandon it after some arbitrary date (that is, set a true deadline), I had to improve my development process.
Why was the game taking longer? What made my predictions so unreliable? What could I change?
Scope creep
I added game play achievements (Cheevos) for a richer experience but it was very costly in terms of complexity. My remedy was to stop adding new features and even defer polishing existing areas until all core functionality was done.
Under-planning
Previously I would start coding features or components without considering alternative implementations. Early bad designs slowed later work and made me reluctant to change course. This fed on itself until I was forced by skyrocketing bugs to back up and start over. It felt like I was being agile but I was actually guilty of shallow thinking. Now I do more up-front planning, with a pencil, paper and lots of diagrams. I force myself to write down at least three ideas before implementing any feature, along with pros and cons. Then I make myself wait about a day before choosing a method and starting to code it. Very often this cool-down period results in simpler design.
Over-engineering
It’s so much fun to code that I would chase the siren of code reuse and make classes overly general, adding functions that might be used in the future. WRONG. WRONG. WRONG. You ain’t gonna need it. Another way I restrained my enthusiasm was paper planning, mentioned before. Writing with real pencil and paper slowed me down, plus it was easier to abandon a bad idea before I’d created unit tests, art assets and typed lots of code.
Code disorganization
I put too much functionality in my cocos2d scenes, leading to monster Controller classes with scores of methods. I would start with concrete, hard-coded values and replace them with more configurable pieces as I went along, in a layered approach. My mistake was leaving all this code in place. The better way to work was to extract sub-methods into their own classes sooner rather than later. The resulting parts were smaller and easier to test & modify.
Under-testing
Since so much code was trapped in massive Controller classes, it became harder to test elements in isolation. I’d dabbled with Xcode’s built-in unit testing framework, SenTestKit, but I had trouble comprehending how to write tests without having them running live in an app. To get around this, I did manual, ad-hoc testing. It was a real pain to set up and I only did it for the more convoluted Model classes. It was better than nothing, but as time went on, the tests would get out of sync and I’d disable them for older areas. This caught up with me eventually and I had to buckle down and learn how to use SenTestKit properly. I’m back on the testing bandwagon now and my newer code is in better shape.
Performance slippage
This was the opposite of premature optimization. I made two big errors. I repeatedly waited too long to test performance on older hardware and I allowed nested loops to happen too often. Calling a method 300 times every 1/60th second is NO way to make a performant game on an iPhone3G. This was the single greatest cause of delay on the project. I’m on my third rewrite of the core game code and it’s mainly for performance reasons. Each time I’ve had to do it, it took longer because of previous bad design decisions. This last rebuild has a much flatter design and more work is done by the underlying game engine.
Simple inexperience
It took quite a while before I comprehended the cocos2d way. This led to costly dead-ends and performance bottlenecks. In the past year I’ve learned a ton about good class design, proper testing and how to manage the non-coding aspects like work-life balance. I was simply too new at everything to have avoided most of the mistakes I’ve made but by continued practice, research and analysis I get better at making THE OCTOBER GAME.
Posted in ProTip, Technical, iDevBlogADay, process, traps
Tagged cheevos, cocos2d, deadlines, performance, testing, THE OCTOBER GAME
Comments Off