Nicolás Miari

Developing a Game Engine Part III: Stage Structure

Fri, 18 Aug 2017 01:53:00 +0000

(Read Part 2 here.)

What’s in a Stage

So far we’ve talked about how stages are linked together and how to get from one to another. However, we still don’t know what the actual stages look like internally; let’s think about it now.

Substructure

At first glance, it feels as if each stage is just a tile map with objects in it. These include collectible objects (gems, coins, inventory items, etc.), traps, triggers (including exits), NPCs, etc. each placed at a specific location of the map grid. But we can do better than this.

In some 2D platformers, action within a stage isn’t just continuous scrolling along a large map: sometimes the player goes through a “door” that leads to a different “room”, typically immediately. Sort of like linking between stages, but within the same stage, and perhaps you can traverse the door back in the direction you came from (but not always: think trapdoors). The goal is to make the stage experience richer by providing different sub-environments, perhaps each with its own mood: a unique visual style, or eve a different BGM altogether.

So, a stage is (again), a (possibly directed) network of tile maps. This generalizes the notion of a gate into a trigger that leads to a specific location on another map, possibly in a different stage.

Coming next: Part 4.

Developing a Game Engine Part II: Stage Architecture

Thu, 17 Aug 2017 01:53:00 +0000

(Read Part 1 here.)

Stages

So I set to develop a game engine so generic that, just by providing custom graphic and sound assets, and tweaking a few settings here and there, it could produce the working code for any game I want.

This means that I need to isolate the most general structure shared by all the games I expect to develop (i.e., 2D action/puzzle platformers), and work my way from there.

Let’s take a moment and think what that is.

First, a basic 2D platformer consists of a series of stages. You start at stage 1 and proceed until you find the exit, which leads to stage 2. Once you complete all stages, you have finished the game.

But is that the most general structure possible? Definitely not: some games have a “world map” connecting several “village” stages. With exceptions -typically dictated by game progress- you can get to any stage from the world map. Once you enter a stage, some games let you “return to map” at any moment (typically from the “pause” menu), while others force you to complete the current stage first. And even if the game is “linear” as in the previous paragraph, the condition to complete a stage can be anything from finding an exit, to defeating a boss, or collecting a certain amount of items.

So, a game is not a series of stages: it is more of a (potentially directed) network. In games that include a “world map”, the map itself is also a stage (with very different rules from the “village” stages). There’s even the possibility that there are multiple world maps, linked by (for example) bridges that become accessible partway through the game, etc.

Gates

Each stage can be entered and exited somehow. For this, we need portals or gates. A gate is an object placed somewhere within a stage. It can work as either an entrance or an exit. When an exit is entered by the player character, it transports it to a specific entrance of another stage! That is, each exit gate leads to an entrance gate in some stage (entrance stages do nothing when entered: they are mere “starting points” for game play on that stage).

Each stage can have more than one exit: think of the world map we described earlier. But it can also have more than one entrance: Each particular “village” stage, when completed, takes the player character back to the world map, at the location of the village’s entrance!

Cut Scenes

We can generalize the concept of the stage further: What about the “cut scenes”? You know, those animations that typically happen in between (sometimes within) stages, to advance the story? Those can be though of as special cases of stages too. The inter-stage cut scenes are just stages where there is no user input and all the characters are scripted! Of course, scripting and temporary cancellation of user input can also happen temporarily within a ‘regular’ stage, perhaps triggered by some action of one of the characters (e.g., stepping on a trap).

Triggers

This bring us to the concept of triggers, which are nothing more than a generalization of the exit gates we talked about earlier. A trigger is basically a location on a stage (a single tile or a group af adjascent tiles, if it needs to be larger) that, when entered, causes some predetermined action to happen. The action can be:

Teleport the player character (and thus, advance the game) to a specific location (entrance) of a specific stage,
Run a script that causes change and/or programmed motion in one or more characters or map objects (optionally, disabling user input while at it)

etc.

Coming next: Part 3.

Developing a Game Engine Part II: Stage Architecture

Thu, 17 Aug 2017 01:53:00 +0000

(Read Part 1 here.)

Stages

This means that I need to isolate the most general structure shared by all the games I expect to develop (i.e., 2D action/puzzle platformers), and work my way from there.

Let’s take a moment and think what that is.

Gates

Cut Scenes

Triggers

Teleport the player character (and thus, advance the game) to a specific location (entrance) of a specific stage,
Run a script that causes change and/or programmed motion in one or more characters or map objects (optionally, disabling user input while at it)

etc.

Coming next: Part 3.

Developing a Game Engine, Part I: The Genesis

Wed, 16 Aug 2017 01:53:00 +0000

Background

In 2011 I was working at a small shop that specializes in content creation and manangement of their own IP assets. At some point I was given an incredible amount of creative freedom and set to develop my own idea of a 2D game.

I had my own sprite library I had been polishing since 2010 and soon found out that I also needed I tilemap editor (I didn’t want to use an existing tool: in line with my ideology of creating my own sprite library from scratch, I wanted a custom tilemap engine that was compatible with it).

It worked but it was buggy and feature limitted; I could live with it for the short period of time it took to develop the nine stages of the very simple game, but it was too much to ask other people to use it (or even myself, in the long run).

The game didn’t do well, but after I left the job the good folks at the company ceded the rights to the app to me (it was my brainchild after all: not just the code but the whole idea and visual design too. Also, it wasn’t IP good enough that they could monetize. I’m not the guy who invented Pokémon or anything). In the end, the custom sound library I was using broke with one of the iOS updates (it seemed to rely on a bug that got fixed, apparently!) and I removed it from sale.

I promised to myself that I would recreate the map editor from scratch, one day, update my game with support for modern devices, re-release it, and move on to develop further games.

I have been trying since, but at each turn I found myself facing design that I could not solve. I wanted my map editor to have the capability of “testing” and tuning each map in real time, during development (without having to export it and import into the game project each time), but on the other hand I didn’t want the editor to know too much about the game in order to keep it generic and versatile.

The Turning Point

Last night I couldn’t sleep and set to think about what I’m rally trying to do with my (stagnant) personal project. I decided to change my mentality and develop a full-fledged game editor.

A game-agnostic map editor that can also “test run” the maps being created is an impossibility. Instead, I will draw some very generic constraints of what constitutes a tilemap-based game, and design my game editor around that. It will be basically a game template with lots of options to configure.

The bonus is that most of the logic will be coded once, into the engine framework, and each particular game I develop after that will consist of custom assets and settings of the engine. Kind of like Unity3d or Unreal Engine, but tailored to my own goals.

Next: Part 2.

DinnerJacket.framework

Tue, 11 Oct 2016 10:33:00 +0000

There’s recently a trend to give open source libraries and frameworks fancy names that have nothing to do with the software’s functionality; for example: Alamofire, Freddy¹, and Starscream (to name a few ones that are prominent in the “cocoasphere”).

I started developing my very own sprite library for iOS back in 2010, and although I do not work on it very often, I keep improving it and over the years and it has gone through several incarnations (and names).

Back then, I had just finished my first iPhone game ², using the (then popular) open source library known as Cocos2d-iPhone. The game was a simple 3D puzzler, but the 3D requirements were so minimal that I just needed to write some custom OpenGL ES 1.1 code on top of the library’s existing functionality (unlike SpriteKit, cocos-2d iPhone provides direct access to the OpenGL ES layer for performing custom drawing other than 2D sprites).

Cocos2d is a great library and very easy to use; but there were a few things that bugged me about it. At that moment, Apple and other smartphone manufacturers were transitioning to GPUs with a programmable pipeline (i.e., shaders), but the current version of Cocos2d was stuck in the older, fixed-pipeline version of OpenGL ES (1.1). Although the geometry of my game was minimal, I still wanted to be able to experiment with fancy visual effects in order to enhance the player’s experience. The programmable pipeline-ready 2.0 API was there for anyone to use, but the people developing Cocos2d just hadn’t had time to make the transition yet.

Secondly, even though I am a computer graphics major, back then the last graphics programming I had done was learning some Direct Draw at a previous job, and before that, immediate-mode desktop OpenGL in the early 00’s at college. In the constantly evolving mobile arena of modern times, I really felt left behind. I needed to learn the present-day graphics programming idioms and techniques.

Finally, it was somebody else’s code. I am not an advocate of reinventing the wheel every time (especially when the available options are so plenty and so good), but there are exceptions.

In this particular case, I felt I would rather be someone with enough technical skills to build his own sprite library from scratch, than just another programmer who knows how to use somebody else’s library.

Fast forward to today, and iOS has made great strides. OpenGL ES, as of version 3.0, has converged closer towards its desktop counterpart. And regarding my “library”, what used to be a folder with source files copied and pasted from one project to another (and all the version control madness that entails), is now a dynamic framework whose source code I can keep in one place.

Following the trend mentioned at the beginning of the article, I have re-christened the code base to Dinner Jacket. The name merely reflects something that I like (evening dress), and has absolutely nothing to do with the library’s capabilities.

Although the days of OpenGL (and Objective-C) seem to be numbered, I owe to my library a big, final update to modern standards before I move on to other projects. Also, there is a small trail of games I developed mostly in my spare time, over the years, that broke on way or another on subsequent OS updates and I was forced to pull from the AppStore. I owe those games a remake and a relaunch.

But after that is done, I will port the framework to the Metal API, and at the same time rewrite it in Swift.

Update (2017 Oct 11)

I have officially abandoned development of DinnerJacket and moved to my next project library, redesigned from scratch with Swift and Metal in mind (some design ideas were inherited, though). The new project is still private, but I will be writing blog posts on its design and architexture.

In the mean time, DinnerJacket is now open source and the (first and) final release is available on GitHub, for reference and demonstration purposes.

To be fair, this one is sort of a pun. ↩
As is usually the case with someone who can not make time to keep his personal projects up to date, it is currently removed from sale until I can modernize it. ↩

Icon Set Creator

Tue, 15 Mar 2016 08:00:00 +0000

Thank you to the 14k+ people who downloaded Icon Set Creator since its initial release on January, 2015!

I have just submitted the latest version (1.1.2) to the Mac App Store for review. New features include:

Bug fixes
iPad Pro App Icon support
Dark mode!

Stay tuned for the imminent release.

Serializing Asynchronous Operations Using Closures and Private Functions

Fri, 11 Mar 2016 11:38:00 +0000

Sometimes you need to perform an asynchronous task, like downloading a file. In swift, closures come in very handy to perform some operation once the asynchronous task completes. For example:

func downloadFile(fromURL url:NSURL, completion:((error:NSError?)->()))
{
    MyHTTPLibrary.sendHTTPRequest({ response in
    
        if response.statusCode == 200 {
            // SUCCESS
            completion(error:nil)
        }
        else{
            // FAILURE:
            completion(error: response.error!)
        }
    })
}

And some other times, you need to perform a lot of asynchronous tasks (like

for example- downloading a lot of files). We could expand the previous code with a for loop, like this:

func downloadFiles(fromURLs urls:[NSURL], completion:((error:NSError?)->())) { for url in urls { self.downloadFile(fromURL:url, completion:{ error in if error != nil { completion(error:error) break }
```
          if url == urls.lastObject(){
              completion(error:nil)
          }
      })
  }   }
```

This will loop through all the URLs and send an asynchronous request for each. The problem is, all the requests are sent almost at the same time: Most likely, you will finish sending the last request before you get the first response. Moreover, we have setup our success trigger (completion(error:nil)) at the end of the completion handler of the last request. This assumes that the last request will complete last: a race condition.

A better design requires that we serialize (or enqueue) all our requests, so that they are performed one at a time. This way, no matter how long each request takes, we can be sure that request number N+1 is sent only after we received a response to request number N. Also, we don’t need to worry about our HTTP library having to deal with too many concurrent connections.

In a delegate-based scenario, we would have a mutable array of connection tasks serving as a queue, and dequeue them one by one on the delegate method that is called on completion, to start the new task.

But with colsures, we have all our code on-site (no separate methods), so at first it is not clear how to “serialize” all our downloads. However, with a clever trick we can accomplish this:

func downloadFiles(fromURLs urls:[NSURL], completion:((error:NSError?)->()))
{
    // [1] Define recursion:

    var mutableURLs = urls

    func downloadNext() 
    {
        if mutableURLs.count == 0 {
            // Terminating condition
            return completion(error:nil)
        }

        let url = urls.removeFirst()

        self.downloadFile(fromURL:url, completion:{error in 
            guard error == nil else {
                // Failure; abort:
                completion(error:error)
                return
            }

            // Success; recurse:
            donwloadNext()
        })
    }


    // [2] Kickstart recursion :

    donwloadNext()
}

The code runs as follows:

We make a mutable copy of the URL array.
Call downloadNext() for the first time: the array is not empty. We remove first URL and send an asynchronous request to it.
Return from downloadNext() right away.
Return from downloadFiles() right away.
…
On request completion, downloadNext() calls itself -this time, with the diminished URL array- and the cycle goes on, until the array is empty and downloadNext() bails out to success.

All in all, downloadNext() is called N+1 times to perform N requests (the last time finds the URL array emoty and bails out).

Hello World!

Tue, 01 Dec 2015 05:47:37 +0000

This is my first post using Jekyll/markdown.

This is a link to my Stack Overflow profile.

(You can download that image directly.)

Welcome to Jekyll!

Tue, 01 Dec 2015 05:47:37 +0000

You’ll find this post in your _posts directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run jekyll serve, which launches a web server and auto-regenerates your site when a file is updated.

To add new posts, simply add a file in the _posts directory that follows the convention YYYY-MM-DD-name-of-post.ext and includes the necessary front matter. Take a look at the source for this post to get an idea about how it works.

Jekyll also offers powerful support for code snippets:

def print_hi(name)
  puts "Hi, #{name}"
end
print_hi('Tom')
#=> prints 'Hi, Tom' to STDOUT.

Check out the Jekyll docs for more info on how to get the most out of Jekyll. File all bugs/feature requests at Jekyll’s GitHub repo. If you have questions, you can ask them on Jekyll Talk.

Nicolás Miari

Developing a Game Engine Part III: Stage Structure

What’s in a Stage

Substructure

Contents

Developing a Game Engine Part II: Stage Architecture

Stages

Gates

Cut Scenes

Triggers

Developing a Game Engine Part II: Stage Architecture

Stages

Gates

Cut Scenes

Triggers

Developing a Game Engine, Part I: The Genesis

Background

The Turning Point

DinnerJacket.framework

Update (2017 Oct 11)

Icon Set Creator

Serializing Asynchronous Operations Using Closures and Private Functions

Hello World!

Welcome to Jekyll!