Beanstalk Update 1

I wrote last week that I'm beginning a new side project which I'm calling the Beanstalk Adventure Kit; a text adventure framework in Java. My goal for this week was to dip my toes in the planning stages and begin figuring out the basic structure.

I managed to do this lightly. What I've decided is to divide the codebase into two major parts: a runtime environment (user interface) and the actual game framework (which I'm calling the "game engine", but I'm not sure that's technically correct). This division was simple to decide on. The runtime environment will include the interface and, eventually, include other user-facing actions like saving and loading game states (this is a long way away). The game engine will contain all of the building blocks of a game - classes and interfaces for developers to use to construct their games. Again, this much is easy - text adventures all have the same basic components and piecing those together isn't terribly difficult.

But I was left with a fundamental problem. How do I make the two pieces "talk"?

The dilemma is keeping the framework code and an individual's code separate. Anyone working with my framework should, under no circumstances, have to edit my code to create their game. What I need is an easy way to display things to the interface and get commands from the player.

The first way I thought of is to have the runtime environment have a class that someone can use as a reference to the interface. Then, the game engine can offer a similar class to represent the entire game that someone would add the pieces to. But the problem with this, I decided, is that anyone working with the framework would have to figure out their own means of running the game. It would be up to them the manage the "talking" between their game and the interface. Not only would that be inconvenient, but it would make it impossible for me to define much structure for the rest of the game engine because I would have no control over how the game would be run.

So then I decided the better way to do this would be to have the game engine handle it all. By structuring the framework classes correctly, I can make it easy enough for anyone to output to the UI and get commands from it as well, without them having to care about interacting with the runtime directly. The setup for a game will ultimately look something like this:

As development of Beanstalk unfolds, this is bound to change a little bit, but for now this is how I'm aiming to make it work. There's a lot left to work out and I've had development patterns suggested to me that may help. But as I said last week, if I spend too much time researching the "right" way to make this, I think I'll miss out on a valuable learning experience. It's almost inevitable that my final product will resemble one development pattern or another, but getting there on my own will better prove its worth and help me understand it more than researching first.

My goal for next week is simple... Write some code. Just a little bit. It's time to dive in. By next weekend I hope to have the basic packages set up and a simple UI in the runtime built. My IDE for this project will be IntelliJ and the GitHub repo will hold the project file. Watch the repo to see when the code hits.