Monday, September 9, 2013

Setting up Ubuntu 12.04 for flash development

In this post I will outline how to setup a clean Ubuntu 12.04 machine for flash development. This should work on both x64 and x86 distributions (I've only tested it on 12.04 x64 and 12.10 x86). It will probably also work on other Ubuntu versions as well.


Run the commands below to download and run the setup script.

source ~/.bashrc
Run the commands below to download and run the script that fetches/compiles/runs @AdamAtomic's EZPlatformer flixel demo game:

Script Source

Below is the full list of commands that will get you set up ( Be sure to source ~/.bashrc after it runs:

# Script made by @narlynephi (
# This script will setup Ubuntu for flash development by:
# 1 - download/install normal and debugger flash projectors
# 2 - download/install flex 4.6 sdk (and fcsh-wrap)
# 3 - install dependencies
# 4 - add flash projectors and flex sdk binaries to PATH

mkdir -p /tmp/flash_setup/players
cd /tmp/flash_setup/players

# download/install flash projectors (normal and debug) to /opt/flash/11
for file in *.gz ; do tar -xzvf $file ; done
sudo mkdir -p /opt/flash/11
sudo mv flashplayerdebugger /opt/flash/11
sudo mv install_flash_player_linux_sa/flashplayer /opt/flash/11

# download/install the flex sdk to /opt/flex
cd /tmp/flash_setup
sudo mkdir -p /opt/flex
sudo unzip -d /opt/flex
sudo chmod -R a+rx /opt/flex

# fetch fcsh-wrap and stash in /opt/flex/bin
chmod 755 fcsh-wrap
sudo mv fcsh-wrap /opt/flex/bin

# make sure package lists are up-to-date
sudo apt-get update

# needed to run mxmlc and other tools in /opt/flex/bin
sudo apt-get install -y openjdk-7-jre

# needed to be able to run flashplayer and flashplayerdebugger if running an x64 system
sudo apt-get install -y libc6-i386

# needed to resolve error:
#     ./flashplayer: error while loading shared libraries:
# cannot open shared object file:
#             No such file or directory
sudo apt-get install -y ia32-libs-gtk

# add /opt/flex/bin and /opt/flash/11 to the $PATH env var in ~/.bashrc
echo -e '\n\n#LINUX FLASH DEV\nPATH="$PATH:/opt/flash/11:/opt/flex/bin"' >> ~/.bashrc
To see something compile and run, run the script below to download, compile, and run @AdamAtomic's (creator of Flixel) EZPlatformer example game (
# Script made by @narlynephi (
# Download, compile, and run AdamAtomic's Flixel example game "EZPlatformer"

# create 
mkdir flash_test
cd flash_test

# download EZPlatformer code

# download flixel code

# unzips to flixel-master
# unzips to EZPlatformer-master

cd EZPlatformer-master

cat <<MAKEFILE_CONTENTS > makefile


CC_OPTS=-incremental=true -static-link-runtime-shared-libraries=true -default-frame-rate=60 \$(SOURCE_PATHS)





 \$(CC) \$(CC_OPTS) -output=\$(RELEASE_OUTPUT) \$(MAIN)

 mkdir -p \$(RELEASE_FOLDER)

 \$(CC) \$(CC_OPTS) -debug=true -output=\$(DEBUG_OUTPUT) \$(MAIN)

 mkdir -p \$(DEBUG_FOLDER)

 rm -rf \$(DEBUG_FOLDER)
 rm -rf \$(RELEASE_FOLDER)

 flashplayer \$(RELEASE_OUTPUT)

run_debug: \$(DEBUG_OUTPUT)
 flashplayerdebugger \$(DEBUG_OUTPUT)

# compile and run the swf
make run

Hope this helps somebody besides me and my seemingly constant need to reformat my laptop's HD.

Until next time.

Saturday, November 3, 2012

Programming by Interface

I'm currently on my second rewrite of a flash game. The first time around, I didn't plan very well (not much at all), and I ended up having to constantly restructure and reorganize the code. I'd get to a certain point, and realize "oh yeah, each weapon might make the player move differently, I can't do that currently with my code", so I'd restructure and rework things till they worked. This was happening constantly, and I got fed up with it.

To change it, I first though "I know, I need to write a design document that will detail everything that's expected of every class down to the smallest detail so that all I'll have to do is 'follow the blueprints' and code it up". So I started writing up a design document. This really helped me think things through some more and define specific boundaries to prevent feature creep, but I found it so tedious that I was wishing I was just writing code. I ended up keeping the design document at a really high level (to define the scope of the game and prevent feature creep, etc). Then I started writing interfaces.

I've never done this before, but it seemed like a good idea. "I'll just write interfaces for all of the types of classes that I think I'll need. They'll be well documented and will detail exactly what's expected out of every class." This turned out to be pretty painless. It forced me to think about how everything will interact, how ManagerX will interact with ObjectY and ObjectZ, where things will get instantiated, what each exposed function is expecting as input parameters and what it is expected to do (and what it is not expected to do).

Coding up interfaces before doing any real coding sounds tedious. It sounds really tedious. But it's not. I thought it was actually rather fun. One of the biggest benefits of doing this was that, since I was only writing the interfaces, I wasn't wasting time writing code that I knew would be changed in a few days (or hours [or minutes]).

Currently I've written and thought about all of the interfaces I've needed to start getting something working (and I do have something working :^). Now when I write the actual code, it really does feel like I'm just "following the blue prints". It makes a lot of things easier because I've already thought most things through to a pretty fine degree of detail. Of course things slipped through the cracks, and I have ended up changing some interfaces, but I think in the end, it's saved me some time.

There are two other benefits that I have really enjoyed from this approach:

  1. Documentation

    As of right now, all of the interactions between classes are nicely documented. While I've been doing this, I've realized that a lot of the bugs I've created come from false assumptions I've made about code that I've written. I've assumed that functionX adds parameterY to the stage, when it really doesn't, or that functionY doesn't initialize objectQ when it really does and it ends up being initialized twice. Having documentation in place in the interfaces keeps me from making those mistakes too often, since I reference the interfaces and the documentation instead of the source code of the classes that implement those interfaces.

  2. Code dependencies

    Since I've got an interface for all of the main types of objects that I'm expecting to use in my game, I almost never store a reference to a class, only an interface. I also never cast something from an interface back to the class I think the object is. I think that should be avoided.

    Using interfaces like this has reduced how much my code depends on everything else in my code base. I love it when I see this output from my compiler:

    (fcsh) compile 1
    Loading configuration file /home/nephi/lib/flex_sdk_4.6/frameworks/flex-config.xml
    Recompile: flashgames/Game/trunk/src/com/narlyproductions/level/
    Reason: The source file or one of the included files has been updated.
    Files changed: 1 Files affected: 0
    Debug/Game.swf (502158 bytes)

    Since the overall code dependencies have been reduced, compile times have also been drastically reduced. Honestly though, on any decent computer it doesn't take too long to compile a simple swf. However, I do most of my programming on an old laptop I got at a yard sale, and I notice the compile time speed up.
Programming my current game using this method has been fun so far. It also automatically gives me a sort of todo-list: write a class that implements interface A, write a class that implements interface B, etc. Hopefully it works out in the end as well.

Until next time

Flash Development

Recently I've switched to programming in Flash. Creating Flex applications used to be my main responsibility at an old job, so programming in Actionscript 3 again was kind of like visiting a rusty old friend I hadn't seen in a really long time (everyone has rusty friends). I had to do some catching up with my friend, learn what's new, etc. It turns out we're still friends :^)

Why did I want to start making games in flash? Let me back peddle a bit and say that used to want to make games for iPhones, iPads, etc. I was using Marmalade, and was having fun doing it.
I was able to develop everything on my Windows 7 desktop. I would have just had to borrow a friend's MacBook to publish it to the AppStore (never got to that point, but that's how it seemed like things would work). Hehe, the big problem though was that I don't own a smart phone or anything close to a mobile "smart" device, unless you count putting my desktop in a backpack with a battery, strapping my 24" monitor to my wrist, putting my mouse in my pocket, and tying my keyboard to my chest. My phone is nowhere near "smart", and I kind of like it that way for now: it's cheaper, and it's easier for me to disconnect and spend time with my family.

The second problem I had with developing games for the AppStore was that it costs money. I know, I know, it's not that expensive, I should be able to make it all back if it's a good game, blah blah blah. Frankly though, I'm a penny pincher in general, and I didn't feel like paying money up front to use an SDK and other fees to get a game into the AppStore. It also bothered me that I'd have to borrow a friend's MacBook to get it into the store, and that any games I made would be incompatible with my non-existent top-of-the-line smart phone (sadly). I would love to play some games on my non-existent smart phone though.

I don't remember what caused me to think about making games in flash. I think somebody mentioned it on Twitter, and I looked into it. I always wondered if and how people make money off of flash games. From what I've read and heard, it seems possible (note: this post isn't a "How to make money making flash games"). Not only does it seem possible, it can be done entirely FOR FREE, which really appeals to me. I can use an existing skill set that I've already developed. I can even program my games using on Linux using the open source flex sdk (AWESOME). So I dropped what I was doing with Marmalade, and switched to developing flash games.

I'm currently using Flixel and trying to keep my first flash game pretty simple. It's waaay too easy for me to keep expanding on ideas and to keep coming up with new ones faster than I can program even the basic ones. I'm not a bad programmer though. I consider myself to be quite adept and proficient. I't just my crazy brain is always coming up with new ideas for my current project (or even worse: new projects), even when I tell it to stop and JUST FINISH MAKING THE GAME, even if it's not "perfect" or "everything that it could be". For my first one, I just want to keep it simple and get it done. If people like it I'll revisit it and expand on it (or so I keep telling myself). Flixel is fun though. One day (here goes my brain again) I'll probably end up making my own flash game framework. It'll be awesome :^)

It's been fun working with my old friend Flash again. It's been especially fun since I've gotten everything working on my Ubuntu laptop. I'm using the Flex SDK, vim, and GIMP, as well as a sprite editing plugin I wrote for GIMP (Narly Sprite).

Soon I plan on posting about the progress I'm making on my current game. Until next time.

Thursday, September 6, 2012

Foray Into Entity Systems II

Since my last post, I've implemented more systems with my entity system framework. I've added a health system, a model rendering system, and a physics system. Below is short video showing the pieces in action:

By the way, Marmalade 6.1 rocks! Besides adding full-screen support for Windows and Mac, the new floating point rendering pipeline is awesome. No more using IW_FIXED* everywhere. Things seem to be running a lot smoother and faster as well.

A little description about the video:

Each enemy (green triangle) has the following components:
  • billboard
  • transform (matrix+position)
  • velocity
  • box2d
  • health
  • damage
  • enemy
The ship (player) has the following components:
  • model
  • transform (matrix+position)
  • velocity
  • health
  • box2d
Entity systems include:
  • billboard rendering system
  • model rendering system
  • box2d system
  • camera system
  • boundary system (removes entities once they go out of bounds)
  • enemy spawn system
  • enemy movement system (keeps the enemies bouncing between the walls)
  • ship control system (catches user input to control the ship)
  • health system (removes enemies when their health is 0)
The biggest surprise to me in this last week was how easy it was to integrate box2d or bullet or any other physics library into my entity systems (I did box2d and bullet very easily). Not only was it easy to integrate, it's also easy to swap one physics library for another.

One of the other really nice things about using a physics library in my entity system is that it gets rid of the problem of removing or modifying physics bodies during a collision callback. This is a common thing I've seen physics libraries tell you not to do. My entity system takes care of this by queuing up entities that are to be removed (something I got from reading the Artermis source). These entities are then removed during the normal processing loop.

For example, suppose an enemy in the video above gets hit. This callback will get called:

void EnemyCollision(Entity *thisEnemy, ges::Entity *other) {
 Damage *dmg = other->GetComponent<Damage>();
 if(dmg) {
  Health *thisHealth = thisEnemy->GetComponent<Health>();

Later, when the health system is told to process its entities, it would tell the entity world to remove any entities that are dead:

void HealthSystem::Process(Entity *entity) {
 Health *health = entity->GetComponent<Health>();
 if(health->IsDead()) {

Since the entity world processes entities like so:

void World::Process() {



 SystemNode *curr = m_Systems.GetFirst();
 while(curr) {
  System *system = curr->GetValue();
  if(!system->IsPassive()) {
  curr = curr->GetNext();

any entities that need to be removed from the entity world will be queued up and removed during the next call to World::Process.

Next up on the list is to make a particle/fx system. It should be pretty simple since the billboard rendering system is almost what I would consider a particle system anyways.

Until next time.

Thursday, August 30, 2012

Foray into Entity Systems

I used to always setup game/graphics code using an object oriented approach that went something like this:

class GameObject {

class StageObject: public GameObject {
 Matrix m_Transform;
 Vector m_Velocity;

class 3dObject: public StageObject {
 Model m_Model;

I got tired of doing it this way, and thought there must be better methods out there.

I started searching, and I eventually ran across a post by Adam on called Entity Systems are the future of MMOG development. This post (and the other five or so following posts Adam did) really appealed to me. His arguments for using entity systems as opposed to a strictly OOP approach for game engines were the exact same reasons why I was getting tired of the OOP method.

I'm a big fan of using the right or most appropriate data structures and design patterns to solve problems. Sometimes I get myself into a bind because I always want to code everything up from scratch just to make something specific to my current problem, but it usually turns out faster and more efficient (even if they aren't better, I learned something by reinventing the wheel).

After studying Adam's posts, I wrote my own entity system. Reading the source to the Artemis Entity System Framework helped me solidify a lot of the entity system concepts. My code ended up being similar to the Artemis framework, excluding the fact that Artemis is written in Java and mine is a C++ library.

Below is a video of a quick test using my entity system:

The code for setting up the world in my entity system goes something like this:

World *world = new World();
world->addSystem(new MovementSystem());
world->addSystem(new EnemyMovementSystem());
world->addSystem(new EnemySpawnSystem(/*params*/));
world->addSystem(new BoundarySystem(/*params*/));
world->addSystem(new CameraSystem());
// etc

while(true) {
 uint64 deltaT = CalcDeltaT();

Each of the systems added to the world defines which components it requires in an entity. As entities are created, changed, or removed, each system is notified of the event. If the event makes the entity meet a system's requirements for processing it (if it has the right components), that entity will be added to the matching system's entity list.

For example, below is how the MovementSystem works. You might notice that I borrowed some terminology and other patterns from the Artemis framework - it's hard to call a construct something else after you've seen it called a name that already seems to fit:

class MovementSystem: System {
 MovementSystem(): public System(new Aspect(
    (1 << Transform3d::s_TypeId) |
    (1 << Velocity3d::s_TypeId)
   )) {


 void Process(Entity *entity) {
  Transform3d *trans = entity->GetComponent<Transform3d>();
  Velocity3d *vel = entity->GetComponent<Velocity3d>();
  uint64 deltaT = m_World->GetDeltaT();

  trans->pos += vel->m_Vector * deltaT;

Creating new classes of entities (not the OOP class, I mean an entity with a specific set or configuration of components) is also very straightforward. Spawning a new enemy in my example goes something like this:

Entity *CreateEnemy(World *world) {
 Entity *enemy = world->CreateEntity();

 enemy->addComponent(new Billboard(/*params*/));
 enemy->addComponent(new Transform3d(/*params*/));
 enemy->addComponent(new Velocity3d(/*params*/));
 enemy->addComponent(new Enemy());

 return enemy;

Pretty simple, huh? I love the flexibility this design pattern provides. If I want to, say, suddenly make the camera look from the perspective of an entity, all I'd have to do is add the camera component to the entity and mark it as being the active camera. Pretty simple! I should probably add another video demonstrating the flexibility that entity systems provide you with. Maybe I will, but I think the concepts are pretty simple to grasp.

Hopefully this little writeup has been an easy and informative read. Until next time.

Wednesday, August 15, 2012


I current label myself generally as a programmer, although I like to think of myself as more of a creator or a constructor. All of my favorite jobs and hobbies have had a creative element as the focus, be that as a construction worker, a web developer, an infosec professional, a lawn mower, or a game programmer. For me, this is a requirement in any job or hobby that I take on.

I am interested in a lot things: I find the AI field particularly interesting, programming design patterns are fascinating, the ingenuity in different code optimizations blows my mind, 3D modelling is insanely fun, fluid particle simulation methods/algorithms are intense, procedural content generation is awesome, oh, and did I mention optimization techniques? The list goes on (yes, I do have other interests besides those listed above: those are just programming/game-dev related interests).

This blog is to be a landing place for my thoughts in the fields of interest that I previously mentioned. I might post some things about roadblocks that I've overcome in specific projects that I'm currently working on, or I might show off something cool I modeled in blender, or maybe if you're lucky you'll see a few postmortems.

Overall, I hope you'll find this blog an interesting source of information, whether you agree with my techniques and opinions or not. I find that I am the one to usually get the most out of formalizing my thoughts and writing them down than any of my readers do.

Until next time.