The sixth game development framework on my list is HaxeFlixel.

08/02/2015 9:00 AM
Downloading Haxe, Lime, OpenFL, Flixel and FlashDevelop then running some stuff on the command line to set everything up. I just followed the process documented here. Everything installed fine with no errors.

Messed around with the FlashDevelop editor to get used to it. Went through a simple tutorial on the HaxeFlixel site to get a feel for creating and working with HaxeFlixel projects.

Although it seemed a bit odd having to use the Command Prompt to actually create a new HaxeFlixel project it wasn’t bad. Reminded of working with C (DJGPP) & Allegro back in the Dos days. Also, I created a little batch file named Create new HaxeFlixel project. So now I can just use this batch file to automatically create a new HaxeFlixel project. Also, it seems like I could simply copy a new empty project and use it as a template. That is the common way I do development in everything including Unity. I have a New Project Template that I simply copy and rename.

Everything worked. I now understand the basic structure of HaxeFlixel game projects. How the FlxGame is at the top and beneath this sits the various FlxStates. These FlxStates are exactly as the name implies states of the game at the high level. The Menu is a common state. Play is another common state. One could (and many probably do) even use a FlxState for each level. Basically they are like scenes in Unity except I get to work in code not in the dreaded Unity Editor. lol

I successfully built the tutorial project for Windows and Web. So far so good! I like what I have seen so far.

From here I am going to move to working with tile maps. Basically see how long it takes to get my Tiled map data loaded in and rendered.

08/03/2015 10:15 PM

Tonight I spent 2.5 hours checking out how to work with Tiled maps with HaxeFlixel. Despite trying a few different methods I found online none of them actually worked to display my map.

The map seems to be loading fine but only 1 column of it is rendering.  It also seems to be scaled up and positioned mostly off the screen.  I have a feeling it is some camera issue.

I had hoped the various tile map loading routines would simply load the data back into an array that I could easily work with.  However, this whole HaxeFlixel system seems to be built around it doing a lot of the work for you. Much like Unity.

I guess I simply prefer just having the basic stuff in place… as long as I can load images, music and sounds, draw the images and play the music and sounds… that’s all I need. I can knock out the systems that I need easily enough. The trend these days is to have game engines to do a lot of the work for you. It is a great idea. However, my experience has been that most of these game engines are so oddly designed they end up adding as much or more time in some areas as they save you in the other areas. lol 🙂

Normally, something like this tile map issue would be very easy to troubleshoot… if it was something I had designed and coded myself. However, at this point I don’t even know where to begin to troubleshoot it because I really do not understand what all is going on and how it is happening.

Seriously… I have no idea how the map is being rendered. How to specify how much of the map should be drawn on the screen. At which map cell to start rendering it. In fact, so far to display my little block player character and the bit of the map that is showing I have not used any Draw or Render method at all.

So… I suspect a camera is what does it all. However, I noticed that every object actually has a camera property. Perhaps it works as some kind of local viewport on every object. Or maybe by default that property all maps back to a single camera.

Anyway, I will stick with it and work through this because this looks like a promising system with a lot of power. I just need to wrap my head around their model. Probably I need to find some basics / overview of how this HF system works in general and then will at least be able to guess at what the issue is.

So… tomorrow’s objective is to take a step back and spend some time focusing on just understanding how HF works in general. And definitely take a good luck at the camera / object cameras.

08/04/2015 9:50 PM

Okay, tonight I spent 90 minutes going through the HaxeFlixel API documentation and the source for a couple of the HaxeFlixel demos. Just getting a clear picture of the architecture of this game engine and how to use it. Because I had already attempted to jump straight into coding with it I was able to get my head wrapped around it fairly quickly.

So… I then spent another 30 minutes on another attempt to make a single screen (non-scrolling) tile-map demo. And this time… it worked! 🙂

It turned out to be a combination of several different things. First, the TiledMap loader was not correctly loading the data. I ended up having to change from saving the map as csv data to Base64 format. Second, the camera indeed was a major factor. And a few other bits here and there such as not knowing how to actually debug in this thing. You can use trace() or even just throw to create exceptions. So now that I was able to actually get some feedback that helped tremendously of course. Throughout all time even with all of the fancy development/debugger tools I still rely heavily on the simple print command (either on-screen or to a log file). It works.

So yeah… basically there were just many little things I just didn’t know about this environment before tonight. Mainly because I think this was designed for people who have a lot of experience in either Haxe or Flash development and I never used either before. But… programming is programming in the end. It is all coming together now.

You can check out my first HaxeFlixel program: Tiled-Map Single Screen

It still feels like things are a little too abstract at this point but at least I have a much better understanding of it then I had last night.

I think HaxeFlixel definitely has potential!


08/05/2015 10:12 PM

I just finished another 90 minute session. This time the first thing I did was recreate my Tiled map. When I originally created the stage map for my Monkey X demo I used a single layer. This is because in Monkey X I simply got an array of tiles that I directly worked with and there was no need for multiple layers. Basically, I just divided the map vertically into sections and scrolled each at a different speed.

With HaxeFlixel the map is managed by the system so I simply created two more layers in the Tiled map editor and copied the content into them from the original single layer and then deleted those areas of the original map.

However, I was not sure if there was a way to independently position the layers within the TiledMap object so I did a little trickery. I modified the TiledLoading routine so that as it loaded the data in it identified each layer in the original map and populated 3 separate TiledMap objects declared in my TiledMapManager.

By doing this I was able to easily implement parallax scrolling. Of course, I am definitely benefiting from already having done the work for this demo in Monkey X. And I am definitely keeping that in mind as I test HaxeFlixel. For example, I used the same scrolling control system that I created for the Monkey X demo. The only difference is in MX I scrolled sections of a single map (because I was rendering the map itself drawing individual tiles) and in HaxeFlixel I am scrolling 3 separate TiledMaps objects (and the system is actually drawing all of the tiles on the screen contained within each map).

You can check out my second HaxeFlixel program: Tiled-Map Parallax Scrolling

Working in HaxeFlixel for tonight’s updates was much easier. It is all making more sense to me. I was able to quickly come up with the design for how to implement the parallax scrolling and it worked.

I don’t want to knock other developers but I have to say that I think what makes understanding things like HaxeFlixel and even Unity in the beginning is that so many of the code examples we find on the Internet are written by very inexperienced developers.

For example, tonight I was able to clean up my TiledMap loading routine and make it more streamlined and easier to follow. Originally, I found that on the web. Now, especially with the support for the parallax scrolling, it is basically my own custom version nearly fully written by myself. Still the original source did provide the clues needed and the general direction. So I am glad for that!

HaxeFlixel is starting to look cool.

08/06/2015 6:15 PM

Okay, this evening (yeah I started early!) I worked on adding music and sounds. For the Flash target I am using (actually OpenFL) I needed to convert the sounds to wave files. The music worked fine in the original mp3 format.

I spent 2 hours on this update. Adding the music and sound assets and configuring the AssetPaths file was easy. Still had the set up of loading all of the sounds, coding the playing and destroying and so forth. I spent as much, if not more time, just going through all of the different keyboard functions offered by HaxeFlixel.

You can check out my third HaxeFlixel program: Tiled-Map Parallax Scrolling Audio Demo

HaxeFlixel is definitely a solid 2D game development environment. At this point, there is really only one more thing to do to get the demo up to the point of the Monkey X demo. And that is sprites. So… with the next update I will have completed my initial learning of HaxeFlixel 2D game development.

08/07/2015 6:40 PM

Today I studied the API documentation on sprite usage. It was quite easy to set up. In total I spent only 45 minutes adding two animated sprite objects. Like the Monkey X demo, one is a one-shot animation running at 1 FPS and the other is a looping animation running at 10 FPS.

You can check out my fourth HaxeFlixel program: Parallax-Scrolling, Audio & Sprites

When I made the Monkey X demo I actually coded up my own sprite management system basically a simple display list. However, I also built an animation system. Interestingly, what I built seems very much like the animation system built into HaxeFlixel.

I’ve found that I do not like game engines very much. Mainly because they always go too far and make what should be simple things into more complex things. In the case of HaxeFlixel I don’t have that view because the sprite animation system they created is very lean & mean and easy to work with. Like I said, it is actually very similar to the animation system I created in Monkey X.


08/07/2015 6:45 PM  One Week Summary

At this point I have now spent 6 days learning and developing in HaxeFlixel.  I’ve made it to the same point with my development that I am at learning Monkey X.  Of course, it was a little faster this time because I already had the tile images, sprite images and tile map created. Also had the sounds created and the music selected.

I now have a very good understanding of the potential of HaxeFlixel and must say I really like it. It is a very well done framework for developing 2D games.

Obviously, HaxeFlixel is a great framework for rapid game development as can be seen in such cases as Coding Breakout in 20 minutes.

Well, that is the power of using a straight forward programming-oriented development environment. This stuff (2D game dev) really should not take nearly as long as it does in things like Unity. Trust me. I have done this stuff for many years. That has been my whole my point all along and is the driving force behind me taking the time to check out all of these alternatives.

Now it is time for me to move on to the next alternative on my list.