As I mentioned in my Conditioning Script post, the next step in comfortably dealing with numeric IDs as replacements for strings was a reverse lookup being built so that the initial input that generated those IDs can be retrieved. At the Highest Level It’s a pretty simple lookup table mapping IDs to strings. In C/C++ one might imagine all of the wonderful memory fragmentation that would occur. One might even start down a path of blocking out a chunk of memory and using a stack allocator or similar to store the strings.

Saturn Cutting is a space action adventure for PC. Side-scrolling Metroidvania. Saturn Cutting is still very much in development. It uses an engine that I’ve been working on since roughly 2010. (FWIW I wouldn’t recommend doing that if you want to get a game made, but it’s been interesting.) For the time being this will be the place to get new information on how things are going.

My engine relies on hashed strings as identifiers, uh, a lot more than is probably appropriate. I know that I’ve worked with engineers that would be utterly furious with me for that. Actually a lot more than just that because engineers are sort of notoriously catty, but I meant more specifically about all of the string hashing. Hashing all of these strings every frame, especially through the scripting layer in Lua, seemed deeply unnecessary.

Testing your game on a large screen or TV, with a controller, from your couch or similar, will help you get a whole new perspective. This, of course, assumes that that’s anything remotely approximating how one might play your game, but helpful none the less. Steam Link Steam Link is a special purposed Linux device with additional video decoding hardware. Once you’ve begun streaming from your PC, anything on the screen will be streamed to your TV.

Further time with the API has led me to some realizations regarding the game controller API. It’s just as useful as I had initially thought, but geared towards solving a slightly different problem than I had assumed. Largely because I wasn’t paying enough attention. Once More Unto the Breach Alright kids, you get all buckled up, because this is, obviously, going to be super exciting to read about. It may change you.

In games, and arguably many other areas where the user is presented with graphical input, the end result of nearly everything equates to animation. Not to be confused with the discipline of animation, i.e. rigging models, curves, anticipatory behaviors, etc., but just, generally, “Animation”. A series of images are created and displayed at a fast enough rate that it looks to our eyes like motion. Our eyes observe the little blobs of pixels and identify shapes, and infer all manner of data that it relays to the rest of the brain like weight, momentum, and surface characteristics.

Look, alright? We all know that you log things out of your games, utilities, and applications. Stdout or files are the norm … So you’ve likely spent a good deal of time staring at a terminal window or some log file from an application you’re making. You’ve got yourself a nice little suite of applications and tools all outputting to separate windows, files, uh, emails, maybe? If only there were some sort of standardized way of delivering, storing, and aggregating messages into log files, am I right?

LuaJIT, which by itself is damned incredible, provides an interface called FFI that allows for directly interacting with C functions and structers. I’ve mentioned it before in my post about my particle language. The FFI library allows calling external C functions and using C data structures from pure Lua code, obviating the need for explicit bindings that use the Lua stack, etc. It parses plain C declarations! Mostly! LuaJIT’s site Data Structure Aside from the obvious interacting with libraries or your internal systems, FFI can be super convenient for working with structures.

SDL2 brought with it a new API for interacting with game controllers such as the Xbox 360 controller (which I’ve heard tell is the most widely used and supported controller for PC gaming). The documentation is a little light, so here’s a quick and dirty tutorial and a few notes on it. The Purpose Mapping joystick buttons and axises to inputs in your game is deceptively complicated. It generally requires several layers of mapping in order to provide the flexibility users will need in order to hookup up various devices.

The vast majority of paricle system implementations are authored with certain assumptions in place. Particles will have a lifetime and be expired after it, all points will be rendered as camera facing quads, all attributes will be animated across lifetime, etc. I started to view these things as simply channels of data and small “Programs” that modify them. TL;DR; I made a particle system engine which utilizes a domain specific language (DSL) for defining the data layout and the modifications to be run against that data on each simulation step.

There are some basic pitfalls in our profession, in our art, that I’d like to call out. Much like musicians or visual artists that fall into old patterns or, similarly, attempt to be different for the sake of being different, software engineers often deal in convenient speech and comfortable habits. I offer the Singleton Pattern as an illustration. Global State Nearly any rudimentary book on program will take up the ageless wisdom of “GOTO considered harmful” and “Global variables are bad”.

Recently I got around to actually experimenting with Google Protocol Buffers (protobufs). The experiment didn’t take long, is over, and now I will put protobufs into anything you let me… on the serious. I will throw out the 90% of your data file processing code that you don’t actually need and go right to Protobufs Town. The Basics: Protobufs work by way of code generation. A proto file defines the various data types you will be creating (i.

While this could certainly apply to my update schedule on the blog, that’s not what’s on my mind at the moment. In the engine I’m working on in my free time, have no been bitten twice by middleware that use a lazy approach to positional updates. In my case it was the underlying rendering engine that I used as a starting point (Horde3D) and an otherwise excellent UI system (libRocket). In both cases the systems had structures of deep hierarchical relationships between elements, which I’ll uniformly refer to as “Nodes” here as that applies well enough.

To a certain extent any game is a simulation. It involves an environment with constraints and mechanics, sometimes nearly arbitrary rules, etc. Many of these components may be rather abstract of course, like in chess or other board games. It’s safe to say that somewhere in there you are simulating something in your game. The tricky bit is identifying what it is you are intending to simulate and to what end.

Fairly recently I came across http://prideout.net/blog/?p=1 covering using Lua as an effects file format. It made me realize some things that sort of made me feel like an ass; chief among them that JSON as a format is actually just valid Javascript that results in a hierarchical structure of arrays/tables/whatever. So yeah, apparently I’m sort of slow on the uptake as I’m now aware that that’s the whole point of JSON.

I’ve been thinking about the interview process recently. I’ve been on many interviews over the years in a number of disciplines and the software engineering ones have been the worst by far. There’s something of a prevailing attitude and approach to the process that interviewers seem to not be able to help but engage. One of esoteric and specific questions designed to really make sure that you “Know your stuff”™; almost designed to make you feel like an ass unless you have, off-hand, an encyclopedic memory of anything and everything programming related.

You very well have a notebook filled with game ideas. Stranger things have happened, certainly. Sometimes you have a pet idea that you keep telling your friends and colleagues about (an idea which they are likely tired of hearing you talk about). One of mine has been “Reverse tower defense”. I should probably make it clear that I don’t think I’m brilliant or anything like that for merely adding the word “Reverse” in front of a well known game design paradigm.

I have spent the duration of my adolescent and adult life (lives?) programming many different things with many different results. I’ve tried planning out everything. I’ve tried not planning at all. Often the results are not all that dissimilar in terms of the number of issues that arise. Surely you need some planning; that’s not what I’m talking about. I’m referring more to the fact that only liars will tell you that they’re right all the time, or that the path they’re on can’t turn out to be the wrong path.

Your AI agents have data that they need to store and reason about. This could be as simple as having data members sprinkled throughout your classes/components. While this gets the job done, it can quickly get messy when you’re wanting to view these values or serialize them to disk, pass them around, etc. To that end, creating a data structure to store agent information (i.e. per agent) has a nice value add.

When developing any system, the temptation to generalize that system for maximum reuse and application, can be very, very strong. In most cases however, you had set out to develop a far more specific task and this added work is of a questionable sort of utility. That being said, game development, and really realtime application development in general, is an exercise in highly constrained and complex interactions between many systems. This means that if you fail to focus your efforts, fail to really address the needs of the application or game you’re building, you’ll be spending what could easily turn into an eternity developing and refactoring those systems.

I’m constantly surprised by how many developers or people peripherally involved in the development process et al freeze up when presented with a basic diff format.This format has been the lifeblood of the development world for many years. Your SCM uses it and likely can generate a list of changes between arbitrary versions, you can email them, you can post them, you can wire up a ticketing system into your SCM and read diffs corresponding to specific commits/changesets via a web interface with syntax highlighting… and in that final case, barring color blindness, if you can’t figure out what the red text is as compared to the green text just quit your job and find something to which you are better suited.