The third framework on my list is Monkey X.

Just did a quick confirmation check and the free version of Monkey X supports desktop and HTML5 game development. Cool! 🙂

07/25/2015 10:48 PM
Downloading Monkey X.

07/25/2015 10:55 PM

Checking out all of the examples. There is a built-in IDE just like Blitz! That is nice.
All of the examples have built and run fine for the HTML5 web target so far. 🙂

07/25/2015 11:35 PM

Checked out all of the examples. Looks like it offers all that I’d need to make 2D games: loading graphics and audio content, drawing images, playing audio. Also I must say this was a very big difference over Angel2D in that I simply installed Monkey X, launched it and everything just worked.

Tomorrow I will start on some coding to get used to the language. Seems to be using a custom language kind of similar to Java yet still different. Oh, also should mention the build times are incredibly fast. Like HTML5 game builds nearly instantly.

07/26/2015 10:58 AM

Just finished checking out some games made in Monkey X. There has been some good stuff done and developed quickly too. So that is promising at least.

Today, I plan on doing some development in Monkey X. So, I guess I should come up with a game to do. Ideally, it needs to be something that covers the needs for 2D games in general. To me that means the ability to have tilemap backgrounds, ideally scrolling level, sprites and multiple levels. So, I am thinking basically a game like Moon Patrol would be an ideal test. So that is what I will be using as a test for Unity 2D, Monkey X and whatever else I find that looks worthwhile. A Moon Patrol style of game with 2 levels. And maybe I will add a boss at the end. Not really needed so that one I will leave as a possibility.

Alright, it is time to jump into Monkey X and get up to speed on this thing! After I am familiar with it (as familiar as I am with Unity 2D development) I will be ready to start development on the game.

07/27/2015 8:36 PM

Whew! What a hot & humid day here in Missouri. Had a very productive workday, did my workout, had dinner and went out and mowed  most of the back lawn. Then I came in to spend some more time learning Monkey.

Although the language seems a bit odd to me as far as syntax is concerned I find it to be quite logical. Yes, I started doing a bit of coding. Then I thought well, I know I can download a library someone made to handle tile-maps but a great little exercise to get familiar with Monkey X would be to learn how to load images and create my own tile-map engine. I knocked out some simple tile images for the two mountain ranges in the background, and the foreground including the holes.

Then I started on the tile-map engine. It didn’t take long at all… about 30 minutes and a good portion of that time was spent on getting the image to load. Monkey X has some specific requirements about where your images must be placed in order to be accessible.

Back in the “good old days” it was pretty common to just use strings to “code up” design maps. It gives you a visual way to layout the stage. Then you just parse the string and transfer the data into an integer array to create the actual real map. During the game you use the real map because it is much faster than messing with strings. So, I just did a very quick design using strings then created the Load and Render methods.

You can check out my first Monkey X program: Tile-Map Single Screen   
This little demo is a whopping 90KB. Now that sure brings back memories of what this kind of stuff used to be like.

I’ll need to play around with sounds and music next so will make another little demo tonight for that.

I will provide the full project source for all of these demos at some point too. So far Monkey X is looking great!

07/28/2015 6:36 PM

The first thing I did was update the tile graphics. Not the image shapes but the colors. That was a very quick update and the time doesn’t count anyway because graphics work has nothing to do with the development time between Unity, Monkey X and other things. I mean the same graphics work is needed in all of them. Oh, I also increased the height of the first mountain range.

Anyway, I spent 30 minutes implementing parallax scrolling into my little tilemap engine, doubling the size of the map and increasing the height of the first mountain range.

Check out my second Monkey X program: Tile-Map Parallax-Scrolling Screen

I gotta say so far Monkey X is becoming quite easy to work with. As strange as the language seems compared to C#, I find it quite logical and easy to work with.

In fact, I am almost tempted to just go ahead and develop this test game creating everything from scratch myself. Considering in less than one hour I already have the parallax-scrolling tile-map complete. Not sure considering in Unity I would be using SpriteTile. Because of that fact I think I should go ahead and download a tile-map engine that is ready to go. Probably one that can be used with the Tiled Map Editor. That way things will be more even. Remember I have made these first programs just to get familiar with development in Monkey X. Learning exercises.

07/29/2015 11:15 PM

Tonight I downloaded the Tiled map editor and the Diddy module for Monkey X. Diddy provides, among other things, a system for loading and rendering tile maps created with Diddy. I spent 30 minutes in Tiles creating a real stage for the game.

Then I started looking at Diddy. Unfortunately, I could not find any documentation except for html fragments (like for a help file). I did take a look at the examples and they looked great. However, it seems to be built in layers as in it uses a game screen framework and then the tile management stuff and so forth. I spent 2.5 hours messing around with Diddy and although I seemed to be successfully loading my Tiled map I could never get it display.

And since I don’t like to waste time (with nothing to show for it) I am saying to heck with using Diddy. At least for now. Perhaps if Monkey X proves to be the language I stick with for 2D development I will probably give Diddy another chance. However, I am thinking I can simply knock out my own system for loading the Tiled data. In fact, I imagine had I spent the 2.5 hours tonight working on that I would probably have it done by now or at least very close.

So… tomorrow I will write a Tiled map data loading routine. I need to get this out of the way and also learn how to play sounds and music in Monkey X. Once I have the stuff I need all squared away then I work on the actual game and see how long it takes to finish it.

07/30/2015 9:40 PM

After talking to the Monkey X community on the forums I learned about some other options. bit.tiled is the one I tried today and I highly recommend it. It is not filled with all kinds of additional functionality like the others I checked out so you can get up n running very quickly on loading and rendering maps created in the Tiled map editor.

Of course, you may want to take the time to check out Diddy because it does have support for other things that will speed up development. I just didn’t want to spend the time now because I am on a mission and have many of these programming languages / apis to check out.

Bit.tiled comes ready to display the maps you have created in Tiled. The example actually just renders the entire map which means in my case it was rendering all 60 screens (yeah I updated my map again today) of map despite only 1 screen worth actually being visible. It also had no built-in support for scrolling. That’s all fine though because what it did offer was the Tiled map data loading (and the associated tilesets loading) and rendering. That saved me time!

I had already created a parallax scrolling routine in my last Monkey X example. So… I just integrated what I had into a Module wrapper around bit.tiled and presto I had a more efficient map rendering engine (only rendering what was needed for the visible playfield) that supported horizontal parallax scrolling.

Check out my third Monkey X program: Tiled-Map Parallax-Scrolling Screen

In total I spent 90 minutes updating the size of the first stage from 20 screens to 60 screens, getting bit.tiled to load and render the map, then adding support for more efficient map rendering (removing overdraw) and horizontal parallax scrolling.

I gotta admit I am liking Monkey X more each day. It feels great to be back to code-oriented development. These days people seem to want all of these GUI/Scene editor based dev environments. I guess for many people they really are faster to develop in but not for me. I have always been a programmer first and foremost and to me the most natural way to develop is by writing code.

Tomorrow, I will move on to audio. See what it takes to get a little Audio Manager built in Monkey X and get some music and sounds playing. Basically, I am just following the same process I did in Unity. I created an Audio Manager for it too.

07/31/2015 7:30 PM

Tonight I spent 3 hours studying all information I could find on using music and sounds in Monkey X … and … creating a new AudioSupport module and creating sounds, finding music and finally updating the tiled scrolling demo to also be an audio demo.

The actual loading and playing of music and sounds in Monkey X is very straightforward. The information I spent my time searching for and reading was “problem with sound monkey x” “sound not playing monkey x” and various other search terms. I’ve been at this stuff long enough to know it is better to find the pitfalls early on. In this case, the result of all of my research can be summarized as it is best to use the ogg format for sounds and either mp3 or ogg for music. And that is exactly what I did. I used Audacity to convert the wav files I created at Bfxr into ogg files. The song I downloaded from Sound Image was already in mp3 format.

I was all happy thinking this was easy! It worked flawlessly in Firefox (my favorite browser). Then I decided to test it in Internet Explorer and discovered there was no sound. Hmm…. so I decided to use a different tactic. I found the most popular (based on usage statistics the most common) browsers. The top 5 browsers starting with the most widely used first are: Chrome, Internet Explorer, Firefox, Safari and Opera.

So… I then spent another 90 minutes on this with a new strategy. What I did was download all 5 browsers and test methodically. I discovered that by using mp3 for music and a combination of ogg and mp3 for sounds I could accomplish two goals: (1) supporting the bulk of browser users and (2) use the most efficient (size-wise) formats for sound files. I will save you some time and tell you the key is to simply use mp3 for your music and use both ogg and mp3 files for your sounds. Yes, you need to duplicate them. I have a full set of sounds in ogg format and a second set of the same sounds in mp3 format. The ogg set takes up 137 KB and the mp3 set takes up 67 KB. There are 8 sound files in each set.

Music is played in mp3 format always and there is only the one music file. Sound is played in ogg format for all browsers except Internet Explorer. Yep, as crazy as it is the second set of sounds is needed just to support IE!

However, I ended up having to throw out support for Safari. I actually don’t know anyone who uses Safari but I am sure there are many out there since it is probably the most common browser for Apple computers. Still, I am happy with this system. Unity webplayer plugin supported exactly the same five I decided on: Chrome, Internet Explorer, Firefox, Safari and Opera. I am sure this was based on usage stats as well. lol

The thing is the Unity webplayer plugin already requires a tiny hack to work on Chrome and in time I suppose it will not work at all. And other browsers will likely end up the same way. Ideally, in time, the top browsers will all support common audio formats. Basically, if they all just supported mp3 and ogg for both music and sounds developers would have a much easier time.

At first the audio was still flakey on Internet Explorer. After numerous tests I had a theory as to what was causing it and updated my Audio Manager to test my theory and see if I could resolve the issue. It worked!

So here is the deal: when I detect the browser as IE I switch from Cycling Channel Mode to Dedicated Channel Mode. By default my audio manager uses cycling channel mode. Meaning each time a sound is played the internal channel number is incremented by one. So the first sound plays on channel #0, the second sound on channel #2 and so on. This continues until it hits channel #31 then resets to 0.

However, this didn’t work on IE. In IE if you played the same sound more than 6 to 8 times it would stop playing period until the channels cycled around to 0 again.

So this brings us to Dedicated Channel Mode (DCM). First, I should say that when a sound is loaded it is assigned an ID. 0, 1, 2 and so on. In DCM instead of the sounds cycling across the channels each sound is played on the channel corresponding with the sound’s id. This, of course, means we cannot have more than 32 different sounds playing in any one scene. But hey don’t be angry with me tell Microsoft. In reality, I don’t consider a maximum of 32 different sounds in any one level/scene/screen to be a big deal.

In fact, in hindsight, it might have made more sense to have just created the Audio Manager this way to begin with. I do like the cycling approach though. It is the same way I created my Audio Manager in Unity and other APIs in the past. I must say though the dedicated 1 sound only per channel does seem to be a perhaps cleaner way of doing it. There is likely less load/noise perhaps work going on in that scenario. It is possible the internal audio system of the browser knows the sound is the same and does not even bother to reload it. It all depends on how they implemented it and I have no idea.

Another way to design around this is to make sure you put the most significant sounds into the first 32 slots and then you can add as many little embellishments as you like after that point. Then on IE people will still get a great experience and on the other browsers people will get a little richer experience. I am thinking of some subtle “extra” sounds, ambient sounds and so forth.

Check out my fourth Monkey X program: Tiled Parallax-Scrolling Audio Demo

This means I now have the ability to easily add music and sounds to my Monkey X projects.

That is one more major piece needed for a rapid game development environment. 🙂

Monkey X is still rocking on!


08/01/2015 10:55 PM

Today I spent 3 hours designing and coding a Sprite System (GSS aka Gar’s Sprite System). Basically just a Sprite List at it’s simplest. However, it also features a fairly comprehensive Sprite Animation System. This makes it very simple to set up one-shot and looping animations, assign them to a GSSSprite (GarsSpriteSystemSprite) and the system handles it all for you (well me).

Handling sprite’s in Monkey is very straightforward. The commands are about exactly as I remember the sprite-based commands in Blitz.

Check out my fifth Monkey X program: Parallax-Scrolling, Audio & Sprites

I did run into one major issue that I have not resolved. For some odd reason when images are drawn that overlap the bottom of the canvas they actually render over the webpage outside of the canvas. The drawing seems to be clipping at the left, right and top edges but not on the bottom.

I spent about 35 minutes of the 3 hours just researching to find a solution to this problem. Every tiny lead I found and tried to extrapolate a solution from did not work.

If I had actually spent this time working on core game functionality I am sure I would have the player moving across the tile terrain, jumping over the holes, crashing into the holes and firing missiles or whatever. But, I was still in my learning mode just to see how long it will take to get my head around Monkey X development and get some basic systems together that are needed for 2D games.


08/01/2015 11:15 PM  One Week Summary

At this point I have now spent one week learning and developing in Monkey X.

I’ve decided it makes much more sense for me to move on to the next programming language & api on my list than it does for me to continue to spend my time on Monkey X. My goal is to figure out what is the best 2D development environment for me.

I now have a very good understanding of the potential of Monkey X. I also like it a lot and find it to be a very well done programming language with a solid API for building games.

This won’t be my last update here. At the very least I will return and post all of the source code for the examples above in the hope that it will help out others interested in game development in Monkey X.

And I may just end up returning to say hey, I have tried all of the rest and Monkey X is the best. I just won’t know and won’t be able to honestly say that until I have tested every alternative on my list.