Category Archives: Engine

TigerHawks, alpha video v1.0

Here’s a look at the first video of alpha gameplay for TigerHawks.

As you can see, you can play as a Player Plane against a single Enemy Plane. The plane will roll depending on which direction you’re turning. The enemy plane AI is just on a random, dumb algorithm that makes him change speed and direction every couple of seconds. The Player Plane is fully controllable by both an Xbox360 GamePad and and OUYA gamepad. It also builds perfectly to the OUYA device, and plays at a beautiful 60 FPS. You’re capable of firing a handful of weapons, such as 3 different machine guns and a dumb-fire missile.

I’m VERY pleased with how well this build is going, and how well Starling is performing on both PC and the OUYA, which is arguably a moderately powered Android device. Keep an eye out for more updates in the future.


BitmapFont generator Hiero saves the day!

colorCodeFontJust wanted to give a shout out to Hiero, an outstanding bitmap font generator! It will convert any TTF system or file font to a format compatible with LibGDX. It will even apply some minor effects to the glyphs, such as outlines, shadows, and gradients. Use it for other engines as well, provided that you can ready their .fnt format.

For instance, this is Franklin Gothic Heavy at size 32 with a shadow, outline and gradient, squished into a 256×256 square. SUPER helpful!

You can download it here:

On the move to libgdx

Over the past couple of months, I’ve started the move to another framework. In short, I have wanted to get away from Adobe Flash for a long while. I’ve sampled a lot of other frameworks in the past, including Unity, Cocoa, and HTML 5, but all of them came with overhead or a ‘gotcha’ that ultimately made it unappealing in the long run.


For Unity, it’s an issue of cost: Unity is an incredible strong platform with a wonderful IDE and tool set. BUT… to go pro means that I would have to pay over $4000 in upfront licensing costs, not including the cost of all of the community-written plugins and tools. I do not pirate software and I’m not a student, so there’s not much else I can do. I’m also set on 2D development for the moment, and that isn’t one of Unity’s strong suits without the addition of many other 3rd party plugins. I want to revisit Unity in the future, though, when I finally break into 3D.


For Cocoa, or other native Objective-C frameworks, they present a strong case if I were only looking at developing for iPhones and iPads. Yes, I know that there are some cross compatible frameworks that support Android and PC, but… no. I don’t see the practicality of investing the time to learn a language like Obj-C when it is only realistically applicable to developing applications on iOS devices.


For HTML5, it’s many things. In my opinion, JavaScript is not an ideal language and framework for making large games. Small games, YES! But larger games… the jury is still out. I have no intention of making my game browser compatible, so there goes JavaScript’s  relevant strong points.


MonoGame is a VERY exciting emerging framework that I am going to keep my eye on. I’m a huge fan of the XNA framework, and was devastated to hear of Microsoft dropping support for it about a year ago. It had everything: speed, C#, gamepad support, PC/Console/iOS/Android support, low cost… but it still needs more work. Once the opensource framework is 1:1 in feature sets with the old XNA, and someone figures out how to properly emulate the old XNA graphic and asset pipeline within a single project, I’m going to give it a lot more serious thought!


I’ve decided to move on to libgdx. It’s a fantastic framework which, surprisingly, uses Java as its primary language. That’s good news for me, because that’s the language I was formally educated in while at college at UC Irvine. Despite the negative stereotypes associated with Java in the past, libgdx ends up being quite fast, and supports all of the features that I’ve been looking for in game development for projects like Conjurer, including OpenGL ES, Gamepad input, Box2D, etc.

I’m looking forward to getting back into the thick of it. Putting my project on hold like this feels more like a frustrating waste of time, but I know that it’s for the best. In the mean time, I’ve also begun learning how to compose music! Let me know what you think.

Engine Update: Scenery, Terrain, and Hero



Here are the latest new features:

Scenery: Each new level can now have scenery marked up in the level file. Scenery can be animated or static in visual appearance. Soon, I’ll get around to building lots of little knickknacks to position all over the map to stress test i. Terrain acts like terrain should, but the art for the grass is temporary. Expect something prettier when I have some trees, rocks, fences, bushes etc.

Hero: The hero  is now loaded into the game on start up. He isn’t animated yet, that will take more time and planning, but he has some rudimentary logic in place that allows him to walk around and double jump. Thanks to the Nape Physics engine, he glides over slanted hills with ease, coming to a full stop when there is no directional input from the player. Input comes from…

Keyboard commands: A dynamic keyboard mapping tool was built to allow you to swap out key values for controls. Currently the player uses the arrow keys and ‘a’ key to get around.

GamePad support: The hero can also be controlled by an Xbox360 gamepad using the left thumbstick and ‘a’ button.

Camera: A simple camera keeps the hero locked near the center of the screen. Soon, I’ll be able to limit it by a level bounding box, and have it set its attention to Entity objects other than the hero.

Console: You can now bring up a console to feed in commands to the game. Currently, you’re only able to enable and disable gamepad control, as well as load a sound or song of your choice for playback.

The UI is just for show right now. I’m building the InGameUI class to handle supporting the health bar, mana bar, inventory, and spell icons.

Thanks to Adobe AIR, I can already install this on Windows and Mac machines using the Adobe AIR installer. So far, everything works, including gamepad support, outside of the FlashBuilder dev environment. Excellent!

Feeling great about this right now. A lot of new features are getting popped out faster than ever now that the ‘hard part’ of getting the physics and graphics up and running is over.

Coming up:

Simple In Game Level Editor
More UI (Dialog screens, fonts, menus, etc)…

First major engine update

Big update today!


What you’re seeing in this image is a very simple level being pulled from XML markup, parsed into Nape physics entities, and painted over with a preloaded texture that resides in a BitmapData object pool. You can’t tell, but a sound track is being played in the background and fades in from silence.

A LOT goes in to actually making this happen, and it’s so nice to finally be at this point in development!

The following engine features have been implemented over the past few  weeks:

GameObject: This class is a super class for any object that is used in game. It uses a component-based structure to handle aspects like graphics, physics, AI, etc.

DisplayManager: This class manages containers that hold various GameObjects, like background, game stage, foreground, and UI elements. It handles the ability to move into and out of full screen mode. It also initializes the ImageLibrary on start up.

ImageLibrary: This class is an object pool for bitmap and meta data for any image seen in the game. Once an image is loaded, its bitmapData and meta XML stored and cataloged in an associative array for quick lookup.

Animations, Frames, and FrameScripts: These classes are a means for a GameObject to display graphics on screen. When called by name (e.g. “walk”, “run”, “reactToHit”), an animation will dig its corresponding spritesheet image out of the ImageLibrary, then use a sequence of Frame objects to designate what section of the spritesheet to display on screen, and for how long.  FrameScripts can run on each frame, allowing me and my designers to create more dynamic looping effects, spawn particles, pause animation, etc. It’s MUCH easier to do this through a crude script markup than by tracking it in code, though it might make debugging a bit more difficult. We’ll see.

Graphics Component: This component class is used in tandem with Animations to display images on screen. Since I’ve decided to forego Startling until I’m more comfortable with designing around its API, it will use the standard object to draw items on screen.

Physics Component:  This component class is used in tandem with the Nape physics framework. It handles managing the shape, friction, material, and other attributes associated with GameObject in the game’s physics model.

AudioManager: This class manages anything audio related, whether it’s playing sound effects or music.

AudioLibrary: Similar to the ImageLibrary, this class acts as an object pool for all Sound Objects.

LevelManager, LevelStage: These classes represent how the game loads levelStage data from XML markup, parses and initializes all necessary GameObject assets, and begins the game loop.  A lot of the heavy lifting happens here, because this is essentially the game!

What a haul. But, now I have the basic backbone in place for the custom game engine. Level stages can be loaded from XML files now, which means that I can finally start in on actual game design, as well as start building a level editor for my designers. It’s been a long wait, but now the fun can finally start. Hooray!

Frustrations over Starling and Citrus

I’ve spent a rather long time trying to get a solid direction going in terms of setting up a back end asset/entity management system. I didn’t want to build one myself. It’s a pain in the ass, and a major time sink. I’ve been sniffing around looking for other frameworks to handle this for me. This week, I’ve been giving the Citrus Engine a whirl, but there have been a few rather important flaws that have popped up.

  • When entering and exiting fullscreen mode, Citrus (and implicitly, Starling), would crash due to a loss of Context Error. It’s VERY frustrating for me to chase down bugs in someone else’s framework, and after a good two days of spinning my wheels, I couldn’t come up with a working solution. Too bad. Citrus was looking very promising.
  • Starling also doesn’t seem to want to scale when Stage.displayState is set to StageDisplayState.FULL_SCREEN_INTERACTIVE. It locks the render area to the stage’s predetermined viewport size. The fix has been to increase the viewport’s dimensions to full screen dimensions, but that is NOT what I want to do. I want the resolution to remain the same (1024, 576 for example), but to have the rendered image scaled to fill the screen. I’m done trying to get this fixed. It’s  a TERRIBLE fault in Starling’s design.
  • Starling also has no support for functionality similar to Flash’s, y) drawing. There are some bandaids offered by other developers, but they lack a means of transforming a texture used to fill a given polygon. What’s more, if you want to have a texture tile in Starling, it CANNOT be from a texture inside of a texture atlas. It has to be in its own separate Texture. THIS IS CRAZY! The whole point of using Starling is to utilize the hardware for maximum efficiency, and texture atlases are a large part of how you accomplish this feature!
  • I can’t seem to find very good information on using Starling for games that aren’t small, casual titles. What I find are articles on “How to make a gem puzzle” or “Angry Birds clone”, which all require a single TextureAtlas  to contain all graphics. If I’m trying to make a game that essentially looks like this, I’m going to need a hell of a lot more than a single texture atlas. Where on Earth do I even start in setting up something to handle this?

If anyone has any practical solutions to these problems, please let me know. Otherwise, I’m back to using Nape physics and my own proprietary image management for Conjurer.


New Years Resolutions

Resolution #1: More posts on the dev blog

It’s difficult to write a blog and try and keep things relevant and interesting. Try it. You’ll see what I’m talking about. You all couldn’t give a shit if I said “Been two weeks, no progress because nothing is really working yet.” But, on the other hand, living under the judgement of those who want to see my work succeed is exactly what keeps me motivated. So, expect more updates.

Resolution #2: Stop reinventing the wheel.

This is somewhat related to post 1, in that I’ve spent the last couple of weeks trying to build a new back-end graphics and physics component system to an Entity framework that controls all game objects loaded on screen. I’d already written one at BlindSquirrelGames for Beards and Glory, but given that I don’t work there anymore, I can’t really use it. That’s OK! Because that B&G framework was custom tailored to run on mobile devices, and as anyone out there who has worked on mobile game development can attest, it’s a VERY limiting platform. This time around, it feels nice to stretch my legs and not to be so constrained by such an environment.

So, it’s been rather frustrating to start from scratch, because I simply DON’T have the time. So, after doing a lot of research, I’ve decided to use the Citrus Engine. It supports two major features that I have already spent 2 weeks trying to hammer out on my own:

Rigid body physics support using Nape.

GPU-enabled rendering using Starling.

Couple that with the Xbox360 gamepad support (Windows only) that I’ve already implemented thanks to a fantastic Native Extension written by Rhuno, and it’s finally time to start cranking out some new features!

First flash… then XNA… now, back to Flash?

Outside of all of the concept art you’ve seen on this dev blog, I’ve been doing a lot of research in preparation for developing the engine to this game. It’s been getting me rather frustrated.

Here’s my dilemma…

Ever since I used XNA at UC Irvine for a game project class, I’ve been really interested in picking it up again. I was hoping to use XNA for Conjurer. It’s such a robust framework, with a ton of support and a long laundry list of indie titles that have seen some pretty good success. I LOVE working in VisualStudio. It’s such a powerful and user friendly IDE. XNA has native support for gamepads, integration with DirectX and can easily handle almost any genre of game type I want, whether it’s a 2D RPG or a 3D racer.

However, I already know how to develop, program, draw and animate in Flash. Been doing it since Flash 3 back in ’99. In fact, I’d go far enough to say that I know it REALLY well. I teach a class on it at a local community college. And for what it’s worth, it’s a really powerful framework and engine. It has a TON of support and a HUGE user base. The player and IDE are constantly updated by Adobe with new features, and it doesn’t look like they’re dropping support for it anytime soon. The major drawbacks that still linger are its speed in comparison to other, lower-level frameworks. A lot of this has been dealt with recently, such as the recent implementation of Stage3D and Worker multiprocessing (Though, in my book, the jury is still out on the latter).

Here’s the rub: I want to make a game in XNA. But, it’s becoming more and more terrifying to realize that I’m on my own at FrenchRoastGames. Art, Tech design, programming… all me (for now). What’s worse, I have painfully learned the hard way that picking up a framework by myself is an incredibly time-consuming and frustrating process. I prefer to learn through osmosis, to have tasks delegated to me from someone who clearly knows what they’re doing, and who can help pull me out of a bind if I get stuck. This likely has something to do with the poorer grades I got at UCI toward the end of senior year. Not fun. Downright demoralizing. Useless TA’s, incompetent colleagues, and overcrowded lectures aren’t a good way to learn the finer points of graphics processing and development.

In short, I don’t have time to learn a new framework. I HAVE TO MOVE. A week spent piddling around on XNA tutorials is a week not spent on development. There is a considerable amount of work to do to build an adequate cross section of gameplay. That cross section must have enough quality to convince tens of thousands of people to donate $10 on KickStarter. This is critical to the success of this game. It has to be a full time commitment by me and a handful of other developers or it will not see the light of day!

One big feature that I am adamant upon implementing is support for game pads. Flash doesn’t have it(yet), which is what ultimately pushed me to XNA. However, recently a couple of developers have been gracious enough to create an Adobe Native Extension for Xbox360 gamepads. It only works on Windows (for now), but it’s a huge step in the right direction for Flash. If I can goad the developers into including support under OSX and Linux (Ubuntu at least), or augment it correctly myself, then I’ll be incredibly happy.

Another big feature was tools development. After working on Beards and Glory for Blind Squirrel Games, I now understand the importance of building quality development tools for other designers. It’s an aspect of game development that is horribly overlooked and underrepresented, in my opinion. For every tutorial and book I need for XNA development, I’d need another book on .NET and WPF to make the level editors, asset managers, and testing apps for the game. This is not an issue with Flash, mostly because of the Flash IDE (asset development and organization), and how easy it is to make level editors myself.

So… as much as I am desperate to move away from Flash, my flagship project is going to have to be built in it if I’m going to get anything shipped on my own.  XNA will have to remain a hobby until I can quickly conjure up a design spec for a project in my head without consulting the Internet. Thankfully, my design requirements aren’t outside of the scope of Flash’s capabilities, and I’m sure the Adobe Game Developer Exchange wouldn’t mind yet another project in their developer showcase. I guess it’s best to make these decisions now, and not further down the production line.