Engine Hacking Marathon; from start to finish.

We all have our moments when we doubt our skills (no matter how good we think we are); This is especially true when we're tackling unfamiliar territory.

Let me elaborate some 'fear items'; problem states that manifest inside a young hackers brain-space;

1.  A sharp learning curve in technology API X.

2.  A sudden surge of labyrinth compiler errors and heisen-bugs.

3.  A lack of enthusiasm; avoiding code seems easier and more comfortable.

4.  The Engine Module that will not be tamed.

I'd like to also note that cambrian explosion in engine technology; just look at the flood of tech available to a junior hacker today, we have to worry about EVERYTHING from OpenGL all the way to Lua.  Under such conditions, a junior programmer may feel overwhelmed.

The common solution is holding a conservative attitude;  'Oh, I don't do language X, because its way out of my league.'  'I don't really have time to understand all of this!' 'I just wanna make a game'

...

This mental exercise I have been practicing, and fine tuning, for the past 2 years helps me build more confidence, and it certainly helped me survive the cambrian explosion.  Granted, everyone has a lot to learn, this mental exercise is geared on building confidence and stamina, with respect to the art of engine code.  Part of this regimen was adopted from training manifestos I experienced in the USMC (don't worry, the physical aspect of this marathon won't kill you or anything); I've adapted similar models from marksmanship training and conditioning, and applied them to the hacker mindset.

Step 0 : TIMING and SCHEDULE

If you are 'short' on time, make time.  You will need 7 full days for this training cycle. This regimen isn't built on quick fixes.  You need to adjust your sleep schedule as follows; Sleep 4 hours, Code for 8, sleep for 4 hours, code for 8, repeat.

It looks harsh, but not really; you're only doing this for no more than a week.  (If you go beyond that, well, don't blame me if you get diagnosed with schizophrenia)  Make this sleep/work regimen, and stick to it.  It's only a week, but its a week worth hacking.  Find time to eat in front of the terminal.  You WILL get enough sleep; you are allowing yourself to spend more time working, and less time feeling tired and exhausted.

The usual 'hot pockets + mountain dew' feeding cycle DOES NOT HELP; I advise on rice, ramen, coffee and fish-sticks.

If you are a physically athletic person; I suggest a 2-3 mile run daily before starting the regimen.  If you aren't well, maybe now's a good time to start? :)

Step 1 : TARGETS and TRAINING

There is no way in Hel that you would sufficiently grok 'Ginormous Suite Z : Enterprise Edition' in a week. And it's probably not worth it, most 'enterprise' crap will make you a worse coder anyway.  This isn't "Teach Yourself C++ in One Week" neither; this is about mastering a route of engine technology, and nothing more than that route.

Notice that I didn't say 'engine module'; we'll get to that in a moment.

Ask yourself an honest question; "Where do I suck?"  It has to be something concrete to a game engine.  The target is something that you want to hack elegantly and efficiently.  You must also posses an honest drive to add this to your repertoire.  

Performing object-oriented pyrotechnics and feats of gallantry on your 'full-ranks' skill set will gain you nothing.  

You have to be honest with yourself; there's a piece of technology in front of me, and I can't understand it, I MUST understand it.  This is the feel of the ideal target for you.  That way, you can go from suck to grok.

Possible targets as follows;

'Learning properties of language X'. 'Writing my own scene graph'. 'Writing my own memory allocator'.  'Making an AI system that doesn't explode at run-time'. 'Porting library X from operating system Z'.  'Writing cache friendly rendering loops.'

Notice that the targets listed are not whole engine modules, but rather, parts of them, or accessors to an engine module.  Also, you are the only hacker that knows yourself the best; don't try to train on something you don't love nor something that sparks no interest.  

Nothing is worse than a training track that isn't fun.  You might as well write in COBOL.

Step 2 : THE STATE of GROK

This is your goal.  

Nothing else.  

You must come out of this week knowing that you GROK the engine route.

Step 3 : REGIMEN and READING

So here it is, you found your route, you have the time, you're loaded on fish sticks.

But first, arm yourself with the following materials;

Build system + IDE.  Equipment failure should not stop you.  Make sure you have a version control system, and a build order through your IDE.  (Unless of course, this is your route.  In which case, make sure you have up to date reference material for IDE X)

Music, run it in your room/workstation for the duration of the cycle.

GDC-Vault videos + powerpoints, research papers, online tutorials, and articles from Gamasutra, re-instating the ACM subscription, all those papers you ignored in senior year. I found it fondly amusing that the articles from 1998-2000ish solved fundamental problems we still encounter today.

Remember that old book on algorithms that you haven't touched since freshman year?  Bust it out.  Graph theory is your friend.

Get a profiler.  As an example; iOS and SDK provides Shark.  Profilers can help you spot tight spots in your code, instead of having to spam 'printf' all over the place.  (Although a profiler may not be relevant if you aren't going for optimization.  Can't hurt to have it though)

And most of all; NEVER GIVE IN.

During your 8-hour bouts, start at simple steps inside your route; if this means using the 'hand-holding material' from the tutorials; DO IT.  You must place yourself in the mind of an acolyte; learning from the masters is far more valuable than your own failures, even if it means crawling through each step of the tutorial.

Once you have grokked the simple steps, escalate as soon as possible.  You must ensure that solutions stay fresh in your head, and the solutions you find plot you down your route.

A crucial point in the regimen is READING.  You WILL spend a lot of time dissecting research papers and sample code.  This is the majority time-sink, if not 65%, of the time you will spend in the coding triathlon.

Don't feel bad if you catch yourself reading endless amounts of papers and tutorials; you are in great shape if you are constantly seeking information.

Like all training exercises, independent of any craft, repetition is the key.

Hacker's have it even easier; we have the advantage of replication.

Consider the following; You had no clue on how to load a texture in OpenGL, so you draw up a tutorial, walk through the steps, and present your own solution.  You are able to get a fresh build, from scratch, and implement the same functions by simply recalling the steps.

With respect to other skills and crafts, replication is not as simple.  Marksmen have to constantly be at the range, and always in tune with their 'zero'.  'Replicating' a shot is not as simple, it is very probabilistic (compounded by wind, light, weapon-zero, breathing).  Artists hone years of experience into developing a style.

Part of this training regimen depends on 'core targets'; after all, a game engine is nothing but a series of components that perform specific functions is a game.  Mastering one component means mastering a fundamental part of a game engine.

Step 4 : PACE and STRIDE

Let's get real; you probably are feeling that your route is way ahead of what you can accomplish.  Most likely, this is Day 0x04, and you aren't even getting close to compiling anything.

If these are your symptoms, consider the following;

a.  Is the route reasonable?  You might be tackling on a problem state that is currently being researched by brains bigger than yours; and even those researchers are fumbling feverishly. (Multi-threaded / parallel processing training routes, Be Advised.)  Don't feel bad, RE-ADJUST (more on proper readjustment in a few).

b.  Are my sources/helper material/tutorials legit?  This happens many times; as an example, the billions of iPhone SDK tutorials out there may be outdated jumping between iOS 3.0 > 3.2/4.0+.  Sometimes, it's not your fault, the build itself sucks.

c.  Am I getting pissed off?  If you are; CLEAR SIGN YOU SHOULD REST.  Sleep it off, or go play Star Craft 2.  There's a stark difference between healthy aggression, and slamming your keyboard while facepalming yourself to tears.  Keeping your emotions in check must be part of the cycle.

Re-adjusting your route is not poor form; after all, this is your training.  If you have to settle half way, than you that's another half of skills that you wouldn't get otherwise.  Make it so.

The inverse is also possible; you probably have something way too easy for your skill-set, or you have found your route through epiphany.  Another scenario that you may catch; you may achieve a state of grok mid-way.  

Don't panic, it's a good thing when your code 'accidentally' solves a problem.

Step 5 : Never Forget Your Friends

Nothing is more humiliating than re-discovering the wheel.  Not 're-inventing', we do this all the time.  Having to re-discover a concept thats already been solved by your professors or peers is not proper training.

So, reach out;  don't be afraid to ask for tips, place a forum post and hunt for more articles.

Step 6 : FUN IS MANDATORY.

The pervasive myth about training is the prerequisite of absolute suffering.  FAR FROM IT, especially for young hackers.  You must stay interested and engaged.  

In the words of Seven-Of-Nine, "Fun, will now commence.";

and you should hold the same attitude.

Hopefully this helps.  The Summer of Code is winding down; everyone's gearing up their IGF submissions >:D  

I present myself as a humble case reference for the training regimen; after 2 years of using this marathon style coding exercise, I have been able to tackle on Cell-OS, topics in multi-threaded programming, Craig Reynolds paper on flocks, iOS/SDK programming (1 week from scratch to full build in OpenGL), and a healthy review of linear algebra.  Having a set of routes (as opposed to full expertise) in each of the target domains has proved invaluable in past and present projects.  

To make an analogy with with skateboarding parlance; I may be able to do only one trick or one ollie, but that trick allows me to learn and springboard to other tricks, and other places.

At the moment, I am using this method to implement a cache-friendly scene graph loop.

Hopefully, you the reader, will find a route you want to tread, and may that route take you to places you have yet to imagine.

Happy Hacking.