More great game dev advice (not great English). . .but still great advice.

Yeah, it was published two years ago. I know. I just now got around to reading it. So sue me.

We’ve never met, but I choose to believe Jesús Fabre wrote 5 lessons I learned while developing our first game: Flat Kingdom. just for me.

  1. Lesson 1. Think About The Final Product From The Beginning.
  2. Lesson 2. Think Of Performance And Optimize Your Game Through The Whole Process.
  3. Lesson 3. Always Be Aware Of The Time Needed To Code And Test Every New Feature.
  4. Lesson 4. Don’t Reinvent The Wheel, If It Is Going To Save You Some Time, Use Plugins.
  5. Lesson 5. Always Test Your Game With Your Target Audience.

I’m putting this here mostly as a reminder to myself for later (as in early 2018). Hope it helps you, too.

Unite Austin 2017 recap

Bear in mind, this is my perspective as an indie looking to invade the mobile gamespace in 2018. I’ve been cyberstalking Unity 3D and lurking around their booths at other game conventions for years and fiddled with the tools, but now it’s wave-or-salute time. From that perspective, this was my first in-person all-Unity event.

tldr; They did well. Not perfect, mind you, and a little smaller than I expected, but one of the better organized and funded game dev conventions that I’ve been to. I think they’re finally ready for me to jump in, and they’re still planning to go lots of cool places.

Training Day

Monday was a hands-on, newbie developer orientation day. The project assets were provided by Cybernetic Walrus (based on their new game Antigraviator) and the training by Unity staff. Although it had more than couple glitches, the demo level provided was full-featured and interesting to play with. The 13 introductory steps (most broken down into several subtasks) took most of the day at the trainers’ planned pace. The training (obviously) glossed over the modeling aspects of 3D game development and focused on the gameplay, camera management with the new version of Cinemachine (very sexy) and the new version of Timeline (very cool). They promised to provide the slideware, a completed (and enhanced) version of the project. I hope to get that next week and fiddle with it some more. [I was pretty happy with how my Surface Book handled the day. I think the i7 and SSD zoomed nicely through the work.]

Keynote & Kickoff

Since I was there for Training Day, it felt weird to have all day Tuesday to myself until the keynote that started at 6 pm, but I guess they’re trying to accommodate everybody else’s busy travel schedule. The keynote was well orchestrated and well rehearsed. There weren’t any significant fumbles, and they did a good job hyping the upcoming sessions for the next two days. Since I’m not the partying sort, I wandered through the kickoff mixer and hiked back to my hotel.


My one huge strategic error was not booking a hotel when I first signed up. By the time I talked myself out of driving back and forth from San Antonio to Austin every day, they’d already sold out the low-priced Unity block, and I wound up at the Double Tree a mile and a half away. Needless to say, I got my exercise hiking back and forth, since I’m too cheap to pay for parking downtown Austin. Punishment deserved and delivered.


These are the sessions I went to and the number of stars I’d give each:

  • 2D World Building in Unity (4/5)
  • OctaneRender for Unity (4/5)
  • Creative Scripting of Timeline (5/5)
  • Disruptive Virtual Cinematography on a Budget (2/5)
  • Unity Labs Behavioral AI Research (5/5)
  • Get Paid on Mobile (4/5)
  • Expansive Storyworlds (3/5)
  • Cinemachine for Games and Interactive (4/5)
  • Buil the Multiplatform Games of Your Dreams with UWP (1/5)
  • Neill Blomkamp’s Short Film Screening and Q&A (3/5)
  • Testing for Sanity (5/5)
  • Insights to Action (5/5)
  • High Performance C# Scripting With the C# Job System and the Entity Component System (5/5)
  • Massive Battle in Spellsouls Universe with Upcoming Unity Tech (4/5)
  • Trivia! Unity by the Numbers (3/5)
  • S.O.L.I.D. Unity (2/5)

There are several more that I wanted to go to, but there were conflicts. Overall, the presentations by Unity staff were more polished than the guest speakers. I was bummed that the recordings weren’t available to buy on a flash drive like other conferences do, but I’m hoping they’ll get them up on YouTube or something soon.


Unity has grown quite a bit since I bought a 4.x version of it almost a decade ago. I’m impressed with how far they’ve come. I’ve made the command decision to try my hand at free-to-play mobile game next year (2018). The convention inspired me to begin writing the design doc and thinking through the gameplay and the freemium monetization model. (Daddy’s got bills to pay!) Since you didn’t ask, I’ll tell you anyway that the game will be set in the Starcrossed universe. Be thinkin’ about where you want to take your own personal starship. . .

Learning under fire. Is there any other way? =P

I’m one of those folks who prefers to test the depth of a river with both feet, and this learning mode from CodeAcademy appeals to me.

Codecademy does a pretty good job, but one group of programmers wanted to make it a little more accessible. Enter CodeCombat, a browser-based game where your in-game actions are dictated by the Javascript code commands you type.
CodeCombat: Learn to code through dungeon crawling

Just in case you get caught playing, at least you’ll have the “job skills training” excuse already built in! Heh.

Amusing, but accurate, code quality metric

In a code review, the lower the number of WTFs/minute is as good a metric as any other. The highlighting in the quote below is mine.

Which appears facetious at first, but perhaps hints at a deeper truth: high quality code should not surprise us; we should be able to quickly and easily discern the structure and intent of the code. But doesn’t this then place software quality in the eyes of the beholder? What if the person evaluating the code isn’t familiar with the patterns used by the original developer? (Or – to be more cruel – what if they just aren’t competent enough to recognize the patterns used?) Are they not likely to harshly judge the code based on miscomprehension? (A similar suggestion to this measure is that software quality is inversely related to the amount of time required to make a modification; again the major problem with this is that it depends on the capability of the person making the change).

On Code Quality « Project ogsa-dai

Too many developers are overly impressed with their own cleverness. I’ve found this more often in “classically trained” developers than self-taught developers, and I’ve found it in myself, too. Regardless the source, resist the temptation to implement cleverly… you’ll wind up writing bugs you can’t fix. Ask me how I know. Heh.

Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?

"The Elements of Programming Style", 2nd edition, chapter 2, by Brian Kernighan

Not a good plan. A better plan (to paraphrase Einstein) is to write the simplest code possible, but no simpler.