This entry was originally stored in my personal blog engine, but has been imported into WordPress.
Finally, I’ve settled down and started writing my first RPG engine. I’m using enchant.js to do so. Although I used this engine in my first two games, I didn’t make use of any of the “advanced” features of the engine, such as maps (to lay out game fields), sprite animation, etc.
– It’s largely used in Japan. This means that much of the documentation, tutorials, and existing games are in Japanese, and not very accessible to me. They have their own site dedicated to their engine’s games, located here, and as you can see, most of the games are in Japanese.
– It’s being aimed at younger and new programmers. This is their main selling point. They have their own online, in-browser IDE for 9Leap, completely devoted to creating small, mobile-sized games for their site. They offer free sprites (but only for “non-commercial” games, so I won’t touch them). They host contests for college students. They tout its simplicity, and talk about how “25 percent of people can become programmers.”
If you create little one-scene casual mobile games with canned graphics and plugin-powered features, yes, maybe you can create a game quickly. Anything more complicated, though, and you need some coding skill. Currently, enchant.js is indeed very basic if you look at it as a game engine. However, in the hands of a decent programmer, that’s all you need to build some pretty impressive things.
As far as evangelism goes, as anyone who’s worked with me knows, I collect programming language books. In that, I’m old-fashioned – for me, online tutorials can supplement but not replace a solid reference book. My main sources when learning enchant.js were:
– The Web Game Developer’s Cookbook, by Evan Burchard. This book demonstrated enchant.js had the capability to handle an advanced, RPG-type game, which I would not have thought based on what’s available online. Unfortunately, the relevant chapter inadequately grasps the object-oriented nature of enchant.js
– HTML5 Game Programming with enchant.js, from aPress. This is the “official” enchant.js book I mentioned earlier, and it’s a very good reference. I can’t adequately express my delight on having the API in print instead of always having to scroll through it online.
– How to Make A Simple HTML5 Game With Enchant.js. This tutorial was really good in explaining the OOP-aspect of the engine (I rewrote a lot of code after reading this).
As for my project, I’m adopting a somewhat unusual approach. Both my co-workers and these books warn that it’s a bad idea to try and create an “epic” game. So, instead of writing the game first and programming around it, I decided to create the features first and then move the game into that. This is forcing me to create very generic and reusable code. An engine I can hopefully tweak and re-use again and again. I’ll be posting this at GitHub when I’m done.
For now, I’ve managed the following functionality, coded in a general enough way that it can be mixed and matched easily.
First, a basic game map screen, which can be customized as needed. It’s robust enough to handle whatever tile-based map you need, conditionally handle when the player moves to other maps or scenes, etc.
I am unhappy that enchant.js’s “map editor” isn’t very useful – the book mentioned it, but following the link led to a mostly-unused, limited editor that’s pretty much limited to enchant’s sprites. The only reason it exists, it seems, is to satisfy book-buyers who were promised the editor – the page specifically states that you probably didn’t navigate to it unless you were referred to it by the book. Even with it, I had to spend an inordinate amount of time manually editing the long arrays needed to lay out these screens.
For NPC interaction, I didn’t want to rely on the traditional “text box” that pops up on the game map when you talk to them (and which Burchard provided the code for). Instead, I took advantage of one of enchant.js’s better features, the ease in which you can create different scenes. I’ve managed to create a scene class so generic that, once you pass in a scene ID, the data in a central JSON object takes care of everything else, including all text and graphics.
The next features I plan to add are:
– A central JSON object to handle overall storyflow. This is how I’ll handle all the game point booleans, among other items I’m thinking of adding. I need to minimize in-code conditionals.
– A means of simulating meaningful NPC dialog. The solution I’ve decided on here is pretty innovative, and will probably be the subject of my next blog entry.
– I’m still unsure if I want to add any combat or shop system (again, apologies to Evan Burchard, who again provided complete code for this). I know for a fact that I don’t want to create the traditional menu-based, turn-based combat that’s been in every Final Fantasy game since the first. But what can I replace it with? Well, there’s the question. As for a shop system, I’m shying away from any feature that even remotely suggests grinding, and the money has to come from somewhere. Overall, I might concentrate on solving puzzles.
The puzzles are another thing I’m thinking through. Ultimately, I’d love to add a series of Professor Layton-type puzzles, but that’s beyond me for now.