The ultimate goal of the Kirbj project is to allow regular visitors to Reality's End (and, y'know, other sites, too, I guess) to create their own games in some fashion. The simplest solution would be to just release libraries; I plan on doing this, but how many people know Java? Or rather, how many people know it well. Ah, that sure does make the number drop!
Currently, every level in Kirbj is hard-coded into the applet's source. Applets have such high security on them that normal I/O routines are out of the question, and this has other advantages, too. It is much easier to express what you want in the form of the code itself instead of some sort of intermediate language. A lotta the stuff has to be written twice like that -- once to do it in Java, and once again to do it in whatever other method is used. Things get quite redundant, and quite redundant, and moreover, quite redundant~!
Besides, why make a pseudo-language when its code will be as subject to change as the Java code? The easy solution: a code generator!
Things are pretty standardized in Kirbj as it is. A normal game can be created from a special default applet subclass that just fills in generic handlers for most things. Unless a game has a specific gimmick, this suits most purposes (or, at least, it has thus far). Besides a few graphics, only the levels differ from game to game. That is the idea of this project's code reuse, after all.
Problems arise in the current methodology whenever changes need to be made. If the location of an object like an enemy or a door were specified and more scenery were to be inserted (or some was deleted), the coordinates for the object would be thrown off. Hel, just changing the scenery itself could be a chore.
Scenery is just a big ol' byte map; that seems to be the easiest way to express an X by Y field that I have ever seen. Each value corresponds to a specific image and set of properties -- definitions which are often reused for several similarly themed rooms in a level.
Enemies, doors, and other events are a bit more tricky. In order to make the game as robust as possible, every Room object just runs a generic, abstract check every tick. Of course, not every single room in the game is going to be its own subclass; that would be stupid. A standard room subclass allows lists of generators to be created which manage the playing field's contents. Managing this list has been streamlined into a very sequential format which is very easy to understand.
The sole purpose of this software, as it currently stands, is to be more usable than plain code. This means a simple point-and-click interface: dragging, dropping, and very visual. Some thing are currently a bit cryptic (like clicking on a placed enemy to change its direction from left to right), but hey, it serves its purpose.
The main issue I was concerned with was inserting and removing rows and columns. Everything to the right of a column or below a row gets shifted in correspondence with the change. Not particularly difficult to code, but incredibly useful compared to my old, mostly debugging methods.
While it is not necessary at this stage, creation software will eventually be needed for third parties to make levels. And while it is not necessary, it will certainly make releases easier. It'll have to be made eventually, after all, so why not now?
One of the basic problems with it currently is that a very low-level symbolic code is used as a go-between for the level maker and the Java. The Java source itself is complex, and while it is possible to squeeze it out of the level maker, putting it back in for editing would be cumbersome. It is much easier to parse some symbolic strings, which can be ready to run with some little more than a few regular expression substitutions. After all, making a DHTML page to parse code is something I have some experience with -- just ask the RE League and the Battling Dragons RPG!
This thing has probably been eating up most of my time working on the Kirbj. It was not supposed to be made for the original release of Save The Day, but after Thanksgiving -- its intended date of debut -- passed, there seemed to be little reason not to put this together quickly.
But of course, nothing is ever quick.
Apparently, applets are finicky about the clipboard buffer used for copying and pasting, which I had intended on being the original transfer medium. That meant I had to use a text box instead, and unless you use standard Java form elements for everything in an application, things will suck badly.
And they did.
What is very interesting right now is that a lot of the contents for the next game (or really, the first game as the previous one barely counts) are being seen by the public for the first time in these squishy screenshots.
No discussions exist yet for this. You can start one if you would like.
|Copyright © 1999-2019|