Skip to main content

Regarding Imitation Versus Motivation

Immediately upon embarking into my bold claims to not be so very bold via imitation, I encountered more trouble in that it's harder to make a game the way I wouldn't normally make it.

It's the trouble with blind opposition coming to resemble the converse of whatever it is that they are opposing; an opposing idea is an idea even further distanced from reality than the original idea by being one more idea removed from reality.  Reality -> Idea based on reality -> Idea based on opposing the idea based on reality.


Consequently, the more you think about a thing, the crazier you get via having distanced yourself from reality all the more.  Sometimes, this results in tragedy.  Other times, this results in the great inventions of our age.  Are you a scientist or a madman?  Whatever artifact your toils produce will convince people which you are.  Or, like me, you can produce nothing at all, and be a typical, everyday, boring failure.

In terms of the game I know I want to make, I know exactly what I want to make.  That it's a hybrid based on existing models of games makes the job a bit easier, but neither should I hold myself to doing things exactly like those models.  No, I need to make the software I want to make, or else I'll come off not wanting to make it at all.  Thus, the prototypes are ones I imitate insofar as I admire what they do.  Being an independent (and unpaid) creator, my motivation to imitate them is not strictly monetary, and so simply cloning for profit (as so many commercial games do) is not at all compatible with my mindset.  (A pity: a clone-prone mindset makes game development a Hell of a lot easier.)

If you're looking for me to start talking about specifics, I'm not going to tell you.  As those on BYOND have warned me, announcing what you do before you do it is a sure way to rob yourself of the motivation.  Funny enough, that seems to have held true. I think we game programmers just derive some measure of energy from harboring a guilty pleasure that what we're creating will surprise people.  Nope, I'm going to get the game playable and reasonably feature complete first.  Then I can consider spilling the beans because the hard part is done and I'm simply free to dabble idly away at refining it.

This is some good advice, too:
These tips apply to any hobby software project, and not just games.
  • Set tiny milestones. Having a goal like "item system works in my RPG game" is all well and good, but that implies a whole lot of under-specified functionality that you probably didn't even know you needed. What about "graphics environment set up"? Or, "A sprite is displayed on the screen."
  • Do a little bit each day. Marathon sessions are great and all, but you're trying to squeeze a long-term commitment into an already crowded life. If you do a little bit each day you are making measurable progress and establishing a structure within which you can achieve your milestones.
  • Scale yourself back. Whatever your grand vision is, try and figure out what the smallest achievable portion is and do that. Making an RPG? Start with one quest and no NPCs. Making a platformer? Start with one level and no enemies.
  • Prototype early. Before you sink a bunch of your hard-earned hobby hours into a game, figure out if it'd be fun first. There's nothing so dispiriting as working your ass off on something for dozens of hours only to find that the basic concept sucks.
  • Develop something iterable. My favorite hobby software projects are the ones where the basic concept allows for later tinkering. Is your game like that? Can you ship something and then revisit it later and add cool stuff?
  • Don't build an engine or a framework. You don't want an engine, you want a game. Don't worry about the framework-y, reusable bits until after your game is shipping. Once you start on the second game, then you can go back to your first and see if there's anything you could bring over. That's not to say that you shouldn't use sound software development praxis, but don't start by writing a Sprite class until you know what you need your sprites to do -- you'd be surprised how little it'll turn out to be. Start with a Hero class, then a Monster class, and then -- oh look! -- there's some common stuff!
  • Shipping is a feature. You're never going to finish your game, you're only going to abandon it. ( = What is the minimum amount you can do before you're not completely embarrassed to show your game to someone else? Chances are, you can do less than that and still have a game to be proud of.
I can verify nearly every point from personal experience:
  • Set tiny milestones.  Note the word "tiny," because setting small milestones isn't enough.  You need to identify a comfort zone in which the milestone is so small that you feel completely comfortable doing it.  I've found that, the longer you've been away from the activity, the more your habits are swayed against doing it, and the smaller the milestone you'll need to find.  In this way, the goal with a tiny milestone is to start, because the first step after a long lull is always the hardest.
  • Do a little bit each day, like set tiny milestones, is a way to reassure yourself so you'll be comfortable enough to commit to an action, but I want to add a caveat: if you're "in the zone," and feel comfortable continuing, don't force yourself to stop.  At worst, you may lose your bearings and dig yourself into a hole, but I'd say the added productivity of being "in the zone" is worth the risk, and it's fairly likely you may reuse that code (or what you learned while writing that code) again some day.
  • Scale yourself back.  Actually, I'm bad at doing this, as my grandiose plans only get more grandiose the more I think of them.  Considering I've never finished a game yet, this is a something I could afford to get better at doing.  As long as you're working to develop something iterable, you'll have plenty of room to add grandiose later.
  • Prototype early.  My "playable and feature complete" aspect is where "prototype early" comes in.  The primary reason I'm doing this is to develop something iterable, but this makes a good point that it could very well be your base concept is not nearly as good in reality as it was in your head.  It happens more than I like to admit that I think I'm making something new and interesting only to discover I reinvented a wheel I'm particularly bored with already.
  • Don't build an engine or a framework.  This, fortunately, I've already figured out.  Engines, frameworks, and engine frameworks are for code monkeys, not content creators.  This is why I'm using BYOND: it is the only already-built engine framework I know that is closest to what I want to make.
  • Shipping is a feature.  It's certainly a feature I've neglected to add so far - but I see his point, it basically translates over to the scale yourself back point above.
So it's basically eight points that translate into both sides of four points.  Set tiny milestones <-> Do a little bit each day.  Scale yourself back <-> Shipping is a feature.  Prototype early <-> develop something iterable.  Don't build an engine <-> Don't build a framework.  But there's at least two sides to everything and, if the reader of what you're writing can't understand one side of it, it's good to mention the other side in case they can understand that.

My mother has some good advice too, and she's not the only one I've heard it from: Just do it.  No creative work is done by thinking about it, and I can spend time thinking about something practically forever.  Actually getting myself to start may involve setting a tiny milestone, but even a tiny milestone never gets done if one never opts to do it.

Comments

Popular posts from this blog

Resonant Induction Really Grinds My Gears... In A Good Way

From about 2pm yesterday until 8pm today, I've been dabbling with my latest custom mod mix for Minecraft 1.6.4, which is this time very much Universal Electricity focused.
Aside from the usual GUI enhancers and Somnia, the primary contenders in this mix were:
Calclavia Core - Of course: this is the base of the Universal Electricity system.Resonant Induction - This seems to be largely focused on increasingly more advanced methods of refining ores divided across 4 ages of technological progression.  It also includes some really cool things such as assembly lines.  I'll primarily be talking about just a few blocks out of this mod today.Atomic Science - A mod dedicated to generating more of those lovely universal electricity volts via the power of splitting the atom.  Build your own nuclear reactor!  Deal with nuclear meltdowns!  You maniac!ICBM - A mod dedicated to generating more destruction using those lovely universal electricity volts (and more than a little gunpowder), it cer…

Empyrion Vrs Space Engineers: A Different Kind Of Space Race

In my quest for more compelling virtual worlds, I have been watching Empyrion: Galactic Survival a lot this bizarro weekend, mostly via the Angry Joe Show twitch stream.  What I have concluded from my observations is Empyrion is following in Space Engineers' shadow, but it is nevertheless threatening the elder game due to a greater feature set (the modding scene notwithstanding).

Empyrion is made in Unity, whereas Space Engineers is built on a custom engine.  While this does put Empyrion at a disadvantage when it comes to conceptual flexibility, its developers nevertheless have a substantial advantage when it comes to adding features due to a savings of time spent that would have gone into developing their own engine.  Examples include:
Planets.  Empyrion already has planets and space to explore between them, whereas in Space Engineers planets are in the works but still awhile away (so you just have asteroid fields to scavenge).Enemies.  Space Engineers' survival mode boasts onl…

Greasing The Grind: Adding Lasting Appeal To Virtual World Sandboxes

Game design, being about entertainment, is not as much science as art.  We're coming up with interesting things that the human mind likes to chew on that "taste" good to it.  Different people find different things, "Fun," and a game designer is tasked with coming up with fun, appealing things.  As pertains to virtual world sandboxes, I identified three of them.

Challenge Appeal.

Dwarf Fortress and Fortresscraft Evolved have the same end game appeal preservation mechanic: wealth equals threat.  The more money your Dwarf Fortress is worth, the bigger the baddies who will come for you, including a bunch of snobby useless nobles who do nothing but push dwarves around and eat.  The more energy you make in Fortresscraft Evolved, the more and bigger bugs come to shut down your base.  Rimworld does something a little different based off of which AI Storyteller you choose, but it generally adds time to your wealth accumulation when deciding what kind of threats to throw a…