Skipping Ahead

This is not good. I haven't finished testing the game I defined for my IntFiction and I have already begun rewriting the engine's client app. In the course of coding the engine I learned better ways to do things and am painfully aware of problems that came up late in development.

One idea I had never thought of, for some reason, is using multiple 'input listeners' (Essentially main game loop). In the original client there was one primary input loop. Any special modes like fughting or admin had to be driven by a mode variable that had to be checked all over the place.

In my new code - special modes are handled by their own inout loops, and you don't leave that loop until that mode is done with you. Each mode can easily have its own prompt and may be nothing more than a bunch of wizards or an entire sub parser in the engine.

I am also hoping to do more of an on-demand pattern for data loading. I'm hoping this will make room loading much faster than the first client.

Uh Oh. Trouble.

I have been working on the text based game engine for quite a while now. Coding it and building a large demo game for it. The demo game has been a great testing tool. It covers many situations that would come up in game authoring.

Everything was going great. I started a basic website for it in preparation for distributing it.

Then I decided to make a trap. A simple timed event. If the player is in the room long enough. DOOM. Things were bad from the start. After all this time, after all my testing I realized I was doing the timed event, time passage counting wrong. Ok no prob. Fixed.

But then when the player died, it kept describing the Room AFTER the die message. This was my first clue that something serious was going on.

There was a processing stack conflict. Events were being described first, which isn't incorrect, but dying was an event. So I stopped any further descriptions cuz the player was dead.

When I began work on NPC movement, since I hadn't tackled that yet, the real seriousness came to light. Player movement, NPC movement, object changes. Which should be done first? What if action needs to happen first and that action's description come last? None of this came up until the NPC movement piece was added.

So now I'm reworking all of the parsing logic. Breaking it up into pieces so I can choose which parsing is being done when. This is a complete reworking of the core functionality of the engine. It's gonna get real ugly before it gets better.

Passing Stuff Around

For a LONG time now I have been working on a Java-based console IF game engine and corresponding client app. This project came about when a friend kept bugging me to ditch TADS and write my own engine, so I can get the games out onto the web or mobile devices, as well as the idea of making it multi-player.
I brushed him off for a while, but as time went on I became frustrated with the limited platforms TADS can be ported to. And I found that although amazingly powerful, the TADS language was not terribly enjoyable to build games in. I DO appreciate its 'programming-like' syntax but I didn't find it fun.
So in spite of the amazing robustness of existing IF engines I decided to tackle my own.
It's been an amazing learning experience. I haven't learned terribly complex Java wizardry but I've become painfully aware of development paradigms. Being self-taught I've always just coded away, never really thinking about paradigms and the philosophies behind them, their pros and cons etc.
After a few failed starts at the IF engine I started to think about structure and how I wanted to accomplish things. I tried to go full OOP and quickly learned first hand why its detractors or mind skeptics criticize it. I did want to have objects since that is how the games are defined (I'm using XML as the definition language, since it's easy to nest elements and attributes), but I abandoned making them self contained. So I pass around the game object and other objects I need.
So far it has worked well. I have it built enough to move around the game world, fight enemies, take and use objects, check various conditions etc.
The engine is structured well enough to make extending it fairly painless and easy to debug. However every now and then a fix or addition involves gaining access to pieces an object currently doesn't have. That's where the nightmares begin.
I have to break a bunch of method calls and put them back together. But for the most part I'm happy with it.
In time I hope to make it better. Minimize or do away with all the hot-potato-ing. As I get better solutions to these problems may manifest. When they do I'll share them here.