Zixradoom
Zixradoom

Reputation: 3

Ideas on how to design an interpreted program?

Some background.

I am currently working on a distributed system in Java. The code is mostly all hand rolled, and consists of a client server frame work and an application to be served. The application is for running a turn based system.

The design issues.

The application is supposed to be almost completely configurable. The base of the program is a processor that will process objects in a linked list style, moving from one object in the chain to the next until the processing is done. I have already written a simple blackjack game with it, nothing fancy just something to implement the API. The problem i am having is that i am unsure as to the granularity of the objects. I know i do not want to write a programing language style architecture, example, classes to represent add, subtract, and other languages constructs, but i want the architecture to be flexible enough so that a user can specify a program, within its capabilities, in a file and have this construct instantiate the proper classes link them and then run the sudo-program.

Any suggestions and/or ideas would be helpful.

Thanks in advance, Zix

Upvotes: 0

Views: 67

Answers (1)

jefflunt
jefflunt

Reputation: 33954

This kind of thing is pretty tough, mostly because the requirements are so broad. When we look at successful, real-world platforms that are highly flexible and configurable it's too easy to think they they started that way, or that you could design them from the beginning to be that way.

This is not the case.

The reality is more about picking a subset of problems. In your case, not just a turn-based games in general, or even turn-based card games, but blackjack, followed by some other game (bridge, poker, whatever), and then you build upon that.

Let your application (and its features) grow based on actual needs, and not the set of problems you think you will need to solve. Focus on the problems that are in front of you as you try to build actual games. Over time, you'll figure which parts to abstract (and which parts not to abstract), and in the mean time you'll actually have something to show for it.

Go the other way, and you'll have an interesting idea, an API no one uses to solve actual problems, and a bunch of code but no games. Don't fool yourself into thinking that no one has tried to build the platform for turn-based games. It's been tried 1,000 times. The reason it doesn't really exist is because building platforms without clear goals (i.e. a set of requirements leading to a finished game) leads you to software without a clear use.

That means they don't get used, games don't get built, you never hear about them, and therefore they aren't successful. Successful, flexible platforms have a long list of successful applications built using them, at many stages throughout their lifetime.

Upvotes: 4

Related Questions