Category: games

The Tall Man

This is not the first time I have faced the end of my career as I knew it.

 

Picture it: the year is 2003. The Matrix Reloaded and Revolution are going to be coming to theaters soon. And on the fifth floor of a nondescript office building, in a tiny room with no windows, sits a tall man in a relaxed pose and a short man looking very uncomfortable.

The short man is telling the taller that he needs to read his required three career improvement books per quarter to continue being employed there. The tall man listens and smiles, laughter bounding in his mind, but only letting a smirk show on his face.

For the last six months the tall man was told to build reusable software for importing email address databases. At no point was it defined how it might be re-used. They even brought a second programmer on the project, fresh out of college with a shiny degree in a frame set against the window at an odd angle, to architect this design. This architect declared the five-tier architecture was the path to reusability. And then proceeded to create separate, duplicate copies of every structure in every tier. Every change needed to be made in five places.

When the completion deadline loomed, the tall man knew the project was doomed. Yet until that last week, he figured it could be saved. But as the day of the deadline arrived, the tall man could not even get out of bed, too sick from worrying himself over the first true failure in his career as a developer.

For four months after being let go, the tall man could not even bear to touch a computer. He was thoroughly sick of them, wanting nothing to do with them. His entire career, almost his entire life was spent around them. Tinkering with them in high school, making games on them in college. And now, he couldn’t touch one, or he would feel the stink and the fear of that last project.

He knew it was time to get serious about his next move. What was he to do? Computer programming was the only thing he ever felt he had a talent for. Grudgingly he contacted a local non-profit organization to see if they might want some help improving their online presence. He wasn’t after money. He was after a measure of making someone happy.

It wasn’t much that he did, but it did make a small difference for them. And they were grateful. The kind of gratitude that didn’t exist at that last job. The kind that he knew was required to keep his sanity if he were to ever work for any purpose ever again.

He set about re-learning the business of game making. When he was hired at that email company they were making games, but their vision had shifted. He was simply riding things out as long as he could, looking around for better opportunities. As it turned out, none came.

So with the strength of his wife’s support and tip of the hat from someone willing to take a chance on him, he began writing the game engine that would restart his career in games.

 

In truth, I’m hardly starting over at all. I will still be able to bring to bear the talent that God gifted me. My heart goes out to you who are forced to truly start over.

Indies are Go!

So now that I’m between gigs, I’m going to try this “relaxing” thing while I listen for what God wants me doing next. But I still gotta do something. So I’m making myself available to all you indie developers! That’s right – come talk to me so all of this great Unity3D and game development knowledge doesn’t go to waste.

You will actually be doing me a favor. Why you ask? Because if I don’t use a piece of knowledge for more than two weeks, it’s almost as though I forget it. Which incidentally is why my code is so well commented, because I know I’ll forget what I was thinking when I wrote it!

You can connect with me through this website, or if you prefer, either of the following teamup sites:

Happy coding!

Marvel Mighty Heroes (iOS and Droid)

App Icon

  • Product description: Free-to-play four player Brawler game for iOS and Android
  • Release Date: March 31, 2015
  • Website: Marvel Mighty Heroes
  • Product history/genesis: Looking for a new game genre, we attempted realtime multiplayer in full 3D and succeeded
  • Team: Varied, largest team was 20. I was one of 5 client coders for most of the project
  • Core Technologies: C# in Unity3D with a Scala-based server
  • Most proud of: New Asset Bundle system that allowed bundle sharing and downloadable scene replacement
  • Responsibilities: Sole implementor of almost all UI for most of the development time; Tool development and support for rest of team.

A month or two before I came on this project, I was given the freedom to start working on taking existing code from our Hellfire project and organizing it so that we could share that basic code across new projects. While I was successful in starting a shared technology stack, it was clear that much more needed to be done to make it solid for other projects to use in earnest. Part of that stack was the Asset Bundle system rewrite.

In Unity3D, the simplest way to publicly download additional content like models and textures is to add them to a Unity-specific container called an Asset Bundle. This feature worked, but was under documented and difficult to use at the time in Unity3D version 3. We had some strong code for working with these asset bundles that was developed by the Hellfire team before I started working in Unity. However, the code was complicated and did not support the sharing of resources between different asset bundles. My goal was to fix that.

While I was working on that shared technology, it was determined that one of our new projects was going to need more client coder help than was available. Therefore when I was brought in, I was still developing that shared technology at the same time as implementing user interface designs in this project that already had almost a year’s worth of prototype work done on it.

I would end up spending most of the project this way, doing double duty as the only user interface developer as well as adding tools to make production easier as well as creating the new asset bundle system to make this large dataset manageable for devices. It was only three months before release that I was able to complete the asset bundle system.

As it turned out, Unity themselves had the same ideas I had about asset bundles. Not a month after completing my system, I learned that Unity 5 was including a new asset bundle system which did exactly everything I had put into mine.

All that aside, this was the most complicated user interface design I had ever attempted. Early in development I made this statement to our designer: “Go crazy, dream up anything you can think of, and I’ll try it. If I can’t do it, I’ll let you know.” Sure enough, I was able to make happen a lot of complicated scrolling contexts and interactions that had not even been dreamed of for the Hellfire project.

We support both phone and tablet devices, iOS’s few resolutions and Droid’s many resolutions, all using the same scene definitions. Each scene was put together based on virtual screen dimensions that scale the interface up but not let it get too “fat” and then use the “springs & struts” style of automated item layout to fill in the differences in device aspect ratios.

Other major improvements over the previous codebase was a new scene loading system, one that no longer assumed only one scene was displayed at a time. To make that happen I also had to rework how scene transitions worked, as well as seemingly simple things that became very complicated like handling the Droid “Back” button. All of this code written from the start with the idea of adding it to the shared technology set that I started with.

This was my largest project with this company, and sadly, my last. After twelve months of my work and just a few days after releasing to the public, I was laid off along with many other people.

Despite the difficulty of this project, I am still extremely proud of the work that everyone did on it. This is one of the projects where every single member of the team knew what they were doing and worked with each other to make it happen.

Couch Fishing

Both game veterans and newbies start with the very same blank page. Even for me, a veteran developer, starting a new project is a daunting task. The difference is that I have the experience to realize what to focus on first.

Except I was completely wrong. I’m building a simple board game, based on a really neat article on simple ways of calculating things in a hex grid. So my first instinct was to start implementing that knowledge as a utility class. Which, in itself, is perfectly reasonable. But then I realized I was writing and testing utilities I’d probably never use!

This is a very common issue at any point during development. You have this idea you want to convey to the computer, but don’t really have a firm design in mind. Writing some code just to fill a page is still a useful tool, so use it. The problem is that many people get stuck far too long in this phase and not step back to re-examine what you really need. In my case, I spent an evening on that utility class. When I stepped away, I realized that was further than I needed to go. (Reminder, there is a strong case here for taking breaks often. You never know what will occur to you when you step away for a minute.)

So now what? You’ve written one utility class. It’s time to sit down and think about how you plan on designing the code for actual game. You may have already worked out the rules of the game, but there is a huge difference between knowing the rules in a human understandable way and coding those rules into a game.

It is here that you should now be focused on. Design the rules of the game and design the code that will implement the rules of that game.

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.