Category Archives: Programming

Posts about anything programming-related

Advantages of a Beginner

When you’re a beginner, it’s easy to feel like you don’t have anything to offer. After all, there are a gazillion people out there who are better than you, right? It turns out newbies bring a lot to the table.

Beginners know how to learn new skills. Let’s say you want to learn programming. Who do you think is better to ask for advice: a friend who’s been doing it professionally for thirty years, or your friend who took a single college course on it about two years ago? Well, the 30-year seasoned professional hasn’t had to learn how to program in decades, and they learned back on a now-ancient Commodore 64. Even though your other friend is quite inexperienced, they’ll have a much better idea of where to get started.


Not that you couldn’t still learn to program on one of these today, but it’s a few decades behind current technology. (Source: Wikipedia)

A beginner can write a guide or tutorial in a language other beginners will understand; experts will have trouble.

Newbies (potentially) know a lot about new tools and technology. When you’re teaching yourself a new skill, you’re inherently forced to put a lot of research into that topic. Odds are that you’ll stumble upon a lot of new and upcoming tech during that research. It’s also easier to objectively compare different tools and tech when you don’t have several years invested into a particular tech stack.

Beginners don’t yet know what isn’t possible. It’s easier to think outside of the box when there is no box. When you have a lot of experience in a field, it’s easy to dismiss a lot of ideas that seem impractical without giving them the attention they deserve. Obviously, this same trait can also backfire horridly and bite you in the rear, but it’s not without its advantages.

A Swift Review of Swift

Over at Ludisto, we’ve been using Apple’s new programming language Swift for our latest mobile game. We started back in July while Xcode 6 was still in beta, and the language has evolved and improved a lot over that time period. Most of the time, the experience is fantastic! Other times, well…

swiftc segfault error

…the compiler segfaults with no useful error message.

The upside is, you know the issue was caused by your most recent code change(s). Tracking it down usually isn’t too hard, but figuring out a workaround can be annoying. Most of the major issues were hammered out during Xcode 6’s beta phase, but you do still run into problems from time to time. Some form of continuous integration (i.e. automated builds) would likely be pretty useful for catching issues early. For example, right now, we’re dealing with an issue where our project won’t Archive, which is needed to build the app for the app store; that would’ve gotten caught much earlier if we had an automated build system checking things nightly.

For anyone with any reasonable amount of programming experience, Swift is super easy to learn. Apple’s book The Swift Programming Language covers it really well, and is a good reference manual. The catch here is that you won’t learn any of Apple’s APIs from that book, so jumping into actually writing an app in Swift is probably a lot easier if you’ve used Objective-C in the past. As someone who had no prior experience with native iOS development, I struggled a little, but it was absolutely manageable. Adobe Flash was über easy to get started with back in the day; SpriteKit is even easier. Apple’s Swift resources page gives a lot of useful links. For a really good tutorial project to get started with SpriteKit, I highly recommend How to Make a Game Like Candy Crush with Swift. Additionally, Apple’s WWDC 2014 videos have a ton of useful talks to watch for free.


Getting to use Xcode is also a nice perk

Overall: Swift is great! I highly recommend checking it out and using it, especially for smaller projects. There are still some small kinks that need to get hammered out, though, so I’d recommend against using Swift exclusively in a large project just yet; check back in maybe six months to a year.

Why Depth is Important

Generally speaking, your education will expose you to a lot of different ideas and make you a well-rounded individual. That said, while breadth is important, having an area of specialization can make all the difference in the world. As a newbie, the value of this isn’t inherently obvious: doesn’t a more varied skill set keep more options open? Sure, big teams might need focused specialists, but wouldn’t small teams favor generalists? It’s actually surprisingly simple: having a specialist on your team, or at least knowing someone to go to, makes things a lot easier when you get stuck.

When I was working on Carbon Conquest (an RTS being made in Unity3D), I had a lot of trouble optimizing the fog of war. Essentially, the fog was created by creating a semi-transparent black texture, then drawing fully transparent circles in it at each unit’s position. The texture was then projected onto the terrain. This looks exactly how you’d want it to, but generating the texture was a real bottleneck. The naive implementation I started with just created a 2D array of colors in code, drew the circles in all via C# script, then copied the color data over to the fog projector’s texture. Obviously, doing this every frame in a component script is going to slow things down.

As this looked perfect but just ran too slowly, I wanted to re-write the texture generation as a shader to speed things up. Couldn’t be too hard: you just need to go through a bunch of location data and change the texture’s color if it’s close enough to a unit at that location. I started to learn Unity’s shader language via a pretty awesome tutorial, but I got stuck: how should I get the unit position data over to the shader? Based on what little I’d learned, I had this dilemma: “I can pass data to the shader, but only via constants, and we have a variable number of units… huh.” And right there, I was stuck. To the internet! ….well, googling didn’t help whatsoever. To other human beings!

Alright, I’ve got friends who’ve done graphics programming, I’ll ask them! As it turned out, everyone I thought to ask had only really dabbled in graphics programming, so they weren’t really sure either. At that point, I was stuck with two options: 1. learn graphics programming in depth, or 2. hack it and actually finish the game before the deadline. Obviously, we went with option two. The fog of war would now only update once per second. Turns out this actually looks alright by virtue of older RTSes having similarly “choppy” fog of war (w00t!), but it would’ve been nice to have something more responsive.

Had either I or one of my friends had the appropriate depth of knowledge in graphics programming, we could’ve probably figured out a more efficient approach that would have ultimately led to a better gameplay experience. Instead, we had to settle on a hackish workaround. Generalists are good, but if you want to deliver the best possible product/game/experience, you’re going to want to have someone who really knows a given subject. Ideally, you’ll be someone with a broad skill set who also has an area of expertise; this is the “t-shaped” skill set that companies like Valve are looking for.

Licenses page added to my site!

I’ve finally gotten around to creating a page that details licenses for source code posted on my site. Check the Licenses page for details!

This is something I really should have gotten around to earlier. If you run a site with code posted, it’s also something you should do. Unless you have a license available for your code somewhere, others cannot use it in their own projects. For example, even if you write a super-helpful blog post about how to solve a programming problem, or offer useful code snippets in your posts, others cannot legally use them.

I opted for the MIT License because it’s super open. I’m in the process of adding a text file with the license to applicable files on my site, but in the meantime, feel free to contact me if there is any confusion. If you’re not sure where to start on picking a license for your code, consider this list of Open Source Licenses.

Also, as a disclaimer: I am not a lawyer. If you need legal advice, you should consider consulting a lawyer or attorney.

GDC Day 1: Math for Games Programmers

GDC '13 logo

For the second year in a row, I attended the Math for Games Programmers tutorial at GDC today. As expected, there was a fair amount of review, but I also learned some cool new things!

The earlier talks on splines, blending, matrices, etc. were basically review for me, but it was nice to have that refresher. That said, one tip came up that really stood out to me for matrix math. Matrices are multiplied in a sort of “reverse” order, for example:

Rotation * Translation = translate-then-rotate

Incidentally, this is actually the same order you’d write functions while programming:

rotate( translate( point ) ) = translate-then-rotate( point )


Jim van Verth’s talk on quaternions was absolutely fantastic. He spent the talk discussing how quaternions work rather than why we use them. Questions like “why four values?,” “why do we input theta over 2 instead of the entire angle?,” “how can we visualize 4D space?” and more are covered. As a bonus, the tutorial will actually make it to the GDC vault this year, so definitely check out the talk if you can! If you don’t have vault access, you should be able to pick up the slides at once they’re posted.

Dual numbers sound useful, but I’m not sure how often I’ll use the content of the lecture. That said, “you can basically get the derivative for free” is a pretty awesome thing to keep in mind. They’re pretty interesting from a mathematical standpoint.

The talk on Orthogonal Matching Pursuit and K-SVD for Sparse Encoding went way over my head, but I still pulled a good deal of information from it. I think I have a rough idea of how compression works now. I have some research to do!

The talk on Computational Geometry was pretty interesting, though it seemed more or less the same as last year. Still, it was good to get the review – I had forgotten a lot of it. I also learned about higher order surfaces on the GPU (i.e. tesselation, etc.), which was new to me!

Finally, the talk on Interaction With 3D Geometry by Stan Melax was amazing. It was a super-fast-paced crash-course on a huge number of subjects that left me really inspired to start writing some tech demos to learn how all of the concepts work. I’ll definitely be watching it on the vault.

Tomorrow: Physics!

Planning Out an OUYA Launch Title

Photo of prototype running on OUYA

After hammering out a prototype for the CREATE game jam (partly to prove to myself I can make this game), I’ve been planning out the development cycle for my upcoming OUYA game, Project Onslaught. In terms of time frame, there are a few known dates:

  1. February 11th – CREATE finalists announced
  2. February 18th – CREATE winners announced. At this point, I’ll know for sure what my budget is. Keeping my fingers crossed!
  3. March 4th – Classes begin again for me, splitting my focus
  4. March 8th – Chuck, fellow OUYA enthusiast, comes to visit for a while and help out, which will help offset classes starting up again
  5. March 25-29 – GDC week
  6. March 28 – OUYA Launch Party (but not necessarily console launch)

There’s no official launch date set yet, but as the “launch” party is during GDC week in March, the apparent best plan of action is to be done by GDC. That said, they could hypothetically launch the console any time in March based on the Kickstarter dates, but I highly doubt it’ll be in the beginning of the month. Ultimately, that gives me about 8 weeks to develop a 3D hack ‘n slash game.

I’ll also be starting “from scratch” in the sense that I won’t be using the prototype code. I went into the CREATE game jam with the rule that I won’t carry over the prototype code so I could make it as hacky as needed to meet the deadline, and I’ll be sticking to it. It wasn’t wasted time – it was a solid proof of concept, and it gave me a much better sense of how to structure everything.  Plus, looking back at it for reference is fine, I just won’t be copying it fully.

With the 8-week time frame in mind, I needed to figure out what the minimum viable product (MVP) is. The MVP, as its name implies, is the bare minimum that needs to get done by launch for a solid game release. Updates after launch are definitely planned, but when the game comes out, we’ll need:

  • 4-player support, local multiplayer
  • 4 hero types to choose from, so everyone can be something different if they want
  • Arcade Mode – Basically, one or more game modes that are focused on high scores, replayability, etc. Arcade mode will be free content.
  • Campaign Mode – At least the first “chapter” available. The first level or two will be free, with the full campaign available for purchase (potentially released on a chapter-by-chapter basis)
  • Power-ups/consumables – think Gauntlet: Dark Legacy. These have the potential to add a lot of fun to gameplay, and should also help the player feel like a complete badass from time to time
  • Basic character progression. At a minimum, XP and levels that give more HP. Preferably, a few basic stats that can be increased. Nothing more complex than that – it should be a game you can sit down and play without fiddling with complex stats/builds/etc

With all of that in mind, I’ve got a rough, tentative schedule written out. It’s super-duper subject to change, but for now:

  • Week of Jan 27: Re-implement player controls and basic combat mechanics (i.e. attack stuff to kill it). Hopefully knock out multiple hero types in one shot.
  • Week of Feb 3: Enemies. Lots of work on enemies, to give lots of options for building levels/scenarios. Also includes polishing combat mechanics.
  • Week of Feb 10: Build Arcade mode. Pretty much a more robust variation of the existing combat prototype. Cross fingers and hope to win CREATE prize money to fund art assets
  • Week of Feb 17: Start working on a framework to build levels for the campaign mode. Discover I won prize money and rejoice! Or, failing that, congratulate the winners on a job well done =]
  • Week of Feb 24: Finish campaign-building framework, and anything else missing in core gameplay.
  • Weeks of March 3, 10: Content! Build content! (Also a buffer for slips in earlier plans)
  • Week of March 17: Feature freeze. Polish. Only finishing up campaign content along with polishing and bug fixes – anything that hasn’t made it in yet won’t be in at launch (but hopefully will be shortly afterward!)
  • Week of March 24: GDC week! Potential launch week! Network, talk about the game, go to talks, etc.
  • Following weeks: Game maintenance, work on new content, etc.

I will, of course, be posting blog updates along the way as things progress. I wholeheartedly expect the schedule to change drastically before I’m done, but I’ve got a rough outline hammered out for now at least until more details develop. Part of the reason all of March is content is that I’ll also be busy with schoolwork, so I’d prefer content development and polishing to hardcore coding binges. That, and it gives a bit of flexibility if the console launch is announced earlier than expected.

It’s going to be an intense two months, but if it’s anything like the game jam was: this is going to be damn fun!

Project Onslaught: OUYA CREATE Entry Complete!

Prototype Features:

  • Supports up to 4 players!
  • Each player controls a warrior character
  • Enemy skeletons will spawn in an arena as the party fights to survive!
  • Game stats are displayed once the entire party is defeated. Try and beat your friends!

Development photos: Imgur album

Downloads: Android APK

Cross-post on here!

Official OUYA forum post here!