Ambrosia Garden Archive
    • Online Plugins


      RESTful API for plugins

      I'm making a game engine that will mimic and extend the EV engines. For those interested, I am making this in the Unity3D IDE.

      One feature of this engine is the ability to get data from "plugins" via a RESTful API. I am creating this in Ruby on Rails.

      This has a few benefits which include:
      - that a developer can modify the plugin and know that the player will have the latest version of the plugin.
      - teams can work on a single plugin at the same time.
      - resources can be re-used across multiple plugins.
      - web browsers are free and most people are comfortable using web forms.
      - players can choose a plugin without having to download and install it manually.
      - all plugin data is stored in a database.(the benefits of this are too numerous to mention here)

      I'm in the process of going through the EV:Nova bible and creating tables and fields based on the respective resources and fields, but have noticed a few things which I'd like some input on.

      1. A number of fields are of a one-to-many relationship. i.e. a resource can be related to one of more other resources. eg. a govt can have up to 4 allies.
      My question is; Is it a limitation of the nova file format, that a govt can only have up to 4 allies, or is it a logical necessity? Is there a reason it couldn't have more? If it's not logical for a govt to have more than 4 allies, I would create the govt table with 4 ally fields, if it is I will create a a separate table to record this relationship.

      2. The EVN game constants are fixed(I believe a plug developer cannot change these, hence constant). Are there any constants I should keep and which constants should be defined by the plug developer?
      Here are my initial thoughts:(?-means they shouldn't be constant, but defined by the plug developer)
      ? Max Ships In System 64
      Max Stellar Objects 2048
      Max Systems 2048
      Max Ship Classes 768
      Max Stellar Classes 256
      ? Jump Distance 1000 pixels
      Max Weapon Types 256
      Max Outfit Item Types 512
      ? Max Beams On Screen 64
      Max Dude Types 512
      Max Ships Per Dude 16
      Max Govts 256
      ? Max Explosions On Screen 32
      Max Explosion Types 64
      Max Missions 1000
      Num Mission Bits 10000
      Max Cargo Types 256
      Max Person Types 1024
      ? Max Shots On Screen 128
      ? Max Asteroids 16
      Max Asteroid Types 16
      Max Nebulae 32
      Max Images Per Nebula 7
      ? Max Simultaneous Missions 16
      Max Disasters 256
      Max Fleets 256
      Max Ranks 128
      Max Junk Types 128

      3. Should I try to mimic EVN scripting or should I replace it with a modern/standard scripting language? e.g. lua

      That's for starters, anyway. I have more, but need to get past these few hurdles before I continue.
      Thanks for your input, and ask me anything that comes to mind.

      tycho

    • @nick-kirkwood, on 04 June 2013 - 04:33 AM, said in Online Plugins:

      1. A number of fields are of a one-to-many relationship. i.e. a resource can be related to one of more other resources. eg. a govt can have up to 4 allies.

      I think that is because each government can also have a class, and same-class governments are allied. The class adds another field, but allows you to create one government with different 'arms.' Here's the quote from the EVN Bible:

      Quote

      Class1-Class4: Allows you to assign this govt to up to four different "classes", which are simply arbitrary groupings of govts that you can use to flexibly assign allies and enemies. Two govts of the same class are not inherently allied unless one of them has that same class number set in one of its Ally fields.

      Sounds different than I described it, I always found this setup kind of confusing. Really, the goal is to be able to set up a linked government; which in turn is setting up an AI force that gives the appearance of one unified group while actually behaving differently depending on which arm you're dealing with.

      Quote

      2. The EVN game constants are fixed(I believe a plug developer cannot change these, hence constant). Are there any constants I should keep and which constants should be defined by the plug developer?
      Here are my initial thoughts:(?-means they shouldn't be constant, but defined by the plug developer)
      ...

      Those were all engine limitations for performance reasons. If you can increase them and still get good performance across all reasonable platforms, good. The developer should be able to change them up to a max value you set to keep performance reasonable; maybe give them a warning if they go over it so that, if this is as enduring as Nova was, the future devs can change it to be within the performance capabilities of future machines.

      Quote

      3. Should I try to mimic EVN scripting or should I replace it with a modern/standard scripting language? e.g. lua

      Not sure what you mean by that, but I liked the plug editing setup in EV/N. If you mean allowing more programming options (maybe make a new AI or something else outside the current bounds), go ahead and maybe someone will use it.

      I'd like to be able to edit plugs in a spreadsheet, in addition to in the nicely formatted editor(s) that were/are available (I'm a fan of ResEdit's setup, though it's hard to get a hold of the tools to make that work anymore). Doing large amounts of editing (ala TC's) is tedius in a normal editor, but in a spreadsheet values can quickly be checked against each other and changed globally.