Inching Toward Success

Recently I was approached by a small group who are at the nascent stage: they have an idea. Better, they put together a top level view of what the game should be. By this alone they have already surpassed most people’s aspirations toward game dev.

Their background was in business software, not games. Why is it so different? In business, if you’ve worked out what the “customer” wants and deliver even close to it, you will succeed. In games however, the “customer” does not tell you anything about what they want until after you’ve built and shipped it and hoped that the “customer” likes it. The developer must guess every part of the design on their own. This can be informed by many means, but it doesn’t change the fact that at the end of the day, you only have your best guess to go on.

So began my involvement. I quickly learned that this group had never done game dev before. They had a few broad strokes down, choosing a game engine and beginning to learn it. It occurred to me that they were starting from (almost) zero and shooting for a AAA title on the first try. I was reminded of a different group the year before who had attempted exactly this. We haven’t heard from them since.

the thing It’s amazing how comic artwork operates. It’s simplicity takes our greyscale, muddled color world and simplifies it into a shining example of a single concept. It was this bit of brilliance from @BaconAndGames that flashed through my mind.

Based on this, I offered them a game plan. Don’t shoot for the moon on your very first try. Instead, break down the game into component pieces and make games from each piece. The eventual goal is that by the time you have make the full game, you have learned what works and what doesn’t for each of the component parts.

Steps to goal gameThe first step is to create the complete game design. Definitely shoot for the moon. Then break it down into component parts. Some parts will be technical abilities, like communicating with a server for profile information. Most parts will be features of the final game, for example a time-based recharge system. For each part, you build a completely separate game. Each game must be completely separate branding from your final game. This way if one of the separate games fail somehow, it does not tarnish the reputation of the final game.

Another golden piece of advice is this: shipping something is always more useful than spending 5 years and having no product to show for it. It would appear that breaking up your game you would be going farther away from your goal. But in fact you are accomplishing these goals:

  • Learning about game development
  • Learning about your audience
  • Shipping something
  • Making investors happy
  • Building a reputation as a developer
  • Building your game

Yes, you really are building your game in this process. Because as you write these secondary games, you write the code in a reusable fashion. When it’s time to build the full game, the code is already (mostly) there.

By the time you are ready to build the full game, you won’t be looking at a mountain. You’ll be looking across a short bridge to the game that used to look like the moon.

How to be stronger at your [insert creative job here]

This is the most useful thing that a manager ever did for me: he setup a standing, consistent weekly meeting with just me. The aptly-named “one on one” meeting.

 

This meeting is possibly the most powerful 30 minutes of your work week. You can know that what you say will be heard by your boss. We are all deluged with emails and passing each other in the hall while on the way to some other task. Not much chance to focus that way. Your manager has a lot to to consider when dealing with the big picture. They go to all the meetings that you consider a waste of time. They are busy people, even if they are handling a team as small as five. This recurring meeting is a block of time when you know you have each other’s undivided attention.

Software is a creative endeavor. It is also all about tradeoffs. Choosing to spend your time on the right problems, and glossing over the stuff that won’t ultimately matter. To do that, you need the big picture. The thing is, you do not have the big picture. Your manager does. How you get it is not through email threads or memos. There is only so much information that you can get from open forums with multiple people, due to politics and other factors. You get that big picture by having a conversation with your manager.

 

If you aren’t asking questions of your manager, then you probably don’t understand the situation well enough. Even if you throughly understand the project, this is time you can learn more about each other on a personal level. This will make it easier to predict each other when decisions need to be made.

 

I still struggle with this even after doing my creative job of computer software and game development for twenty years. If I wanted management, I could have it in a heartbeat. But I don’t like that it would take me from my code. As Capt. Spock said to Admiral Kirk, it would be “a waste of material” for me to take a promotion.

 

A few months ago I was put under a new manager for a new project. His suggestion was the first time I’d heard of it in my career. He tells me it became a priority after reading “Managing Humans” by Michael Lopp. I do not fear end of term reviews, or getting close to crunch time. This is because I know that my manager has told me what to expect, and I was able to tell my manager what I thought we can do about it, all long before it happened.

 

Ask for 1:1 meetings. Make use of them. You both need to know about each other’s expectations and concerns as early as possible.

Warp Shader References

Tonight I did a presentation at a Unity3d user group.
I referenced a few items in the discussion that I thought might be helpful to have direct links to.

Basic Shader
http://docs.unity3d.com/Manual/SL-VertexFragmentShaderExamples.html#simpleshader

Creating Shaders – Surface Shaders, but have a lot of solid basics
http://unitygems.com/noobshader1/#prettyPhoto

Unity Sample Assets
http://blogs.unity3d.com/2014/01/17/new-sample-assets-beta/

Final Shader (with a few tweaks beyond the presentation version)
http://dwulf.com/source/Fudge%20Ripple.shader

All games are engines

Write your game code so it can be re used, and your next game benefits from it. Ideally only the things that make your game unique will not carry over to the next game.??

Here’s the setup: I spent time fixing up a chunk of code for use in our asset pipeline. However, my lead coder had his own feelings about an addition I had made. What follows is my response.

 

It appears to me that there is a fundamental difference between how you and I approach coding. Please correct me if you feel this is wrong:
– you are concerned with making changes for the sake of this project.
– I am concerned with making changes for the sake of *all* projects.

This strong typed id is a perfect example. You do not feel it is a good fit for this project. Okay, I can certainly live with that. But not every game team will necessarily make that choice. And that is the core difference.

At the same time, I do not feel that we should have custom versions of scripts and sources that are specific to particular games. This leads to maintenance nightmares. It is better to have one reusable script that has options to allow each targe team to make those decisions for themselves. Then when bugs are identified and fixed by one team, Then all teams can share the knowledge without having to import it into their custom version. It just “works”. Not to mention that additional features can be created and shared to all with minimum of fuss.

There is a limit to how much options should be available before the script is fundamentally different from the original base one. But a properly designed script or bit of code will only be doing one task, and most of the time, there is rarely more than one good way to do that task. This very fact automatically limits how many options are needed in the first place. If the task is so different that it needs a lot of extra support options then it is probably doing a completely different job and is no longer sticking to one task, and should be decomposed into multiple sources instead.

One script = one task. ??Likewise, the thrift making script does one task, and is fairly compact. I do not believe it should be split into multiple files because it already adheres to this principle. To split it would make the code harder to read, not easier.

Just because it is capable of the strong typed Ids does not mean you have to use it that way. It still processes a non typed id in the same way it did. As proven by converting the existing data set. It is improved with some other cleanups that are related.??

 

I feel that few game coders consider these kinds of issues all at once. And I think we could be making much better games if we were to simply design the basic stuff reusable. Much more of our games is basic stuff than most want to admit.

Boycott Bad Developer Tools!

I’ve been at this game coding thing a long time now. Long enough that I’ve noticed a difference in attitude of game coders who have been around as long as I have.

 

We wonder why our development tools have gotten *worse*, not better.

 

Agile and other high level methodologies are a fine thing. I make use of their ideals all the time. But that’s not what makes me productive. What makes me productive is that I’ve chosen the right tools for my job. But not the mainstream tools – because the mainstream tools have gone to the dogs.

CodeWarrior – anyone remember that superb Metrowerks development environment? That was the one reason I stayed with Macintosh computers for so long. At the time, Windows had Visual Studio. Which was an all-in-one window, covers the whole screen with wasted UI, sloppy, slow development environment.

The only IDE to surpass it was Xcode 3. Apple clearly learned a lot. And it was a superb run. Yes, they defaulted to an all-in-one interface, but they were smart enough to embed a way to break it up into the highly effective multi-window design of CodeWarrior. They knew where their bread was buttered.

 

There is an online radio show by a couple of smart guys. Apparently they are the guys behind the (most awesome) RAD game tools. I was using their stuff twenty years ago. And I’m both pleased and impressed to see they are still going strong. The Jeff and Casey Show, April 2014. They were expounding upon how they don’t care about high level tools when our low level tools have progressively gotten worse and worse over the years.

One thing they said rang so very true with me: we need to boycott these crappy development tools until the vendors realize that this is crap. Visual Studio not updating variables immediately during single steps? Two minutes to do a single run in Xcode just to install a *debug* version on an iOS device? And we won’t talk about 3 minutes for building the dSYM file. How can we possibly get anything done when we are spending so much time just waiting for our computers to do what a decade ago took half as long?

And yet we are in no real position to do anything about it besides cross our fingers and hope something changes. We have to use these tools because they are the only way to get our code past the gatekeepers. Or are we?

 

So I am productive – because I don’t use the gatekeepers. I use Unity3d, which lets me do everything in a very well designed *simulator*. (It’s a shame the MonoDevelop IDE is terrible, but it’s still faster than Xcode or anything else.)

 

Boycott these crappy development tools – and make better ones!