Nosce te Ipsum

Truly nothing requires more intimate knowledge of a system, than refactoring its components.  Familiarity with its internal organization demands familiarity of its creator; their habits and practices, their syntactic and semantic preference, and their logical flow all must be grokked absolutely in order to understand the choices they made and why they made them.

The past two months saw significant changes in my life and it is apparent from reading my old code that I have changed as well.  It’s as if I were a different person then, an individual with an obsessive thirst for pre-optimization and style propriety, so much so that the earliest classes I wrote (the rendering component and main loop) have had their line count reduced by half as a result of the refactoring effort.  An idealist at heart, the past me sacrificed productivity in search of the programmer’s haven; a paradise with code so elegant to eliminate the need for comments, so simple that even the most inexperienced of Python scripters could read and follow the flow of C++’s cacophonous syntax (yes, that is a jab at scripters, and at Python).  It might be construed that this materialized as a consequence of game development (or, more broadly, software engineering) naiveté. I think this is but one of many factors, factors not excluding the absence of the time limitations mentioned in my previous post.

Eventually the pragmatist in me realized that if this attention to detail was afforded to every line of code, we would be here for a very long time.  After all, the maths behind a 2D platformer are not so complex that they require rigorous optimization to perform well on a modern platform, especially this early in development.  It became my opinion that this form of microscopic scrutiny finds a more meaningful purpose on the outer surfaces of the product: gameplay, story, characters, art, and sound make ideal candidates.  It followed logically that functionality should be implemented using minimal effort and focus shifted as quickly as possible away from engineering and towards design.

At least, that was the principle I adhered to following my return from GDC; seeing the excitement and reward generated by a well-designed game at the Indie Games Summit served as the catalyst for a shift in development paradigms (not to place the blame solely on the IGS because it was a wonderful event, but it is MUCH easier and more productive to discuss design than it is to discuss programming with such a broad audience).  What I ended up with was a mess of spaghetti code, OOP shortcuts (e.g. returning raw pointers to component classes), and functionality delegated inappropriately among other generally poor programming habits that do not adhere to the entity/component methodology, all in the sake of development speed.  The “add functionality on top” attitude I expressed earlier this month caught up with me quicker than I had anticipated, necessitating a refactoring of the entire project.

That is not to say that either extreme is the appropriate answer.  Of course, were I one half of a team focused purely on one half of the development, this post would be one half as long and 100% less interesting.  But as the sole developer on this project, it falls to me to decide what the most important aspect is, and where to delegate my resources.  Am I trying to create a technical masterpiece that a programmer would be proud of?  Or do I want to make an artistic experience that a designer would be pleased with?  At this point it is too early to tell.

The Boiling Frog

I suffer from serious and crippling motivation issues.  More often than not, I find myself wishing that I had not substituted my daily allotment of programming for various other distractions.  Part of it can be attributed to the shrinking window of free time my schedule leaves me every day; my part-time employment has evolved into a menacing full-time beast, and my pile of shame has never looked taller.  But the true culprit becomes clearer the deeper I delve into this endeavor — there is a lot to do.  The high of motivation from GDC has worn off, as the reality of the proposition once again takes over.  The sheer amount of work required to produce even a working prototype is immense.

I am very much a short-term, in the moment thinker: were I to be placed in front of a large marble slab and instructed to chip away at it until I had achieved art, the predicament would be indistinguishable from the one I face now.  Small measures of progress have incredible difficulty taking hold in my mind, and what does is not processed until a conscious effort is made to notice.  I expect this is the development equivalent to watching water boil: regardless of how much heat is applied, thermodynamics dictates the same finish line for all waters (i.e. “it’s done when it’s done”).  I feel more inclined to occupy myself with other things until that point, rather than stay and wait.  In fact a more apt description would be watching water boil while you build and maintain the fire.

That aside, I am not without my share of optimism — slow and steady progress is still progress, and it is being made.  I have adopted a strategy that should assist in managing the workload.   By breaking down the systems of the game into its rawest components, and then iterating on the code to add a single crumb of functionality at a time, I can narrow the scope to the immediate issues, and work up.  Not the most elegant solution (it’s quite top-heavy, see: ripple effect), I concede, but appropriate given my level of experience.  As a bonus, it allows me to familiarize myself with the core components of the system, what they do, how they do it, and what I can and cannot change.  The first of many obstacles has been overcome.

And the feeling is profound.

 

Oro en Paz, Fierro en Guerra

Tomorrow heralds the commencement of game development’s Mecca – GDC.  The perennial gathering of the industry elite has since 1998 been a potluck of knowledge, techniques, and opinions for others to share and contribute, as well as establish the community zeitgeist for the following 12 months.  I too am making the pilgrimage this year; my attendance serves as a sobering reminder that I am treading a path walked by giants — giants who once stood where I stand, and knew as little as I do — and that for a week, we will share the same premises.

I will be present under the Summits and Tutorials Pass; reservations have been made for Monday and Tuesday for workshops and seminars on various concepts and topics, and ripe with opportunity to network and establish insider connections.  Rest assured that I will do my best to make the most of it; in fact, if this is the first post you read then chances are we met during the conference.  The remainder of the week is less certain, and while I do not possess the clearance to attend the main conference keynotes, I remain copacetic.  I expect that I shall leave San Francisco with renewed vitality for game development and several newly acquired tools with which to expedite or embellish my personal project(s).

On another note: I shall be avoiding the internet like the plague beginning Monday night and continuing into next week, in the hopes of avoiding spoilers for a particular game whose release could not be more ill-timed.  Expect updates of the conference, after the conference.

Tabula Rasa

Often acknowledged as a truth universal in scope is the 90-90 rule.  A much more serious affliction in my case tends to manifest in what the blogosphere refers to as “Blank Page Syndrome,” a phenomenon completely self-explanatory in definition and arbitrary in circumstance.  The mental dexterity for transcribing thought to text drains entirely from me as I confront the empty Emacs buffer, an infinite expanse of choice and possibility limited only by my own proficiency.  Pre-devised design documents assist in mitigating the effects, but ultimately serve to escalate the issue to the planning phase, a space infinitely more empty but not completely unmanageable like an empty buffer.  Brainstorming serves as the go-to solution for designers, a procedure I wholly endorse.  Having performed these cerebral acrobatics for planning my projects, the benefits of dumping all thought into a page regardless of sensibility (see: example) make themselves clear to me.

The issue I face is not one of design, but implementation.  I am well aware of the end result I intend to meet; the means by which I arrive there have not made themselves clear to me.  I find myself more often than not wondering where or how I should begin.  I attribute this most confidently to the nature of OOP; when implementing class hierarchies I tend to begin with those containing the least amount of dependency, and build out.  My latest entanglement with OOP is the result of poor design leading to circular dependency, rendering me unable to properly structure the class’ code.

Of course, the obvious answer is to properly construct class relations before coding.  Were this any experienced developer, with multiple large projects under their belt and familiar with the exact requirements of their design, that would be included as a step in the process without a second thought.  In my case, I have but the slightest notion of the requisites necessary for a program to display game-like qualities.  I tend in this scenario to dive into the coding directly, hoping to emerge with a clearer idea of what I need to make happen, and somehow always return to the original problem: a blank buffer and nary an inkling of where to begin. Stifling is the word I would use to describe it.

A technique acquired from my post-secondary learnings for designing object hierarchies comes to mind: compose in written English (or language of your choice) a description of the functionality expected.  The last time I checked, the cognitive diet on which humans are cultivated is one of natural language; the conditioning to think in an object-oriented manner is absent from average beings and, as a result, fledgling software designers grasp concepts in their native language more easily than in the pattern of encapsulation.  A clear description of the expectations of one’s code does wonders in the subsequent step of translating into compartmentalized functionality.

So this is the next step for me.  I anticipate that once the operation I expect from the subsystems of a game becomes apparent to me, I will finally be ready to begin.

Of Mice and Men

In a sense, planning a project not only provides a foundation by which involved parties can remain cohesive, but also assists in making sense of abstract concepts, giving them context and structure.  An idea is only valuable once its essence can be explained to others.  In this way I see planning as more than designing a strategy; it is a procedure for validating my own thoughts.  The same could be said of blogging: a public outlet for which to share my progress and opinions doubles as a template for my reasoning, a way of reaffirming my own beliefs.  I treat planning in this manner.

For the remainder of 2012, I will focus on learning about the game creation process, as all-inclusively as possible.  I intend on applying the knowledge I gain from various sources (which I will cover later) into creating my game; by the end of 2012 I aim to have a released, working title either for sale or available open source to the community.  This is a decision to make further in the production timeline, but will rely heavily on whether the product is of sufficient quality to justify exchanging its entertainment value for money.  In the meantime, I plan on documenting some of the design decisions/technical challenges in this blog, my approach to solving them and the associated thought process.  I will also offer occasional commentary on both the industry as a unit, or on introspective musings about life (for what is a personal blog without personal moments).  This blog aims to catalog my transition from proverbial games industry n00b to indie dev supercelebrity.

As for the technical details, my language of choice is C++.  I will be working with SDL for handling events and sprite/font loading, and OpenGL for rendering and post-processing effects.  Portability tops the list of reasons behind the choice of language and libraries; most platforms support either running native code directly or executing native routines from their virtual machine (see: Android NDK), and OpenGL is supported by almost all major hardware (see: Xbox 360).  Alternatively: in terms of absorbing as much knowledge as possible, a ground-up production provides an in-depth learning experience unavailable were I to use a pre-built engine1.  In order to compensate for the statically compiled nature of C++, I will incorporate JIT compilation via Lua to handle all my game logic and AI.  This will allow me to save time on prototyping during production, and in the long run provide tools for expanding or modifying the game while retaining encapsulation on the engine’s core functionality.

The game I intend to create is a 2D open-world action platformer, similar to the Metroidvania family.  It is common knowledge that bad luck befalls those who discuss works in progress with others; therefore on specific details I will say no more.  Thoughts of relative simplicity in implementation and depth in design approach come to mind when considering this genre, one of the most under-appreciated in modern game space.  With respect to design decisions, I will attempt to keep them as generic as possible and ambiguous in the nature of their implementation.

The conclusion of this post brings me to a realization: it is entirely too early to discuss roadmaps or milestones for this project.  Being the first undertaking of mine with a tangible purpose (i.e. not just for funs), I have little experience in the way of estimating dates or time frames, especially at this scale.  When the framework is a bit more concrete, I will discuss deadlines and other completion motives.

  1. for the record, I have used Unity, GameMaker, RPGXP and others in the past and loved them; if you have interest in making games but are not fond of being bogged down in the implementation details, I strongly recommend any of these products [↩]

Origins

It has crossed my mind (a dangerous proposition to begin with; my mind for all intents and purposes is a one-way Autobahn of untamed consciousness) that there are two strains of reader this thought repository will attract: those who are versed in the attributes of my personality (some more so than others), and others who found themselves lured in with promises of intelligent commentary on the state of things in the realm of digital entertainment.  An irrational fear of uncommon denominators hinders my forward progression in this venture: the first obstacle among many I’m sure.  In an effort to not alienate any aggregation in particular — although I make no reservations expressing my ire for the Dubstep Brofist Consortium —  I present the following effort to standardize your perspective and assumptions about my level of exposure to game development and programming in general.

HTML, CSS and JavaScript raised me in my early years of coding.  As exercises in cognitive development, numerous “web” pages were carelessly cut and pasted together from source code blocks scavenged from reference elements I was particularly privy to, not unlike LEGO bricks hastily assembled from various prefab packages to form a spaceship, or house, or whatever whim demands satisfaction.  Web development in my case is a long saga and not entirely relevant; perhaps in later installments the story arc will command a re-examination. I began delving into PHP, the oft-mentioned “fundamentals of logic and programming” bestowing upon me their teachings.  I would continue to imbue my metaphorical blade of programming skill with challenges of ever-increasing complexity, achievements including, but not limited to, implementing a personal blog, a bulletin board, and an animation submission portal.

High school provided me exposure to desktop programming, making first contact with C++ in a limited-risk integral-type-only text-based environment and later being weaned on to Java and OOP.  Advanced concepts such as parallel programming, model-view-controller architecture, and GUI implementation were introduced to me with Java as a conduit, however the “first love” passion C++ and I shared was a feeling I could not shake.  The siren song of C++ told of its efficiency and power, both in syntax and design principle, drawing me away from the obnoxious and unnecessary verbosity of Java (an irony that has not escaped my notice, but on that I will say: writing is about the journey, not the destination; the opposite is true of programming, at least externally).  I returned to my first language with a renewed vigor and respect for the concepts that Java offers, but that C++ implements at a fraction of the time and resource cost.  As of January of this year, I am on hiatus from my university studies, seeking knowledge and experience in the business of video games and their conception.

This post has become quite drawn out; it requires a division between summaries of the past and propositions for the future. In the coming days I will explore goals and possibilities, as well as contemplate upon a potential road map for the purposes of preventing complacency and monitoring progress.

-faide

Call me Ishmael

My name is Michael (pseudonymously known as faide), and I make games.  If there is a more lackadaisical introduction (of which I’m sure there exists more than one), I myself have become too lackadaisical to embark on a quest to discover it, an enterprise which would surely be produced as a motion picture trilogy in later years.  Of course a venture to that extent, on a budget reflective of my economic circumstance and wholly indicative of my Time and Effort ™ investment,  would consist entirely of a single Google search, and conclude on page two of the results.  That is to say, I at present do not regard this introduction as the quintessential template for lazy expositions, however any weary travelers who happen upon this post in their crusade for the Holy Grail of Brevity are welcome to rest and recoup here.

I said that I make games but that is misleading testimony, and were I being deposed I would be charged with perjury.  As I wish to avoid jail, I shall rephrase: given my current trajectory, I estimate that at some future point, I will be in the trade of game manufacturing.  Currently this is only an extrapolation of the status quo, as I have yet to produce an entity which leading experts may classify as game-like.  In preparation for diving into the deep end of the gamedev ocean, many hours I have spent wading in the kiddie pool, digesting tutorial material and absorbing choice modica of wisdom passed down from those who were (in the existential sense of the word) before.  Only time (and those who would wield it) may predict the success of this undertaking.

In lieu of such a time hero, I invite you to accompany me on this ride, for what a ride it shall be.  As I throw myself into the industry of game making, this site shall serve as a breadcrumb trail, chronicling my progression and, with luck, serving as a beacon for those to come (in the existential sense). As is foretold, many tribulations and trials await, and only beings of a particular fortitude may pass unscathed.  The road doth lay ahead; while not unfrequented, it remains shrouded amongst unforeseen/undocumented intricacies, constraints, and hurdles but I am naught if not imbibed with an intrepid excitement – a yearning for learning, so to speak.  Should you choose to explore with me, and barring a catastrophic lack of interest or end of the world, we shall together probe behind the industry curtain, and unravel the secrets of the universe (see: Episode 3).

-faide

 Scroll to top