“Studio” Update

I couldn’t really think of anything better to call my desk than a studio. That and I’m sure “Desk Update” sounds more like a press room churning out whatever they can come up with.

The holidays have a way of stealing time away from projects. As does family drama and everything else that constitutes a curve ball in life. But you have to do what you have to do. If that means putting things on the back burner for the time being then that’s what has to happen.

As the holidays are just literally right around the corner, I’m starting to find time to get back to working on The Shopper v. 2.0, which is long overdue, and trying to finish up the two Android game projects I’m cooking up.

Two? Oh yeah. My second “filler” project. A Greg-ified Pong variant. If you don’t know what that means, don’t worry about it. I don’t either but I’m sure that whatever comes out of it will be pretty decent. At least I’m hoping it will. I really just needed to do something else besides for work on The Shopper and my other game. I haven’t churned out any Android apps since my pilot release and I want to get something else out there. I’ll be distributing on Play as well as other channels to friends and family. No need for any restrictions on this as it’s intended to be open source. Now clearly, I don’t own Pong or anything like that but I’m sure that as an educational vehicle, it’ll be just fine. As an entertainment vehicle, you may or may not puke over how awesome it’ll be.

For my game projects, I’ve finally decided to put my own personal touches so that it is clearly my work. Most of those are code formatting subtleties (nothing that makes the code unreadable). Others are visible to the user.  One such way of doing this is by creating a splash image for the name that I distribute apps under, Quorra Apps. The image is shown below. Nothing fancy but it’s pretty clean and simple. Plus the green kicks ass.

The splash image used in my games.
The splash image used in my games.

Maybe I should have added some inset to the characters? I rather appreciate the appeal and simplicity that “flat” brings.

In my last post, I’d mentioned something about doing a write-up on migrating from simple pixel-oriented mechanics in 2D games to using classical mechanics, or actual physics, to regulate the behavior of your in-game entities. I’ll release this in parallel with my Pong variant release. This way, I can get code samples lined up inline with explanations. Keep in mind with this though that I’m not the “go-to” game developer or physicist or mathematician. My profession is writing software for practical everyday solutions or business application. So what I’m saying there will not be the best way to do things and some of what I’ll say might be wrong. If it is, just send me a “Hey asshole!” email and I’ll fix it.

I’m going to finish up with salutations. I hope everyone has a damn good holiday, whichever one it is you subscribe to, and you don’t do anything too crazy.

After all, we survived the impending apocalypse yet again. Might as well pat yourselves on the back for that one.

Game Development – Migrating to Classical Mechanics

Let’s clear up some possible confusion regarding the title of this post. I’m not necessarily directly talking about game play mechanics as I am talking about the branch of physics called Classical Mechanics. You know, the fun stuff that helps us describe motion of mass under certain types of forces and the effects, both direct and indirect, resulting.

Well it’s fun for me anyway. Even though I hadn’t necessarily realized how much I’d forgotten about really simple stuff.

And let’s clear one more thing up here. I’m not a professional mathematician or physicist. I’m a software engineer. So if you’re looking for a primer on those areas, you’d be better served by Wikipedia/Wolfram, sites dedicated to those areas, or proper coursework. More importantly, my understanding of certain concepts might not be as robust as a skilled professional in either of those areas but I’m confident enough that I can describe what I see in everyday life enough with classical mechanics to be proficient in what’s called applied mechanics (that was actually my strongest point).

What I wanted to talk about here is something that I’m sure every game developer has dealt with at some point in time when designing a 2D game (strictly 2D). But to best describe what I’m getting at, I should probably start with an example.

Moving a block from one point to another is a relatively simple task to accomplish. Assuming that you’re not using an origin offset of some type, moving from point A to point B would look like this:

A simple affine transformation
A simple affine transformation

Geometrically speaking, this can be accomplished by a simple affine transformation. However, even though you could get away with expressing this event with an affine transformation, it’s not taking into account how this would happen in the real world. Even autonomous movement doesn’t occur without some type of external force being applied to the object to make it move in a certain direction. That being said, an affine transformation like this wouldn’t actually happen without some force being applied to the rectangle to make it move from vector A to vector B. Visually, the player may or may not be able to tell the difference between which method you chose to use. But we all know which one is more fun. 🙂

With that example, I wanted to point out that even in the most seemingly simple situations, it’s really easy to avoid the use of classical mechanics. But should you even if you could?

The really nice thing about classical mechanics is that the rules for movement, collision, and forces are all already laid bare before you. Even better is that these rules and observations are and have been made about real-world objects and these rules can be expressed mathematically (thus you’re translation point into software). At that point, it’s nothing more than to write a utility class or a series of methods that parameterize those expressions and make arbitrary calls to them in code as needed.

Ignoring classical mechanics means that you’re basically left to invent your own set of rules for these behaviors. Not only would that mean that things would probably not do what a player would expect them to do, but it makes a significant amount of work for a developer.

One particular point of difficulty for developers looking to migrate to using classical mechanics would be the change in understanding of objects in the game world. You can no longer look at your objects and entities as mere rectangles and circles with dimensions based in pixels. Now you have to start thinking about how these objects relate to real-world counterparts. Gravity now comes into play thus properties like mass, density, volume, etc.. are all now factors. It’s not enough to simply say “the user pressed this key so now I call this method to do a transformation to make the player move from here to here”. Now it’s more or less along the lines of “the user pressed this key so based on the current factors like gravity, applied friction of the area they’re standing on, if the wind is blowing or not and how fast, how fast can they move in the direction requested and move them accordingly”.

It all comes with the territory transition though.

A really simple but fun exercise for this transition would be to try and write a Pong clone implementing as much of classical mechanics as possible. It’d be fun to discuss this so I think I might try to do so soon.