Category Archives: Conjurer

More concept art

Thought you guys might enjoy some more concept art.

cat_piratesCat pirates are some furry little NPCs and enemies throughout some of the tropical areas in Conjurer. They’re adorable, but don’t let their cuteness fool you. They are bloodthirsty little savages –  Vicious little cutthroat scoundrels!

omen_polesOmen Poles are NPC objects that act as quest points and hints to find secret areas. They’re guarded by Touki Birds, and house the souls of those who betray others in a heinous manner. They speak in riddles, and the taller a pole is, the more complete the riddle you receive.

gomer_the_poetGomer the Poet is a lovable NPC and quest giver that always seems to end up horribly maimed, slashed, impaled, crushed or inconvenienced.  He only talks in rhyme, which is more than likely due to brain damage.

touki_birdsFairy Doors are little doors that are hidden everywhere. If you happen to have a fairy key, you can shrink yourself down and see what’s inside. It might be treasure. It might be a helpful items. It might even have someone inside to talk to. Keep your eyes peeled!

fairy_doorsTouki Birds are tough giant birds that reside in the tropics. They hassle you by acting very territorial and dropping heavy objects on your head. You can trick them into triggering traps and puzzles if you’re smart enough.

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.

New races (concept art)

I had the idea of adding new races of characters into the world of Conjurer. I figured that it suits the lore and opens up a lot of interesting ideas in terms of story and gameplay. I like the current concept sketches, and I’m doing my best to stay as far away from furry territory as possible.

Trent and I have been hard at work building out a wiki for Conjurer. We decided to do this after it became apparent that I’d forgotten a large amount of lore that we’d thought up 6 months ago. I’ve never been good at keeping track of that kind of stuff. But, story is going to be a large part of the gameplay, and exploration is hopefully going to be what makes the game interesting. If anything, it gives me a way to allow future KickStarters to participate in the development of the game. Maybe donating $100 gets you written in as an NPC. $200 makes you a quest giver. (Prices may vary). Sounds fun, why not.

Work on the engine has been slow, and the past few months have been hectic. I went through a not-so-positive experience at a software company, and I’ve got another couple of projects for a client that have been eating up the rest of my time. But, we’re still moving forward, albeit slow.

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!