Java has a very useful modules system that allows you to write "plug-ins" for an application using the Reflection API. It can be used for a variety of things and in terms of gaming, it can be used for these:

Quests

New Gamemodes

New Entities

And a lot more stuff, just to give you an idea. Note that this isn't restricted to gaming, and has even more uses in software engineering itself. There are a few reasons why we would want to use this plugin system. First of all, you don't need to write your own scripting language or whatever for something huge. Then, its really quick and fast to set up, and it makes a whole lot of sense.

However, there are some disadvantages as well. Since Java uses the JAR format, it can easily be modified without security like obfuscation and hash checking with the internet. Also, if you are going to open your API to developers, you have to make sure public fields are public, private fields are private, and protected fields are protected. Otherwise they get access to a whole bunch of things that can ruin the game. That's about it for explanations. Now let's get to the real code.

So, first, we have to make an API. Most of it will probably already have been done. I will be presenting a small quests system in this. In my project, I've defined a Quest class as follows:

I included a QuestRunner class(shown later) in the Quest file so the class can add events to the event buffer in the QuestRunner. Events in this term means like things to do like display text, move a character here, start another event, start a battle, etc.

For simplicity's sake, I've also defined a QuestController class, that "controls" the quest, or just organizes them:

I've only given enough information in the class so an API can be written with it, not its actual functionality, just to note. Now, I export it as a JAR(not a runnable jar). Unselect all the files, and then I go select only Quest, QuestController, and QuestRunner. This will only make these classes available in the API. So now I export it, and I now have a quest API that can be used in another project.

Note that I the only reason I export as a JAR is for simplicity here. You can export your entire project and the API will have everything available, but usually you'd need to make sure all the visibilities of fields are correct.

So, now, you can make a new project, maybe name it "Quests". In here, make a new class that extends Quest. Do stuff in it, add to the storyline etc. Now you can export it as a JAR including only what classes you need.

Now, back in your main game, you can make use of this JAR file you exported with a URLClassLoader object. Basically it allows you to open a JAR file and get a class:

The real advantage of systems based on dynamic loading is that you can change behavior at runtime without restart. To do that you need to use one or more classloaders. As an example you can do something like this (Fake mixins by inheritance part) to allow for total conversions. Using a virtual filesystem probably makes a lot of sense as well.

@deepthought: I'd say that for quests to not be boring, you have to be able to add behavior...but that wasn't my point...my point is where and how.

Take say killing a specific monster/NPC, which might progress a given quest. How is that different from launching a cut-scene or performing any additional uncommon thing? It isn't. You need to be able to script (potentially in a data-driven way) events that occur.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org