Finding the Fun

Reflecting on the past year of game development (and related stuff), I learned a few hard lessons. Here is a breakdown and some additional rambling, which is hopefully of some use to you.

 gameTimeline2An approximate plot of my games to date. I really got off track this year.

Lesson #1: Get good at failing.

Failing is super key. I know this, and I’m sure you do too. But I am still not very good at it sometimes. What is failing in the context of making games? To me, it’s learning when your game should no longer be pursued. A couple of times over the past year, I poured weeks into stuff that was not and would never be good. The “One Hundred Prisoners” project is a prime example. I had the idea of making this game. The idea was simply not a fun or worthwhile game idea. But, I didn’t realize (or want to admit it), so I kept pushing the project forward. After many weeks of making cooler looking textures and adding sounds and stuff, I finally gave up. Why? It wasn’t any good!

makingAGame2
A crude illustration of my part of my game making process.

Lesson #2: Gameplay. Gaaaaameplay!

 

dontDoThis

Games do not need to be fun*. But, they do need to be GOOD. The “One Hundred Prisoners” project was not meant to be fun. But, the end result would have been an experience that had someone basically walking up and down a hall a few hundred times. I could add some dialog and stuff, sure. But at the core of the experience, the only way the player could interact with the world was a light switch. That is not a compelling experience. The game play was not there, so the game should have been abandoned as soon as I realized that. But, as mentioned above, I decided I would work on graphics for a while, then come back to the game play. I skipped over the “Is it actually any good?” decision point, and went to the “Making it look and sound good” phase. Bad idea! But it was easier than making the decision to kill the concept and move on.

*Not looking to argue this point. There are plenty of arguments around this online already 🙂

 

Lesson #3: Making a framework for a game is easy. Making it a real game is hard.

A couple other projects I worked on this year (looking at you, 2D Golf) resulted in some pretty fun core game play. However, I got the games to a point where I needed to commit and make actual levels and art and stuff. But I didn’t want to. I liked the “Cool ideas!” phase of the project, but didn’t want to do the grunt work to build the rest of the game. So it got shelved. Will I come back to it? Maybe. Probably not.

I do find some joy in simply proving out a concept. Recently, I made a mario kart like thing in Unity in about an hour. However, this time I resisted falling into the “Oh, I’ll just go make mario kart now” trap. Nope. I proved the concept to myself, it was neat and fun, yay for me. Time to move on.

Lesson #4: Sometimes (Most times) fun is enough!

Games don’t need to be fun. But, a lot of games are fun! So, why not start there. Some of the mental traps I fell into in the last year were trying to stretch my game concept into being something more than it ever could be. I took a few garbage concepts, and polished them. Tried to add meaning or complexity when the core concept was no good. Guess what? They were still garbage. They just took a lot of my time.

Recently, Tom Francis started a youtube series about making a game with no experience (It’s really great, and you should watch it). I started watching the series, and in the first 8 hours of fiddling with a basic game, I got something REALLY fun completed. It’s not a game yet, it’s a little game zygote. But, it is good. I added some zazz (See “The art of screenshake“), and it feels like something that can be a fun experience.

 
badGraphics
Note, the graphics and sounds are garbage at this point (see above). But I am really refusing to let myself deviate from adding game play value and fun to the game. This is key to keeping me in the “good stuff” zone for the project (see games plot at top of post). If I add something, and it doesn’t feel good to the game, it gets dropped. I don’t care if it’s the coolest idea I’ve ever had. If it’s garbage, it doesn’t go in.

 

Lesson #5: Game Play Foot Notes

“A bystander asked an equestrian sculptor how he did it. The sculptor replied, ‘I just chip away everything that doesn’t look like a horse.'”

A teacher of mine once told a story to the class. He said his professor taught him to take non-core ideas out of his papers, and insert them as foot notes instead. That way, his ideas were still there, but didn’t interfere with the core concept of the paper. Before handing in his paper, his professor told him to delete all his footnotes.

I think this applies to game ideas. If you think an idea is cool, but it doesn’t make the current game better. Make a footnote (email it to yourself, write it on your whiteboard, or whatever). But don’t let it interfere with your game! If it’s such a good idea, you will come back to it when you make your next project. And if it’s not, you didn’t waste time exploring it and taking time away from your current game.

 

That’s it really. Nothing earth shattering, really. Just some stuff that I thought I knew to avoid that I did not avoid as well as I thought.

 

 

 

Posted in Uncategorized | Leave a comment

Fetching Palettes from Textures in Unity

I was making a thing, and I wanted to get a list of the hex values for the colors of an palette image I made so I could import into Paint.NET. So I made this thing that does it using Unity (had it open already :))

http://pastebin.com/6kY35Kvp

paletteThinger

If pastebin does not make things public domain, please consider this post a declaration of that instead.

Enjoy!

Posted in Uncategorized | Leave a comment

Code Ambiguity in Unity

Edit:

Revisiting this post a few years later, as a “seasoned Unity/C# programmer” (see below), and it seems it doesn’t really matter anymore. After a while, stock components/types and custom scripts all meld together as part of the flow of coding in C# with Unity.

Here’s the original post for context:

I have stumbled across a lot of ambiguity in code around the web in the context of Unity. Just now, looking at a very stock item – the FPS character controller. I wanted to get a C# version of the CharacterMotor script and FPSInputController script, so that my life is a little easier (all code in C#), and also because I really dislike using js with Unity.

In porting this over, using an example I found, I noticed this section of code:

[RequireComponent(typeof(CharacterMotor))]

// snip

motor = GetComponent<CharacterMotor>();

It was not super clear to me (and never really is) when a Component is a built in Component or a custom Script (which is also a type of Component). When I make scripts, I append “Script” to the Component (read: Script) name to be super explicit that I am dealing with a Script. Looking at something like CharacterMotor, and I wasn’t sure if I was dealing with a built in Component type or a custom Script. Turns out I was missing a Script. This wasn’t super difficult to figure out, but it could be a lot easier to figure out. Here’s the new code:

[RequireComponent(typeof(CharacterMotorScript))]

// snip

motor = gameObject.GetComponent<CharacterMotorScript>();

if(!motor){
  Debug.LogError("FPSInputControllerScript:: Cannot Find CharacterMotorScript");
}

I find the latter a lot more friendly for debugging and sharing with other people. If anything goes wrong, it will be abundantly clear why. If the required Script is missing, an explicit error message will call this out. I also typed the additional “gameObject.” prefix so it’s clear where the GetComponent<>() call is going.

I imagine the seasoned expert Unity/C# programmer will scoff at this complete waste of keystrokes. But I know whoever uses this code won’t complain that it’s “too human-readable”. This is something to keep in mind when writing code for other people, selling your Unity assets, or posting examples online. The consumers of your code can always make it “more efficient” by deleting the extra stuff. And if they don’t, there is no real downside.

 

 

Posted in Code, Unity | Leave a comment

Working with dynamic materials/shaders in Unity

So I decided to test a standalone build of a Unity project I am working on and encountered a severe performance issue. I was getting about 15 frames per second, which made no sense at all. At first I thought it was to do with some new objects I had just added or too many normal maps or something.

It turns out that the standalone version did not like something I was doing with dynamically created Materials, and was logging thousands of lines a second to the output_log.txt file. This was the error in the log:

 

NullReferenceException

at (wrapper managed-to-native) UnityEngine.Material:Internal_CreateWithShader (UnityEngine.Material,UnityEngine.Shader) at UnityEngine.Material..ctor (UnityEngine.Shader shader) [0x00000] in <filename unknown>:0 at ParentClassName.Start () [0x00000] in <filename unknown>:0 at ChildClassName.Start () [0x00000] in <filename unknown>:0

(Filename: Line: -1)

 

I immediately suspected I was doing something wrong with the abstract class (ParentClassName), but after some investigation found that no, in fact, it was the Material. This line, specifically:

myHighlightMaterial = new Material(Shader.Find("Reflective/Specular"));

 

To work around it, I simply had a create a new Material in the editor (left blank/default) of the same type (Reflective/Specular), and stick it in the Resources folder. The code to do the same customization is as follows, and works fine.

myHighlightMaterial = Resources.Load("MyHighlightMaterial") as Material;

 

You can also customize the Material using the shader variables all you like, allowing for some neat things, I think.

// Set some material properties
myHighlightMaterial.SetTexture("_Cube", highlightCubemap);
myHighlightMaterial.SetColor("_ReflectColor", myHighlightColor);
myHighlightMaterial.SetColor("_SpecColor", myHighlightColor);
myHighlightMaterial.SetColor("_Color", Color.white);
myHighlightMaterial.SetFloat("_Shininess", 0.01f);

I am back to 60+ frames per second, and no longer sweating. A good bit of positive reinforcement to occasionally test standalone builds though! Not everything works the same outside the editor.

 

Posted in Unity | Leave a comment

Hello World – New Blog

Hello World…again.

I’ve decided to host my blog on my site rather than tumblr. Not sure if I’ll actually post more stuff here than there, but who knows!

Posted in Uncategorized | Leave a comment