Booniverse
25Jun/110

I Like to Watch People

I like to watch people, when I'm out and about. Sometimes I just sit and stare from the corner of my eye, pretending I'm thinking or reading or singing a song that's been stuck in my head.

I wonder who they are, and what brought them here. And I hope they're doing okay.

And then I wonder if anyone is watching me.

And I get paranoid and self-conscious and freak out a little bit, because that's creepy.

True story.

Filed under: Random No Comments
24Jun/111

Colour… A Primer

HAHAHA, sorry.

I spend a lot of time exploring colour, but I don't post a lot of what I explore because it's more visual-play than visual-art. I tend to gravitate towards palettes with tension: Schemes which employ contrast and conflict. I'm a personal believer that something doesn't have to be aesthetically attractive to be aesthetically successful. Ugliness is as valid in visual storytelling as sexiness.

(Yes, I often use the word 'sexy' when describing art, irrespective of the amount of hunky or boobalicious content. Yes, I said boobalicious.)

The difficult thing is not selecting a palette, but executing on it. To be able to execute well on a palette is something which often eludes me. Particularly palettes with tension (making my predisposition towards such palettes an oddly counterproductive trait). But nevertheless, this endless journey towards perfecting an understanding and practical mastery of colour is one of my more creatively rewarding ventures, and probably the most critical in my development as an artist.

I wanted to write a bit about what I know of colour theory. If you like... A primer (HAHAHAHA! Kills me every time!): Primaries, secondaries, tertiaries, analogic palettes, accented palettes, contrasting or complimentary, hue, saturation, value, additive and subtractive, the disappearance of the letter 'u' from American English...

But I'm not in the mood right now. I'll do that later.

Instead, here are some resources, pilfered from my immense list of bookmarked awesome, that are related to colour, themes, and palettes. If you're short on colour resources, or find that sometimes, like me, you suffer from sudden onset of chromatic illiteracy: Enjoy!

Kuler
Adobe's colourific themes resource.
http://kuler.adobe.com/

ColourLovers
An awesome resource for sharing and collecting palettes, patterns, and colour inspiration.
http://www.colourlovers.com/

ColourSchemeDesigner
A pretty cool palette creation tool. It's focused on colour for web design, but it's useful for any number of colour palette creation purposes. Supports a variety of different palette options.
http://colorschemedesigner.com/

Hopefully,  you can find something worth pilfering from these sites, if nothing more than an unexpected appreciation of the skill necessary to master the fine art of colour palette selection. As, I expect, Erin now knows with an office the colour of Optimus Prime.

Filed under: Art 1 Comment
22Jun/114

Unity: AIBrain Execution and Polling

I'm tired. I have sandpaper eyeballs, or so it feels. I think I need a good night's sleep. I think it's the cold weather: I'm not used to the need to defrost my face in the morning. But on the plus side, it gives me plenty of motivation to be inside, working on my game. As opposed to going outside and scoring those scores and winning that sports with those guys.

But assuming you're not here to read about my eyeballs (which I think are making scratchy noises when I blink) or the weather, I do have some game-related stuff to talk about.

I completed the draft of the AI framework for AIPawns. There's some hardcoded relationships between the AIBrain and the AIPawn that make me a little nervous, because I can see it breaking in the future, when the memory of what I've done has faded into the annals of ancient history. AKA: Yesterday.

But yesterday is the future.

Besides that sounding incredibly deep in my tired state, what matters is that the AIBrain now successfully polls a distance-check between the AIPawn and the Player (at a manually editable pollFrequency) and switches between two states - Active and Inactive - based on whether or not the AIPawn is within an also-editable activeRadius attribute.

If the AIPawn leaves the radius after being made active, it will be reset (and the AI script will cancel execution) unless the AlwaysActive property is true. I'm also intending to implement a DoNotDeactivateOnceActive property, which works slightly differently because AlwaysActive means it's active from the moment it spawns, while the DoNotDeactivateOnceActive property will allow an inactive AIPawn to become active, but not deactive again. What? I don't know. Something.

I ran into a few problems when I realised that the AIPawn might die, requiring a third state to be handled on the AIBrain. So I introduced, along with Active and Inactive, a third Dead state. To reset the AIBrain to Inactive (and therefore ready to poll again), the AIBrain is subscribed to the AIPawn's OnSpawn event. What? *sigh*

Internally it's all a little spaghetti. But it works. For now, that's good, but it will need a little housekeeping.

Like my eyeballs. Time for bed. Assuming I can close my eyelids without waking everyone up with the rasping.

Filed under: Code, Game Dev, Unity 4 Comments
22Jun/115

Unity: Even Simpler AI Scripting

Okay, so that turned out to be super easy, and very cool. Happy? Yes! Yes, I am! Here's a quick description of what is happening:

The AIPawn contains all of the methods and properties of the pawn. Things like its health, its speed, and its position, along with controls to move it, kill it, etc.

The AIBrain is dropped onto an object with an AIPawn present, and uses the AIPawn's coroutines to sequence events.

Here's the AIPawn in all of its wonderfully uncomplicated glory:

public class AIPawn : Pawn
{
// ----------------------------------------------------------------------------
// -- AI MOVEMENT PROPERTIES --
// ----------------------------------------------------------------------------
 
// The AIPawn's movement speed in units-per-second. This value is clamped at a
// minimum of zero (for non-moving enemies).
private float m_movementSpeed = 1.0f;
public float MovementSpeed
{
	get { return m_movementSpeed; }
	internal set { m_movementSpeed = Mathf.Max(0.0f, value); }
}
 
// The target position for the AIPawn when a MoveToTarget command has been initiated.
private Vector3 m_targetPosition;
public Vector3 TargetPosition
{
	get { return m_targetPosition; }
	private set { m_targetPosition = value; }
}
 
// Is the AIPawn currently moving?
private bool m_isMoving = false;
public bool IsMoving
{
	get { return m_isMoving; }
	private set { m_isMoving = value; }
}
 
// ----------------------------------------------------------------------------
// -- AI MOVEMENT METHODS --
// ----------------------------------------------------------------------------
 
// COROUTINE: Move the AIPawn to the specified location.
public IEnumerator MoveToTarget(Vector3 position)
{
	IsMoving = true;
	TargetPosition = position;
 
	while(IsMoving)
	{
		MoveToTarget_Update();
		yield return true;
	}
 
	yield return 0;
}
 
// Update the position of the AIPawn if the target position doesn't match the
// Enemy's current transform.position. This is called by the MoveToTarget
// coroutine, and is separate just for the sake of clarity.
private void MoveToTarget_Update()
{
	if (transform.position != m_targetPosition)
	{
		Vector3 move = m_targetPosition - transform.position;
		if (move.magnitude > MovementSpeed * Time.deltaTime)
		{
			move = move.normalized * MovementSpeed;
			transform.position += (move * Time.deltaTime);
		}
		else
		{
			transform.position = m_targetPosition;
			IsMoving = false;
		}
	}
}
}

And here's the brain that drives it:

public class AIBrain : MonoBehaviour
{
// The AIPawn to which the AIBrain is attached.
private AIPawn m_aiPawn;
 
// Initialize the AIBrain and start the coroutine.
public void Start ()
{
	m_aiPawn = GetComponent<AIPawn>();
	StartCoroutine(Execute());
}
 
// The main execute coroutine which loops endlessly (until the gameObject is disabled)
private IEnumerator Execute()
{
	while (true)
	{
		yield return StartCoroutine(m_aiPawn.MoveToTarget(new Vector3(-1f, 0f, 0f)));
		yield return StartCoroutine(m_aiPawn.MoveToTarget(new Vector3(1f, 0f, 0f)));
	}
}
}

Works perfectly, and is much easier to manage than the previous example. I believe the word is BOOYA. Or as the Captain would say it:

"Bam," said the lady.

Filed under: Code, Game Dev, Unity 5 Comments
21Jun/116

Unity: Simple AI Scripting

I took a bit of a break from housekeeping. Not the best idea to leave code half-refactored, but I had an idea I wanted to test out, regarding a simple AI scripting system. I think what I've come up with works pretty cool, but I'm not experienced enough with creating AI in general (let alone using Unity's coroutine features) so I'm not sure how good it is. If anyone has any desire to chime in at any time, feel free. This is very new ground, and I have to confess, I'm a little unsteady on my feet here.

Anyway, to describe (before pasting code), what I have is a simple list of AICommands. The AIPawn grabs the next command and continues to Execute() it until the command flags itself as completed, and then the AIPawn grabs the next AICommand in sequence. Rinse and repeat, until the list is exhausted, and then the command queue jumps back to the beginning of the list.

New AICommands are created by inheriting the AICommand abstract class, and overriding the StartExecute() and Execute() methods.

So to break it down, first up I have my AIPawn (just posting the code relating to running the AICommands):

// The AICommand list to control the Enemy.
private AICommand[] m_commandList = new AICommand[](25);
 
// The currently active AICommand.
private AICommand m_currentCommand;
 
// The index of the current command.
private int m_commandIndex = 0;
 
// Update the AIPawn's brain.
private void UpdateBrain()
{
	if (m_commandList.Count == 0)
		return;
 
	if (m_currentCommand == null)
	{
		m_currentCommand = m_commandList[m_commandIndex++];
		if (m_commandIndex > m_commandList.Count - 1)
			m_commandIndex = 0;
		m_currentCommand.StartExecute();
	}
 
	m_currentCommand.Execute();
 
	if (m_currentCommand.HasCompleted)
		m_currentCommand = null;
}

Next up, is the AICommand_MoveToTarget which tells the AIPawn to move to the specified location, and checks every frame to see if the AIPawn has arrived. When an AICommand is 'attached' to an AIPawn, the TargetPawn property is set:

public class AICommand_MoveToTarget : AICommand
{
	#region Constructor
 
	// Create a new MoveToTarget command.
	public AICommand_MoveToTarget(Vector3 position)
	{
		m_targetPosition = position;
	}
 
	#endregion
 
	#region Properties
 
	// The target position.
	private Vector3 m_targetPosition;
 
	#endregion
 
	#region Methods
 
	// Called before the AICommand is first executed.
	public override void StartExecute()
	{
		TargetPawn.MoveToTarget(m_targetPosition);
		HasCompleted = false;
	}
 
	// Execute the AICommand.
	public override void Execute()
	{
		if (!TargetPawn.IsMoving)
			HasCompleted = true;
	}
 
	#endregion
}

And finally, here's the code I used to create a simple AIPawn that moves back and forth between two points continuously:

public class AIPawnTest : AIPawn
{
	public void Start()
	{
		AddCommand(new AICommand_MoveToTarget(new Vector3(1.0f, 0.0f, 0.0f)));
		AddCommand(new AICommand_MoveToTarget(new Vector3(-1.0f, 0.0f, 0.0f)));
	}
}

It's not a particularly impressive example of what this simple system is capable of, and for anyone who has done any programming before, it's probably not a particularly impressive system. But nonetheless, I feel like it simplifies the task of composing simple, repetetive behaviour.

I do however wonder if there are better options for AI. A Finite State Machine, for example (my experience with which adds up to a grand total of 4 lines of code). Perhaps there's also a really cool way of utilising Unity's Coroutines to create a similar but more powerful system.

I figure my system might be expandable to support multiple AICommands running parallel. But that also frightens me due to the potential for creating extremely broken sequences. As it is now, it's simple enough for me to comprehend, and yet fairly powerful because I can create individual 'behaviours' and sequence them with ease. Which is almost all I need for my platformer enemies (most of which will just follow a mindless pattern). I'm not sure yet how, using this system, I could handle more advanced AI that responds to the player's position or line of sight and changes its AICommand situationally (i.e. non-sequenced AI) but for now... it's kind of exactly what I need.

I might also be able to adapt this system to work with things other than AIPawns, to create simple sequenced GUI events and such.

As I said, if anyone out there in internet land feels like chiming in, I'd be greatly appreciative.

Filed under: Code, Game Dev, Unity 6 Comments
21Jun/114

Unity: Pizza and OCD

Today's creativity has been, and will continue to be, housekeeping. In fact it might take me a couple of days of tidying up to get ready for the next creative sprint. My code and project structure up until now has been very slap dash. I've been focused on getting stuff done, rather than getting stuff done in a nice, tidy and concise way. I figured it was time to start refactoring a bit.

It happens.

I'm extracting a lot of player-related properties and methods into an independant abstract Pawn class, so that I can build other actors containing the same members without repetitious code.

For anyone who reads my blog and doesn't understand, it's kind of like this:

You have Hawaiian pizza. You have supreme pizza. They both share some things in common, such as the dough for the base, the sauce, and the mozzarella cheese. So without using inheritance, some information (Dough, Sauce, Mozzarella) is repeated unecessarily between the two 'classes' (HawaiianPizza and SupremePizza):

HawaiianPizza
Contains: Dough, Sauce, Mozzarella, Ham, Pineapple
 
SupremePizza
Contains: Dough, Sauce, Mozzarella, Ham, Pineapple, Olives, Mushrooms, Capsicum, Onion, Anchovies

Refactoring to take advantage of inheritance, and minimise repetitious code, you would end up with a base Pizza class, and use inheritance in the example to make HawaiianPizza a type of Pizza with added ingredients, and SupremePizza a type of HawaiianPizza with added ingredients. Inheriting means 'take all of the stuff from what I'm inheriting, and add to it'.

Pizza
Contains: Dough, Sauce, Mozzarella
 
HawaiianPizza inherits Pizza
Contains: Ham, Pineapple
 
SupremePizza inherits HawaiianPizza
Contains: Olives, Mushrooms, Capsicum, Onions, Anchovies

So maybe you understand how inheritance works... But why bother? Well, if we had a hundred different types of pizza, and someone said "Hey, let's use cheddar instead of mozzarella", the first example (without using inheritance) would require us to go through every one of our one hundred pizzas and change the ingredients to use cheddar rather than mozzarella.

The same example but this time using inheritance would mean we could just change the ingredients of the base Pizza class to include cheddar instead of mozzarella, and every type of pizza which inherited from the base Pizza would automatically use cheddar.

Does that make sense? Or did my attempt to explain it just make it more complicated?

Also, does anyone else have a sudden and desperate hunger for pizza? OM NOM NOM.

Either way, that's essentially what I'm doing now with the Pawn class: taking stuff that relates to ALL 'living' actors in my game, and putting it into a Pawn class, which other classes will inherit from. So my Player will inherit from Pawn, as will my Enemy. And then individual enemy types will inherit from Enemy, which will contain only the stuff common to all enemies.

I actually enjoy this process. It's kind of like that logic game where you have a farmer, a fox and some chickens trying to cross the river but only two things can fit in the boat and... I have no idea what I'm talking about. It's a game. I can't remember it all that well. And the more I think about it, the more I realise it's nothing like what I'm doing.

Suffice to say, refactoring can be a challenge, but it also tidies things up and makes it easier to make new things. Which is a good thing. Also, I'm not far off adding enemies to my game now, so it's exciting because it's a necessary aspect of adding new gameplay. But really, I'm just kind of OCD about this kind of stuff.

In other news: I enjoy UV unwrapping, I take great pleasure from manually editing my contacts to ensure everyone's names and phone numbers are in the same format, I regularly reorder the folders on my hard drive into more efficient hierarchies (I'm approaching a kind of binary Zen), and at least once a week I spend thirty minutes or so trying a new tab-depth across all of my existing code. I'm just oodles of fun.

Filed under: Code, Game Dev, Random, Unity 4 Comments
19Jun/110

Colour and Misleading Light

So, I was kind of creative today. I helped Erin paint the two new office rooms he has spent the last month building in his shed. He's done an exceptional job, and since I plan to make good use of the new space, I was more than happy to offer a lending hand.

I wasn't expecting to pick the colours.

At first I flat out refused, but then we had a discussion about me "being the creative one" and I ranted a bit about colour theory as if to convince myself that I knew what I was on about.

Though Erin is very agreeable in general, I still felt we'd managed to successfully simplify our choices down to a couple of options that I was pretty sure he was genuinely happy with. We'd agreed on a feature wall for each of the rooms, with a neutral fill. We also agreed that the feature walls should be complimentary, or if we were feeling particularly bold, strongly contrasting in a GASP-DID-THEY-REALLY-DO-THAT? kind of way.

I should say, if you've ever looked at paint swatches, you'd know how hard it is to pick a colour. I expect it'd be hard to pick a hundred. They're all so seductive. And they've got the kind of names you want to say out loud. Celestial blue. Arctic white. Visual names; power names which conjure strong imagery and personality. It's not just an office, it's a twilight norwegian glacia with computers in it. Don't tell me that doesn't sound awesome.

Well, we got down to two choices: a complimentary scheme of a deep purple coupled with a lime/olive love child (whoever said that purple and green should never be seen?) or a red and blue eyeball explosion that was best described as Optimus Prime.

Need it be said that we went with Optimus Prime?

Almost as an afterthought, we picked the aforementioned Arctic White as our neutral. The word White being, unfortunately, a misnomer.

The thing with colour is, our perception of hue changes depending upon the ambience of the environment we are within. This happens as a result of reflected light (known in CGI terms as global illumination, or radiosity) and our brain's automated ability to compensate for colour cast, similar to the White Balance option on digital cameras. The colours we see are very rarely the colour we see, so to speak. While a white piece of paper might seem white to our eyes, it could in fact be a deep orange due to the artificial lighting of the room - a phenomenon that you've likely seen when taking indoor photos with a camera balanced for daylight.

And it turns out that Arctic White in the slightly warm lighting of Bunnings appeared to be considerably more neutral than it actually is.

As soon as we had it up, I was aghast at how blue it looks. Especially against the trim, which it turns out is a warm white. I'm a little mortified that I made such an amateur mistake (without being patronising, because this is the shit that I get paid for). I should have checked the swatch under different light.

Luckily for my ego and propensity for self punishment, Erin as I said previously, is usually spectacularly agreeable, and he assures me he likes the colour. As I take my time to look at it, I like it more myself, especially when more natural light is spilling into the room. I'll hold final judgement until we complete room number 2. And if I find I can't sleep at night... I'll just have to break in and repaint it all when no one is looking.

Filed under: Random No Comments
18Jun/110

Creative Neuroses and Melodrama

Started working on the 3D version of my main character tonight. That is, the beefcake pixel pirate with the green hair and short-shorts, flexing up a storm. Which would be great news, if I hadn't had such a frustratingly unproductive day. I couldn't focus. I kept jumping from project to project (game to reel, website to writing, 3D to 2D) and I just couldn't settle and get into a groove. I was restless, but stubbornly determined. Maybe I should have just called it for the day and played some games instead: I've been super productive this month, so I wouldn't feel so bad about a day off.

Except that the last couple have days have been disturbed by a faintly strummed chord of panic playing in the background of my regular soundtrack: A constant note of mild anxiety, that I'm not moving fast enough. Not doing enough.

This is probably a symptom of my very special ability to get stuck on Big Picture and become overwhelmed; to feel that the goals I've set for myself are insurmountable, and that if I were to summon the courage to look directly I'd see a megalithic pile of tasks before me; some Gorgon of my own construct, a sight so terrible that gazing upon it would surely turn me to stone. So I keep my eyes to the ground, trying to ignore its encroaching shadow.

It's left me feeling, quite obviously, a little melodramatic.

There's a lot I want to do: My lighting reel which I've intended to update for months now with barely a start; finally taking the time to note down the outline for this game's narrative; beat those stories I've had gestating in my head for months now, before they become lost in the mists of unrequited ideas, too distant to recall beyond the recollection that it was something I certainly didn't want to forget; lots and lots of stuff.

So every now and then, instead of just focusing on one thing and moving forward, my peripheral vision fills with an army of expectations, and I fall, paradoxically, into an incredibly rushed state of complete motionless.

Instead of tackling this neurosis with brute force, I'm going to turn off my laptop and go play some games. I have a huge backlog of XBox 360 titles I've been collecting in anticipation of a day off. I think it's time I gave myself one.

Filed under: Random No Comments
15Jun/110

80′s Cartoons and a Video Game Daydream

I have this recurring waking fantasy that I've completed my indie opus: A video game series in the format of an 80's epic adventure cartoon. Think, Mysterious Cities of Gold, Spartakus and the Sun Beneath the Sea or Ulysses 31.

Think gloriously audacious opening sequence, full of expansive vistas and children doing dangerously exciting things. Think catchy title tune by anonymous vocalist that's so bad it's embarrassing, yet so good you secretly 5-star it on your iPod. Think of yourself singing it out loud only to realise you're in a crowded supermarket and then try to do that thing where you act like you don't care but lapse into an awkward tuneless hum. Think rushing home on Friday afternoon to catch the latest episode, only you're 35 now, not 10.

Nostalgia so bad it makes my eyes water.

Episodic games certainly aren't a new concept. Alan Wake used episodic chapters to create a genre film in a game, excusing its pulp horror storyline by cleverly wrapping it up in format that demanded it. Brilliant!

Team 17 took advantage of Xbox Live Arcade's short-order expectations by releasing the remakesequelthing Alien Breed series as a triplet of rapid fire, easily digestable, arcade blast-at-everything-and-scream-a-lot-emups, and I'd argue that they're more entertaining and more accessible for it.

Valve take advantage of an episodic release schedule to bring us the remaining chapters of the Half-Life series far faster and cheaper than full-release sequels. *Cough*

But I'm thinking bigger. Yes, that's right: Bigger than Valve. I'm thinking, completely disregarding the whole one-man-army thing... I'm thinking a series where you sit through the opening credits just because they're AWESOME. I'm thinking that you're talking about the latest episode with your gamer buddies, and making predictions about the next. I'm thinking that you're rushing home on Friday afternoon for the latest episode even though you're 35 now, not 10.

And I'm thinking that somehow, it's entirely economically viable and appealing to a publisher who will agree to sell it for a gold coin per episode.

That is my daydream. I'm not even remotely ashamed of such naive romanticism. It'll happen one day - I even have the story all figured, and the start of an opening sequence playing in my head, title track and all. If I ever find the kind of financial success that lets professionally immature people like me treat business ventures as giant funparks, I'll do it. And it'll be like being 10 again, watching Cities of Gold when Esteban raises the Golden Condor and thinking for a time that magic - like those crazy people who wear crystals and smell like marijuana only vaguely masked by incense say - happens.

Until then, I get an aweful lot of fun just pretending.

Go! Follow Spartakus... To the sun... Beneath the sea! We're so near... To the Universe... Which has long... Disappeared! Rainbow dawn... Of Arcadia... Shining sun... Beneath the sea!

Filed under: Game Dev, Random No Comments
15Jun/1131

Rant: Games are Too Easy to Create

LANGUAGE WARNING: MA15+

If you're involved in any way with the game industry, I'd bet money you've heard someone say "Games are too easy to make these days". If it wasn't uttered by one of your coder colleagues, perhaps it was during kitchen-meet gossip. You might have stumbled upon a heated thread on a game development website full of programmers wailing and gnashing their teeth in righteous indignation. Or maybe you read it in the subtext when Steve Jobs slammed the banhammer down on Adobe Flash, apparently out of fear of a slew of crappy games flooding the market. As opposed to all of the masterpieces that currently grace the iTunes App store.

If we make it too easy for people to release games, then we'll have too many bad games on the market. Right? Isn't that how it usually goes?

Well, I don't disagree with the symptom. It's why I made the snide remark about iTunes. But I'm going to go right ahead and smack down over the insinuation that these bad games are being made by people who wouldn't know how to make games if toolkits like Unity and UDK didn't exist.

In other words: Bad games, according to the sway of conversation, are the fault of non-programmers.

You know what? Get off your fucking high horse.

I'm getting pretty resentful of this elitist and exclusive attitude. Often when it's not being literally stated, it's there between the lines in the way beginners and *spit* *spit* artists are treated with impatience or sometimes outright disdain on programmer centric forums. So I wildly underestimated the amount of code involved in what I thought was a simple action: on no the end is nigh. Yawn. Let me assume by your latest efforts that you wildly overestimated your artistic talents, and we'll call it even, k?

So it's the internet, and everyone's an asshole. I'm not a princess about it, usually, and it doesn't bother me, usually. But today, I read a post on a community forum that seemed laced with derision, entirely constructed to tear down the naive game maker - a youthful optimist, nonetheless - who woe be him does not come from a programmer background. It rubbed me in a way I do not like to be rubbed, and a ranting, obviously, ensued.

I should temporarily shut off the steam and say in big bold letter that I know a few programmers who I worked with in the past who I do not at all refer to in this post. In fact, I can only think of four people I've actually met in real life who do have this attitude. Sadly, one of them was a CEO.

But if you've read previous posts you'd probably know that a programmer colleague, James Podesta, has been helping me with code and design. I have no intention of biting the hand that feeds. I do suspect that he agrees in essence with the fact that accessibility to game development is resulting in more crappy games, however I would hope that he doesn't jump on that bandwagon of artist/designer/daydreamer hate that shovels the blame onto our underpaid shoulders.

It's made more difficult to argue my case here when one considers that improvements have been made to my game already through James' input. Without him, the movement wouldn't feel quite so nice. I would have eventually solved the collision bug, I'm sure, but it's those anecdotal tips and tricks that make the real difference, such as the 0.2 second fall-jump buffer.

But I'm going to use that example to argue that game development should be even easier. We've heard it a hundred times before: Graphics are not gameplay*. Well, guess what, neither is code. OMG GASP, RIGHT? No one gives a shit about your programming. No one in the real world, anyway. Your designers and artists will love you for it, and appreciate how your skills contributed to the product. You can pat yourself on the back for a job well done. But if you're going to argue that the polygons I push together are nothing more than a necessary component of the construction, far less than the sum of the parts, then explain to me why your lines of script are any different?

We can probably agree that all our consumers care about is the end product: Does it feel good? Does the aesthetic inform the gameplay? Do I have enough challenge and enough motivation to continue playing?

So all it's about is making good games. That's it. Who gives a fuck how you did it? If you take away the barriers to game development, then you open the door to more people who have a story to tell, an idea to sell, a concept to show off, and a real creative talent to make something entertaining and of quality.

Just because you have the rare technical proficiencies necessary to construct a game, does not guarantee that your game is any good. This has always been the case. Even when programmers were the only ones making games.

* I actually believe that graphics are gameplay, but I'll save that shitstorm for another post.