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.
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.
No comments:
Post a Comment