Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
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.
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.
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.