Store voxel type data in XML or Java classes?

Question

So, I want it to be very easy to create all the entities of my game and for other people to come in and do the same. I was thinking I could just let the users/myself create an XML sheet the stores all the properties of each block (Like a Terraria or Minecraft voxel) and add Lua scripts that are referenced in the XML for additional functionality of any of the blocks.

I'm starting to think It would just be easier to let the user create a JAR file full of classes for each block. And then that JAR file could easily be used to get all the blocks. It'd just be interesting to reference all the blocks by a block id without storing all the classes by ID. Or I could give each class a static id. But that's not important.

Okay, so my short question is what are the pros and cons of storing all the the different types of blocks as classes versus in an XML sheet with Lua for additional functionality?

UPDATE: I will probably go for the only use Lua approach. I found about it just recently and it appears like it could be the best method as of right now for me!

Answer 1

The first thing to do here is consider yourself. You, just like your end users, will want to add functionality to blocks. So, think how you would most like to add the functionality. Most likely, if you find it simple and efficient, then the modders will too.

JAR Files

• Pros

  • More possibilities for functionality.
  • Linking in of 3rd party libraries.
  • Lots of tools (potentially debugging).
  • Compiler (can flag errors before you run the application).
  • Possibility to link in 3rd party libraries.

• Cons

  • More complex (less accessible to the layman).
  • Security concerns.
  • System API needs to be clean and well documented.

LUA

• Pros

  • Easier for the layman.
  • More control over potential functionality.
  • Less security concerns.
  • Forces mod code to be in a human readable format (users can read and extend mods they like).
  • Can be easily reloaded at runtime.
  • Option to provide an in game command line environment for writing/testing scripts during gameplay.

• Cons

  • Limited extensibility compared to JAR files (fewer possibilities for functionality).
  • No compiler checking for errors.

Note

If you add functionality by writing straight to your code base then you may simply want to consider just going open source. If you do go open source then user's won't be able to pick and choose the mods they want or share them as easily, but you may also find that the community is willing to help further develop your game in more ways than you currently have in mind.

Answer 2

First of all, your focus should probably be elsewhere. Have you ever made a game that attracted just a modest user base before? If not simply making a game that people want to play in the first place is a plenty steep goal.

Supporting good moddability is hard and time consuming. It takes some experience that you probably don't have and require a more frameworkish structure.

For all the good things there is to say about planning ahead and doing things right from the beginning, you easily risk such concerns getting in the way of actually making a game.

Go with the easiest solution. For all the cases where that leads you to go back and redesign there will be many more where you avoided needless extra work. With time you should learn to spot the cases where a more elaborate approach is required.

The Java classes offer by far the easiest option to implement, and while some XML files may be easier to edit you have to offer some pretty elaborate bindings in order to make that LUA script anywhere near as flexible as an option for modifying the native Java code.