Today I’ve started writing some ActionScript, and I’ve been attempting to make sense of the best way moving forward to write and build AS using my new text editor, Sublime. I thought this might be helpful for other people who may want to do something similar.

So first off, this article will get you compiling using mxmlc in Sublime.

But this is slow. GLACIALLY slow. Additionally it needs a line_regex (which I’ve added in the comments) so that you can press F4 and be taken to the error. The best way moving forward is to use something that supports the compiler’s ‘incremental compilation’ feature, and pipe that output to sublime.

So what is incremental compilation? Essentially this is a configuration of the compiler where the compiled objects are kept in memory, and the compiler only re-compiles items that have been modified. Adobe has kindly provided us with a command line utility called Flex Compiler Shell (fcsh) which you can use in a terminal. But this is an interactive utility, and doesn’t really play happily with much of anything, except a human being typing stuff in it. Or…screen.

Enter ‘fcshctl‘, a couple command line scripts that ‘maintain’ a running fcsh instance in a screen session. When you first use fcshctl, it will create an fcsh session inside a screen session. When you issue commands to it, it will attach a logfile to the screen, execute the command, and upon completion of execution, output the logfile to stdout.

The upshot of this is that you can do your compile in Sublime using fcshctl, which is significantly faster, and then Sublime gets the compiler output which it can then regex and parse into errors which can be navigated via F4 or double-click. Please note: due to the limitations of Sublime’s build system, I still do a lot of things outside of Sublime in my workflow. These could most likely be added to some kind of python-based system in the future.

When compiling, the build window below displays the output from fcsh.

Clicking on an error (or pressing F4) will navigate to erros.

Prerequisites:

• A bit of unix command line comfortability.
• This zip file. It includes a functional fcshctl, an example swf build config, and the sublime-build file.
• The Flex SDK.
• This works on OS X. I’d imagine it should work on Linux. Definitely not Windows. But they have FlashDevelop.

Installation:

• Download the above files.
• Unzip the Flex SDK somewhere. I keep my copies in ~/Library and symlink the latest version to ~/Library/Flex4.
• Next put the fcshctl script somewhere. I put mine in ~/bin. Set your FLEX_HOME var inside the file, example:

• Finally put the sublime-build script in your Sublime Users folder. You’ll need to hardcode the location of fcshctl in this file like so:

Usage:

I’ll usually create a simple shell script for initializing the build. An example is included in the zip.

Execute this on the command line to initialize the code:

After executing, if things went ok, you’ll see the output saying you’ve built a swf:

After this, you can press F7 in sublime to build. It should happen quite quickly. And that’s all there really is to it.

Caveats

This is not a replacement for a real build system. You should most likely be using Ant and Hudson. The only reason I use this is to quickly execute builds, and those seconds add up. But having a build system that will execute an Ant build upon commit should be the method used to create your final deliverable.

Multiple builds at the same time wil require additional sublime builds that run compile 2 etc. I’ve found that frequently I’m only building one item, so this limitation is not an issue for me.

Conclusion

If you’re wanting to do some serious ActionScript development you’re going to want to speed up compilation and provide Sublime with access to its output. While the method detailed here is kind of complicated, it works well, and I have yet to find a better solution to  AS3 dev in Sublime. Hopefully this will help others who enjoy working in Sublime to work faster and smarter!

I have this conversation in my head about how the Rovio guys came up with Angry Birds Space:

Mighty Eagle: Man, we gotta figure out how to make another Angry Birds game. We have to milk this cash cow.

Giant Red Bird: How about Angry Birds….IN SPACE?!

Mighty Eagle: We just made Angry Birds RIO, dumbass. We can’t just change the setting…AGAIN. People might catch on.

Giant Red Bird: But Nintendo did it with Super Mario Galaxy!

Mighty Eagle: Yeah, but Super Mario Galaxy is like, the most EPIC and amazing of the Marios. The use of gravity and physics is brain-bending platforming at its finest.

Giant Red Bird: True! Too bad our game doesn’t use physics and gravity…

Mighty Eagle: You pathetic excuse for a narrative device! Don’t you see? Go read some astrophysics textbooks and modify the Box2D engine to include planetary gravity systems by using applyForce a lot. Let’s see what happens.

Giant Red Bird: w00t! I’m on it!

[UPDATE: Turns out the real conversation is much more interesting.]

If there was a 900-pound gorilla in mobile gaming, it has to be Angry Birds. And so here they are, finally making a sequel! Angry Birds Space.

It would have been easy to just take Angry Birds and put them in space. Kind of like Angry Birds Rio is just Angry Birds…but in Rio. But Rovio has taken the time to make a successor that is a real treat, and put some real thought into what’s possible.

Overall the mechanic of gravity is pretty awesome. Watching birds smash into things is gratifying in the same way the original Angry Birds is. But the added fun of them careening haphazardly around planets does make this a solid idea for a sequel.

So far the one thing I dislike is that the birds I’m shooting are small, and the change in camera system means that knowing what kind of bird you’re shooting becomes harder. The ‘triple’ bird (do these guys have names?) is so tiny that I have shot it multiple times without even knowing I could tap again to split it into three. Also I am confused on how these birds can reproduce asexually in mid-air, but I’m no ornithologist, so maybe this is possible in space. Maybe the lack of air causes some kind of Tribble-itis.

Honestly, not sure why I’m writing this review. You probably already have this on your phone. If not, go pick it up and take part of this senseless conflict!

My previous article about inheritance seemed to be well received by geeks, so I think I’ll follow up with a design pattern dear to people’s heart.

MVC

For people who know MVC, feel free to skip ahead. But watch these awesome MVC combos first:

MVC, aka Model View Controller is a design pattern that in general expects your code to conform to specific rules. I will now explain my interpretation.

• Model – A non-visual representation of the data within your application. The goal of the model is to fully abstract what you are manipulating from how you are manipulating it.
• View – The view is the entry point into the application from the user. The view displays the information to the user. The view allows the user to see the data and make requests to modify it.
• Controller – The logic behind the application. The controller initializes the model and view. It handles requests from the user to modify information.

Mistake 1: Monolithicness

In the early days of MVC, as I was trying things out, I think I viewed things very much as there being an M, C, and lots of Vs. There were Singletons. They were rebuilt from scratch on every project. But hey, I had a method, and I could explain it to others, so I thought I was moving along in this MVC direction quite well.

When you hit 1000 lines its time to start worrying. When I had a 5000 line controller, I had a problem. But that isn’t the only problem I had with One Big Controller. The other was maintaining controller state on asynchronous operations. Let’s take the following series of events:

• User clicks on item to load an image.
• Controller starts loading the image.
• Controller tells view to change to a holding pattern.
• User gets impatient, moves on to another item, and decides to load another image.

In a monolithic controller design, how do you handle this? In the past I’ve managed the loading right in the controller. That didn’t work too well, there’s a lot of state management going on. I have attempted offloading the image-loading to a processor that would return when the operation was complete. This is better, but still a lot of scaffolding.

There has to be a better way!

The hidden gem of functional controller design is a variant of the Command pattern. By creating a controller that is essentially stateless and only responding to system and user input, you can take a controller from a monolithic mess to clear, concise flows of code.

In the above example, lets assume instead that we have a specific class called RequestLoadImageCommand that responds to a request from the user to load an image. The class is instantiated and executed only when its needed by our controller. In this class:

• The command attempts to load an image
• If it loads, it tells the view its loaded.
• If it doesn’t load, it tells the view an error occured.

What happens if a user wants to load another image? The controller loads and executes another RequestLoadImageCommand. All operations are handled this way. This is a stateless controller design. This was key for me to fixing my monolithic problem.

Mistake 2: Controllers control, they don’t do.

I think controller code is not reusable. Period. Here’s my current philosophy.

Controller code is like a maestro. It waves its hands in time, points at the horns section, brings them to crescendo, then a soft diminuendo. It doesn’t play any instrument. To extend this metaphor, a program is like a symphony. When you write a new symphony, you might use the same instruments, but the notes played are different. Controller code is the notes.

Once I learned how awesome commands are, I put a lot of code in them that didn’t belong there. Why? Because I didn’t understand that you don’t mix your symphony with the piece your playing (this is where the metaphor breaks down ).

To use the simple image loading example, I could write the image loading code directly inside the command. Well, what happens if I need a different command that loads an image? In that case, I’d be duplicating the image loading code.

What I really wanted to do was to abstract out everything that was an action into a separate structure. Then I could execute, based on the current state of the application, those structures in the order they should occur, checking along the way that everything was running smoothly.

This is the heart of what a controller is.

Mistake 3: Model Controllers

Here is a comment that I wrote a while back:

// [CH] Todo: Maybe move this logic into the model?

You may laugh because you have written this code yourself at some point in time. I know I’ve had debates with people, too, who felt that model code and model logic belongs together. This is pretty common:

My answer to this is: 99% of the time this became a pain in the ass. 

This seems a pretty easy one to avoid: don’t do it. But the problem is the temptation. I’ll just put this one convenience function into the model. Team member b sees that and goes, ‘hmm, I don’t have a class to put this in, but it looks like we’re putting model utility functions in with the data. I don’t want to expend the effort of adding a class. I’ll just put it in with the model.’

And then its the APOCALYPSE I tell you.

Nah, but seriously, I’ve worked on projects where there was more controller code in the model than the controller by the end of the project. It can be hard to fix, especially in teams  where competing code styles cause things to get messy.

The Tip Of The Iceberg

Wow, I’ve done a lot of really dumb things with MVC. I haven’t even really begun. Sorry, former employers! And sorry people who inherited my codebases.

Here’s a few quick tidbits that I’ve done that you shouldn’t:

• Don’t extend view objects willy-nilly. Create view controllers that are mini-controllers.
• Use events/notifications to decouple your controller code from the views. You shouldn’t ever directly tell a view something. Dispatch an event, that way anything that wants to respond to the change in state caused by the controller can respond.
• Don’t think of your application as having just one MVC. Hierarchical cores can help, and your code re-use will be easier.
• The Command pattern isn’t always appropriate. It is extremely versatile, but often the Strategy pattern triumphs. Sometimes I need to think in terms of behaviors, not objects.

Fixing my mistakes

So is there anything that can be done to accelerate development and avoid making these mistakes? Nope. We’re all doomed to make the same mistakes forever.

The best thing I did to stop issues I had with MVC was to explore other design patterns. The importance of design patterns cannot be understated. They give you a common vocabulary with other developers. It gives you templates for solving problems. I’ve found a perceived issue with MVC can be solved by using a different design pattern.

The next important thing I did was to understand the fundamentals of PureMVC. PureMVC’s approach to MVC uses a very design-driven and well thought out approach. Its not perfect but it gives a strong foundation.

While I still consider PureMVC to be the best of the MVCs, I felt that it has specific aspects that don’t work well for game development. Specifically its Proxies were problematic, and the plumbing between cores is just a nightmare.

At about this time I began experimenting to fix these problems. And so I think that designing and implementing a few games in my own micro-architecture has been very valuable. I would recommend going out and exploring options. MVC is only a piece of a larger puzzle in any program. Solving those puzzles is part of the joy of programming.

Bing Gordon’s passions have driven him quite far. He has a keen eye for what works, and a humbleness and soft-spoken disposition that is enviable. TechCrunch had a short interview here.

What sets Bing apart for me is that he’s been able to make a business out of pioneering games. He talks about how people thought he was crazy that gaming could be a mass market. He made it happen with Electronic Arts. He then went and pioneered social games with Mark Pincus. I would recommend this old podcast from the early days of Zynga.

And now he’s talking about gamification. I have been vocal about what I thought about gamification: its a lame buzzword. Occasionally people think I might have a unique perspective about gamification. I unfortunately don’t. But Bing is a visionary who sees something there. He’s not always right, but what is it that he sees? I think its time to realign my thinking now that the gamification buzzword is not as hot as it used to be.

Its time for MORE Monster Words! There are now twice as many levels to play! Drag items around. Some of the later levels are TOUGH for more challenge.

You can grab it now on the app store!

There’s no question that Lume is gorgeous. Its all video backgrounds and everything is hand-crafted. Its like if Etsy made a video game.

I played it for a little while, and was, well, immediately stuck. I mean, almost immediately. I got the first puzzle, which I immediately thought ‘wow, that’s a bit 0 to 60′. The second puzzle was this:

 By the way, that red circle is not the answer, that’s just one of the answers I came up with. After trying this puzzle and having absolutely no clue what I was doing wrong, I gave up. ‘If North was heading towards the house, head East 5-3 steps. What does ’5-3′ steps mean?

I would consider myself to be a hardcore room escape/adventure gamer. And I was turned off by this after 10 minutes of gameplay. Another major flaw was that I had no clue as to what was interactable. I tapped many times on things like stairs only to find out i was clicking a little ‘off’. Clicking on the house’s door doesn’t open it. Clicking on the doorknob opens up a puzzle, then you puzzle through to open the door.

I read articles occassionally about ‘oh we don’t use analytics’ or ‘yeah we don’t test our games with users, we just go by our gut’. Well, sometimes I need to get out the door and watch people play my games, because what I thought they would do is nowhere near the truth. I think this game could use a bit of user testing. I have no idea how the devs did usability, but it just feels like a game that has a broad appeal in its art style, but severely lacks in game design tuning.

A friend last week said I should do something in Monster Words. I didn’t think it could be done to my liking. He used some psychology on me: ‘You said you could find out in like 15 minutes. Do it then.’ I did. He was right, I was wrong.

Code Wins Arguments

This is one of my favorite phrases from the Facebook IPO S-1 filing. One of the things that I value is the concept of ‘failing fast’. The idea that you need to work in a way where you can test a hypothesis quickly. Prototyping things quickly and writing demo code is key to that. The faster you get things wrong, the sooner you start getting things right.

But there are a lot of ideas, and how do you determine what game concepts are worth making, and which aren’t? Well, we developed a kind of methodology for determining what to prototype, and I think it works pretty well.

Prototype Planning: The Beginning

Thinking up ideas is easy. We had about 12 different game ideas that we could prototype. But how could we determine which of these would work the best? I created about 12 different attributes that I could assign to a game. I took my game concepts and threw some numbers around. I sat back, looked at the numbers and said ‘this is kind of a mess, I’m not sure there is much value in it’.

I realized that these 12 attributes could probably be generalized to three numbers: feasibility, audience, and fun factor. Knowing this, me and my friend sat down to figure out what we should make.

The Prototyping Process

First, I think at the very least, if you’re not making the game in a group, you should at least pull someone in for the planning. Someone to be an objective voice is very helpful in reigning in any ideas for MMOs with lasers.

Then, take all the ideas and write their names down. Give everyone involved a series of cards numbered 1-10. Then poker plan on the following points:

Feasibility: How realistic is it that we can create a prototype within the given timeframe?

Audience: How many people would want to play your game? How likely is there a good business model for this game?

Fun Factor: How much fun do you think the game will be? It is important to vote from the perspective of the target audience. For example, if you’re not an FPS guy voting on an FPS game, try to gauge the fun factor as an FPS player.

An Example

(The names and faces have been changed to protect the innocent.)

Chris wants to prototype a 2D game about bike maintenance. You learn how to fix your bike through playing the game. Chris and Steve are working on poker planning this prototype.

Feasibility: Chris and Steve initially vote this as a 7 and a 5. Chris attempts to persuade Steve: “its less difficult than you think because its a lot of point and click,.”. Steve attempts to persuade Chris: “You always say that and its always harder than you say.” They re-vote and Steve has persuaded Chris to bring this down to a 5.

Audience: Chris and Steve initially vote a 7 and a 3. This is a big discrepancy. Problem! Chris: “I think its got a big audience because its kind of a wacky concept, like Wario Ware.” Steve: “Wario Ware isn’t just one wacky thing, its lots of them. And your market segment is too small because the number of people who like bikes a lot and are into games is going to be way too small.” They keep re-voting, debate it out, and finally come to agreement on 4.

Fun Factor: Chris and Steve initially vote a 7 and a 6. Chris is able to persuade Steve the fun factor is higher because of a unique mechanic he wants to add. Since Steve is not really the target audience, he bends to Chris’ will and ups his vote to 7.

The Outcome

The important facet of this is not the final numbers, which will generally have a bit of skew due to politics. It is discovering the discrepancies between team members, and working them out. Everyone slowly gets on the same page, and the best ideas rise to the surface. We had some concepts that started out looking very promising which turned out to have details which made the game problematic.

An example of this was an ‘infinite runner’ prototype. Sure, the feasibility was high. The audience was potentially high. But fun factor? We couldn’t think of a unique game mechanic that would differentiate the game from other similar games. Without a unique game mechanic, we couldn’t guarantee any kind of fun factor and left it at a 5 for ‘average’. We opted to work on a game with a much more ‘known’ fun factor.

This all depends on your team and abilities. If you *have* a great idea for an infinite runner, then maybe this would be the direction to go.

Well, I think I’ll be refining this variant on Poker Planning as I go, it seems very promising. And if you have any thoughts or have done something similar, I would be very interested to here your thoughts!

For me, if I were to pick a platformer that is awesome on iPhone, it would be Doodle Jump. It used the iOS controls to innovate on the genre very well. A lot of platformers have a hard time on touchscreen devices, mainly because they attempt to emulate the existing controls of a controller. Paper Monsters comes to mind. ZiGGURAT attempts to experiment with new controls and falls a little short. Zelda: Skyward Sword suffered because of its corporately imposed requirement to use the Wiimote Motion Control Plus in a unique way.

Anyway. The point is…this is HARD.

Hookshot Escape is a great game that is able to make platformer controls work well on iOS. The intuitiveness of the controls and the simplicity make for a really fun game. It also works extremely well given the screen size. They chose a very functional size of sprite, balancing between the readability of the characters and enough real estate for the user to comprehend the environment.

Their business model is quite interesting: it was a $1.99 game, with in-game purchases. It seems like a lot of games are actually pushing up their prices, and attempting to get more LTV (lifetime value) out of users who really like the game. I also bought Lume and Waking Mars, both $4.99 titles. Ghost Trick was $9.99. All that is still less than a console game, and I think the variety and fun factor is higher than buying Yet Another First Person Shooter: The Sequel.

I saw this above screen a LOT. This didn’t deter me, and I think I’ll be playing a lot more. The art is great, and the game is very well thought and fun.

Perhaps as a followup to ‘Mistakes I’ve Made As A Programmer‘ I could make ‘Mistakes I’ve Made As An Entrepreneur’. Those mistakes outweigh any programming mistakes I’ve made, as I’ve not had the best luck from a business perspective…yet.

Developing a functional business model for a game is not easy. There is a lot of dart-throwing involved. The most important acronym here is SWAG: Silly Wild Ass Guess. How do you define a business model for a game? What are the key variables?

Then it hit me: I prototype games, why don’t I prototype business models? Answer: Because I don’t know how.

Go Ask Alex

Alex Osterwalder is an entrepreneur who wrote a thesis for his PhD which has evolved into a philosophy and set of exercises based on his concept of the ‘Business Model Canvas’. I was turned on to Alex’s work from Stanford’s Entrepreneurial Thought Leaders podcast.

To start out, I was skeptical, because, well, how many systems and ideas are there that propose to give value and end up being a Tony Robbins motivational self-helpfest? Too many. I’m a quant under the hood, I want numbers. I want actionable numbers. What numbers are important? What numbers are questionable and require further research? What numbers don’t make a difference at the end of the day?

The Business Model Toolbox

Playing with the numbers is important. Playing with them fast is more important. That is what I like about Alex’s Business Model Toolbox app.

The above business model idea for a fictional ‘Social Word Game’ was made in about 20 minutes. And that was with learning how to use the software. The idea of collaboratively pumping out 3 of these in an hour, and being able to quickly look at different ideas is quite fascinating.

The revenue estimator was intuitive, and well built to handle a few scenarios. I took the time to determine potential revenue generation from advertising based on my customer segments:

This was a great thought experiment. It made me think about a couple things:

• Are my numbers accurate? Is that a realistic CTR and CPC? Time to do some more research.
• The proposed game could not survive on virtual goods sales alone given the current business model. What could I change to make this feasible?
• What if I removed virtual goods sales completely and made it completely ad-supported?
• The business model I made broke even (after paying for everyone). What other business models (and types of games) could be more profitable?

These are all business models that can be roughed out quickly. This could also  be collaborative, with people who wouldn’t normally even be part of the business process. Providing a sense of economic understanding to the team can better inform people’s opinions.

The app also gives a good amount of reference material from Alex and his teams’ concepts.

Business Model Prototyping

I think I still need a lot of this to soak in, but the key takeaway for me is prototyping. Rapidly assembling lots of concepts helps point out which have merit, and which aren’t worth it. Of the ones that have merit, it gives a direction to evaluate the numbers, and determine how realistic they are in terms of time scale, profits and cost. This is a new concept for me, and one that I think will help me make less mistakes as an entrepreneur.

In my time as a developer, there are things I look back on and think ‘”oh my god, I totally Golden Hammer’ed that”. I can be a pretty blunt and bullheaded guy on certain topics, only to realize later that I was completely wrong. I think its quite easy to believe that you are right, and stay that way even with a lot of evidence to the contrary. But changing your opinion, and learning from that is a great tool.

So with that I would like to write at least a few articles going over mistakes I’ve made as a programmer. First up: Inheritance.

I pick inheritance first, because it is probably the question least asked when developing software. It is almost expected when you are given code for a library, that you inherit from some base class. And after a while you get this:

That is a JTextField from Java. Now, how many of these methods and properties are actually used by this class? Who knows? How does this occur? I think Ben Garney has a great video explanation of why this happens.

Bad inheritance is bad, mkay?

Frequently when I coded I would attack problems with inheritance as a given. It took a long time to stop doing this. It almost seemed like coding was supposed to be this way:

• Write some code in a sub-class.
• ‘Oh hey, that’s pretty useful, I think other subclasses will use that.’
• Migrate the code upwards into a superclass.
• Feel satisfied that I had somehow created a facility for code re-use in a best-practices methodology.

Delegation

I think James was on to something. Objective-C has a lot of delegation, and while the implementation is still somewhat limiting (who hasn’t done an if([foo isSubclassOfClass:blah] in a delegate implementation?) it is a far better way of doing things. Compare Java Swing’s hierarchy to ApplicationKit. From the Cocoa Fundamentals guide:

As you can see, the hierarchy tree of AppKit is broad but fairly shallow; the classes deepest in the hierarchy are a mere five superclasses away from the root class and most classes are much closer than that.

I’ve found AppKit to be a much cleaner and easier to understand implementation, and the use of delegation is quite helpful.

Strategery

I feel I must now be constructive and attempt to explain how not to use inheritance. Well, if you are not inheriting, you are ‘composing’. Object composition is the methodology, and the Strategy Pattern is the single most important design pattern you’ve probably never heard of:

Perhaps you’ve heard of it, that’s great. But its one of the interview questions I rarely use, because noone ever answers it correctly. The gist is:

• create a property on your class and instantiate an object that you can delegate the task to strategically.
• execute the corresponding function on the child object.
• if necessary, make multiple functions that execute the task in different ways, and use an interface/delegate/superclass to define the implementation for the behavior of the object.

The Strategery Pattern essentially unlocks the power of the Strategy Pattern by using an Entity/Component system, a common design paradigm. This essentially anonymizes objects into generic entities that manage the lifecycle of components that implement the Strategy pattern. Then all the components use the Strategy pattern to talk to each other.

An entity with various components that provide functionality via the Strategy pattern.

This allows for a very clean and functional coding environment, where objects only contain the code they use and the amount of classes used is ultimately reduced (through the Factory pattern).

If I were to credit a single person with helping me to stop using inheritance badly, it would be Ben Garney. His Push-Button Engine is based on the entity-component system. This is also used in other game builders (note: not engines) such as Torque and Unity. Thanks Ben!

Well, that’s about it for now. I’ve got a lot of other mistakes I’ve made in coding that I will try to attempt to share in the future. MVC and Singletons come to mind. Trust me, I won’t ever run out of ideas for posts anytime soon.