Menu Home


Game programming…

Last year I learned the basics of jMonkeyEngine, and though I intended to create a 2D game with it, I only ended up creating the MIDI animator mentioned in my last post. But for a tile-based 2D game, it’s really not ideal. It’s certainly capable of producing such a game, but as an engine, it’s not really designed for it, and I realized I’d have to spend a considerable amount of time just programming a custom framework for such a project.

So last month I began learning LibGDX, which is certainly better suited for the sort of tile-based 2D adventure game I’d like to create.

So here’s what I’ve got so far (the art is temporary, simply a free tile set I found out there, though I think I’ll be aiming for tiles that are 16×16 pixels as well, so this represents the size I’m hoping for):


Doesn’t look like much, but I’m still learning and programming the basics I’ll need before I actually start programming the actual game play. What I’ve learned and/or programmed so far includes:

  • loading and displaying a tilemap (a .tmx file from Tiled)
  • dynamic window resizing (or resolution changing) without completely screwing up the aspect ratio (trickier than it may sound)
    • basically it will always render with a resolution of 1280×720, which is then rendered as a texture to whatever resolution the user sets; handy for Android devices which may feature differing resolutions which cannot be changed
  • using Ashley as an entity framework
  • using Box2D for character movement and collision detection
  • animating the character as he walks (much easier with LibGDX; I had to program a custom shader with jMonkeyEngine)
  • real-time A* pathfinding (hope to use it with NPCs)
  • text (as you can see at the bottom there) to be used with menus, dialog, etc. (nice little font called Munro) (this is also much easier with LibGDX)
  • custom shader to make object tiles “light up”

Still lots to program, but I reckon that’s an OK start. The to-do list before I can actually begin programming the actual game-play logic includes:

  • have interactable objects “light up” as the player nears them, along with a small pop up menu with available actions (pick up, talk, examine, activate, etc.)
  • design and implement a menu panel / status bar (along the black panel along the bottom)
    • this menu will switch to a “dialog mode” when the character is talking with someone (as in The Secret of Monkey Island, for example)
  • pause menu with save, load, quit, settings, etc.
  • camera movement for when the player walks off the screen
  • loading another tilemap for when the character leaves a village or enters a house, for example
  • I need to try sticking an NPC in there and having it play through some scripted material, utilizing the aforementioned A* algorithm as necessary
  • real-time combat system
    • cast a spell or swing a sword to injure attacking enemies (the combat will be simple in this game, nothing fancy)

That’s all I can think of at the moment, but that’s plenty, isn’t it?

The game itself will be pretty short; I’ve tried to keep it short on purpose since even a short game is a lot of work, especially when you’ve never done it before and don’t have a pre-existing framework your familiar with to use. If I manage to actually succeed in this endeavor, I hope it will be easier to create new adventure games and/or RPGs in a similar style without having to reprogram these basics again, at least not from scratch.

The tentative title for the game is Memory of a Thousand Kings, which began as a half-plotted fantasy novel, but I think it will work better as an adventure game.

Source code for my MIDI animator

I recently uploaded the source code to the MIDI animator I programmed with jMonkeyEngine to github: midi-animator.

To use it, see the Readme there. You’ll need jMonkeyEngine, and understanding Java would probably help. (I’m not really interested in making a standalone user-friendly app at the moment; Stephen Malinowski’s “Music Animation Machine” is still available if you want that. I’m more interested in having something I can continually customize and play around with.)

In addition to perhaps being sloppy (as I never intended to share it), the source code is a bit bloated as it’s actually part of a larger project to create a MIDI editor that will feature my melody generator. But that’s a long way off; I’m not actively working on that at the moment, and probably won’t anytime soon.

So… there it is if anyone else wants to play around with it, or contribute their own improvements to it… feel free!

Also, it’s my first time uploading something to github, so I’m not very familiar with the platform yet… I hope I did it right.

Still programming…

Haven’t posted in a while, so here’s a little update on what I’ve been up to lately.

Basically, I’ve abandoned Unity for now, though I’d like to get back to learning it at some point. But I’m much more familiar with Java, so I looked around and found jMonkeyEngine, an open-source Java-based 3D engine, so I’ve been learning that. I’m currently working on a small 2D mystery game for PC and Android platforms. (Like a small adventure game, where you go around talking to suspects, searching for clues, collecting inventory and using it, etc.) It will use pixel art, since I can actually create pixel art with a bit of clicking around. Currently I’m using Pyxel Edit to create the pixel art, which is small and elegant and quite affordable (only $9 at the time of this writing). Pixel art actually isn’t too difficult for a non-artist like me. Well, OK, it’s still possible to create really crappy pixel art. What I mean is that it’s much more approachable for a non-artist; you can create an effective passable character (and walk-cycle for that matter) much more easily than, say, trying to draw something with pencil and paper or trying to actually model and texture something in 3D. And it’s not difficult to search for references online to see how other artists did things; everything is made of pixels anyway. So I’m confident I can create the sort of graphics I think this game will need. Still, if I had the money, I’d rather hire a free-lancer. After all, it’s still a time-consuming process, especially the animation.

Anyway, while I’m more familiar with Java programming, jMonkeyEngine has far far less online support than Unity (and their forums are difficult to navigate and contain many broken links). The engine also has far less features. For example, to achieve the animated textures I need for my 2D game, I had to program my own shader. Granted, that’s not too difficult to program once you know how to do it, but I spent over a week just focusing on how shaders work (and only scratched the surface, I’m sure).

Still, the advantage is that I’m working in a programming language I’m much more familiar with, and I’m not obligated to pay any license fees or anything when my game is released. So, while I’m sure I’ll switch back to Unity (or GameMaker) at some point, I do very much appreciate the option of jMonkeyEngine.

So that’s what I’m up to at the moment. I have no idea how long it will take to finish this game, assuming I don’t abandon it. Guess we’ll see. I’m crossing my fingers that it doesn’t take longer than March 2016. (Which means it will probably take until March 2017.)

Back to Unity 3D

So my Kickstarter quietly (but I suppose not unexpectedly) failed yesterday, though backers did pledge to contribute $785 of the requested $9,000. Which isn’t completely horrible for spending no time building an audience. But it wasn’t nearly enough, so unfortunately there won’t be a book on melody from me in 2016. Not sure yet if I’ll try to build an audience and try another Kickstarter later, or if I’ll find some other way to find the time. But it’s back to being on the back-burner for now.

Other than that, I’m still learning the ins and outs of Unity3D. I’m confident I can learn the programming side with more practice and experience; Unity is so much more convenient and intuitive than the engines I fooled around with a bit more than a decade ago in high school. (I could swear I used to understand quaternions when I was in high school. Not that I really need to understand them now, as Unity takes care of them, but I still want to understand them again, if I ever really did.)

I’m also not worried about game design. Though I don’t really have much practical experience with it (beyond daydreaming), it is the fun part of game development. Writing, designing puzzles, storytelling, etc… Those are what excite me about game development in the first place. I would never have bothered to learn GW-BASIC when I was in elementary school if storytelling through video games didn’t excite me.

What I don’t have any experience with is creating art for games. Modeling, texturing, or drawing in general. And since I can’t afford to hire freelancers, that’s something I’m going to have to learn, and a skill I’d love to have anyway. Though I may try programming a game that features purely abstract shapes to circumvent the need for art, I still want to create adventure games at some point, and those will require some modeling and texturing skills.

So there’s that fun stuff, and of course I’ve still got some novels I’m working on…

Unity and games and stuff

Learning Unity!

This week, at the expense of working on my next novel*, I’ve been getting back to studying Unity, the game development platform. My new computer handles it beautifully, nice and fast. And I found some great introductory tutorials to start with from a “gamesplusjames” from Ireland, land of me forefathers:

It’s still a lot to take in; I don’t know if it’s just my aging brain or that I haven’t been programming regularly for a long time now, but I’m definitely slower at learning this sort of stuff than I used to be. Anyway, Unity makes a lot of stuff pretty easy; wish something like this was out when I was in high school.

(* On a side note, my writing blog is down for the moment. It was getting inundated with bots, and just pointing the domain back to the registrar was my lazy way to try to get them to go away. It’ll be back at some point.)

Let’s Plays!

With my powerful new computer, I’ve been able to record some “Let’s Plays” on my new YouTube gaming channel, SirDragonWizardMasterLord, the dorkiest name I could come up with.

Probably won’t make them regularly, but it was fun to try, and I was very impressed with how well my computer could handle them; capturing video didn’t slow the games down at all, even with the games’ graphics settings at their highest. Nvidia’s GeForce GTX 970 is just awesome.

Inside Out’s blatant plagiarism!

I saw Pixar’s latest, Inside Out, earlier this week. It was a great film, but as I mentioned on Twitter:

In Search of Strong AI

While trying to work on my novel, my mind sometimes turns to mush and I can’t think creatively, at least not in the way that novel-writing calls for. So I began a journal with which to chronicle my thoughts and explorations as I search for Strong AI. I would love to live to see Strong AI achieved; who wouldn’t?

My short term goal, however, is to create a computer program that can teach itself to play chess (or any rule-based game) in such a way that we can observe the rules that it learns. As far as I know, no one has achieved this. Chess engines focus on number-crunching algorithms, using the computer’s ability to calculate quickly to its advantage rather than trying to simulate how a human would learn things. But if we can figure out how a human learns the game, I think the algorithms involved would be far more useful to advancing human knowledge than number-crunching algorithms created specifically for the game. I want an algorithm that creates algorithms.

Anyway, I have written up my explorations so far in my new little journal. You can download a PDF of the journal here. It’s a bit too long and clunky to post as a blog entry. I hope that as I continue to explore the subject, I will write and upload more journal entries.

Not sure anybody else out there is interested in the subject, but I’ll put it out there in case anyone is curious. Join me, and together we will rule the world.


In search of the best idea ever

Last month, or the month before (it’s all a bit of blur), I started programming what I thought could be a general purpose AI engine.  And it works!  It can find any pattern that is computational, and thus solve any computationally defined problem.  But it’s unfortunately completely inefficient for most interesting tasks.  If it wanted to learn to play chess, it would try to solve the entire game.  While mathematically possible, it would take far too long to compute and take up way too much memory to be of any use, what with combinatorial explosions and all.  And I don’t even know how to define a creative task, such as drawing or storytelling, in any computationally useful way.  So I really didn’t achieve much.

But the seeds of obsession were planted.  How does the human mind do it?  What am I missing?  There must be an answer, because humans do it.  This is the “AGI problem” – AGI standing for “artificial general intelligence” – the elusive AI system that can do anything, not just model a solution to some specific traditionally-cognitive task (which is what most of the “AI field” focuses on).

While I knew nobody had the answer (at least not that they’re revealing, otherwise we’d be living in a very different world), a trip to the bookstore seemed like a good place to start.  And there I found David Deutsch’s recent book: The Beginning of Infinity: Explanations That Transform the World.


It’s a fascinating book, one of the most fascinating books I’ve ever read really, even though it doesn’t give me any of the answers I’m looking for (Deutsch obviously makes no claim to have solved the AGI problem).  At the heart of it, Deutsch argues that it’s our human ability to create explanations that gives us the ability to think about all the things we do and make the sort of progress we do.  Of course, we’re still left with the question: how do we create explanations?  How can we program computers to do the same?

To quote Deutsch from this also fascinating article:

AGI cannot possibly be defined purely behaviourally. In the classic ‘brain in a vat’ thought experiment, the brain, when temporarily disconnected from its input and output channels, is thinking, feeling, creating explanations — it has all the cognitive attributes of an AGI. So the relevant attributes of an AGI program do not consist only of the relationships between its inputs and outputs.

The upshot is that, unlike any functionality that has ever been programmed to date, this one can be achieved neither by a specification nor a test of the outputs. What is needed is nothing less than a breakthrough in philosophy, a new epistemological theory that explains how brains create explanatory knowledge and hence defines, in principle, without ever running them as programs, which algorithms possess that functionality and which do not.

Without understanding that the functionality of an AGI is qualitatively different from that of any other kind of computer program, one is working in an entirely different field. If one works towards programs whose ‘thinking’ is constitutionally incapable of violating predetermined constraints, one is trying to engineer away the defining attribute of an intelligent being, of a person: namely creativity.

Clearing this logjam will not, by itself, provide the answer. Yet the answer, conceived in those terms, cannot be all that difficult. For yet another consequence of understanding that the target ability is qualitatively different is that, since humans have it and apes do not, the information for how to achieve it must be encoded in the relatively tiny number of differences between the DNA of humans and that of chimpanzees. So in one respect I can agree with the AGI-is-imminent camp: it is plausible that just a single idea stands between us and the breakthrough. But it will have to be one of the best ideas ever.

So I’m in search of one of the best ideas ever.

Melody Generator for the web progress…

Finally fixed this blog’s recent comment-spam problem by adding a CAPTCHA plugin.  Duh.  Why didn’t I think of that before?

Anyway, my Melody Generator for the web is slowly coming along.  It mainly consists of two pages.  First, the "Compose Melody" page:


Above you can see all the functionality the melody generator should have.  Right now, none of those options actually work, except for the “Melody name” field and the “Compose melody” button.  The rest still needs to be programmed, which is what I’ll be working on for the next few weeks or so.  After you hit the “Compose melody” button, the melody plays as a MIDI file at the top.  If you like the melody, you can download it right away, or you can save it to your Library.

And that’s the second page, “My Library”:


The library section should be pretty self-explanatory; you can go through your list of saved melodies and download them, play them, or delete them.  You’re allowed to save up to 5,000 melodies, though if you actually compose that many, you are probably somewhat insane.

After I finish programming the functionality for the melody generation options, I’ll have to program some user-settings (such as the ability to change your password).  Not sure how long it’ll take, but I’ll keep the blog updated.  Maybe.

Web-based melody generator?

Grrr, my poor blog here has recently been getting overly abused by the WordPress comment spambots (of the “You, sir, have valuable information here, I will check back for more of your posts” variety) of which quite a few are slipping past WordPress’s Akismet plugin. I don’t want to have to moderate all the comments to prevent the spam from showing up, but if it doesn’t die down, I might have to do that, at least temporarily… for now, I’m just manually deleting the spam. How annoying…

Anyway, about that melody generator… I’ve heard some interest from people who don’t have Android and therefore can’t use my melody-generating Android app, so I’ve been hoping to make a web-based version of the program for some time now. And since I recently redesigned the algorithm to be much more efficient computing-power-wise, I think it should now be perfectly feasible for a server-side program to handle it. I don’t plan to abandon the Android update I’ve been working on, but it may be delayed a bit; a web-based melody generator just has a far larger market. So I’ve been working on that for the past couple days, really brushing up on my web development scripting skills. It will still be a lot of work, but I look forward to seeing how it will turn out.

Melody Generator 2.0 progress update

I have just about finished rewriting the main algorithms of my Android Melody Generator, though I have not yet reprogrammed all of the features. Here’s a ZIP file with 100 MIDI examples.

A few things about the examples:

– I am forcing every melody to end on the tonic
– I am forcing every melody to end with a perfect cadence
– All the melodies are 8 bars in length and in 4/4 time
– 8th notes are the smallest notes I allowed

Do the melodies sound better? They’re not on a human-composer level yet (well, I guess it depends on the human in question), but I do think they sound better than what the current version of the Melody Generator can produce.

The other big advantage of the rewrite should be the generator’s speed. I haven’t tested it yet on my phone, but my computer (which is, granted, a lot faster than a phone) can crank out over 1000 melodies a second. This is quite good, since my ultimate ambition is to have the generator crank out Mozartean symphonies, so we can’t have it wasting much time coming up with short simple melodies.

I am not exactly sure when I’ll upload the update to the Android market; there is still plenty of work to do. But I’m currently aiming for sometime in April or May.