Particle Fleet Next

[knucracker]

First, thank you for those that took a quick look at the steam CW1/2 beta releases.  It helped provide confirmation that the sky wouldn't fall on the day of their release.  I know it seems anti climatic when you try something, and then apparently nothing much happens.  But validation checks like that all fold into an actual release and are part of what allows it to happen.

So, CW1/2 are now on steam and I can return my attention to Particle Fleet and the remaining things yet to do for that.  These are the big areas:
- Ship preview display
- Ship sharing database
- Custom modules
- Minor bugs and other issues as reported.

What I'll talk about below are custom modules. I'm going to openly discuss the issues and problems associated with them and see where it takes us.  So if you are interested in that topic, read on.  Otherwise, get back to smashing the particulate!

--
A custom module should allow a player to create anything from a weapon to a ship modification module.  So a laser, a cannon, a shield, a reactor.... those are all existing modules but custom modules should allow for the same kind of things.

That means that custom graphics and scripting have to be supported.  PRPL will of course have to be extended as necessary to support anything the module might need (apis to modify a ship for instance).

Now here's the catch.  A custom module, as I have been thinking about it, has to be stand alone.  That means it can't depend on any other scripts on a given map.  A module must be something that could appear on a ship, zero or more times and on zero or more ships. It can't rely on anything else being present in the map.  So it can't use the custom image database.  It can't assume there are other scripts on the map.

This would put irritating limits on how I implement support.  There is an immediate name space problem with scripts.  PRPL scripts currently assume there are N of them on a _map_. If there are two custom modules employed on a map and the authors both named the scripts "MyCustomModule", then that is a name collision.  So, I will likely have to prefix all module scripts with a GUID, or just auto name them as a GUID.  In fact the name of the script probably isn't really important as I may also limit the number of scripts per custom module to 1.

The number of custom images per custom module will also have to be limited.  They would be limited to probably 8 (or so) at 128x128 resolution.  These images have to be associated with the custom module itself.

So, if you assume up to 8 images and 1 script per custom module you can imagine what has to be done to make various modules.  If you want to make a 'shield' type module, you likely would only need 1 image for the module.  In the one script you might do things like consume energy from the ship, and manipulate the ship using PRPL calls to do so.

If you want to make a beam weapon, like a laser, then you likely will need 3 images.  One for the module base, one for the module barrel, and one that will be used to make a beam.  The 1 script will have to manipulate the barrel and beam images as necessary to make it aim and fire at a target.

If you want to make a projectile weapon, it would be similar to the beam weapon.  Except now the 1 script has to manage the apparently moving projectile.  That's 'ok', but it does have one drawback.  If the module gets destroyed then the projectiles go with it. 

The reason for these issue is that creating a core to represent the projectile and then assigning a new script to manage that projectile depends on having more than 1 script available and also knowing the name of that script.  This returns back to the name space problem and having to have more than 1 script associated with the custom module.

Now, all of these problems are predicated on the idea that custom modules must be standalone and divorced from a map.  Right now some folks implement custom modules, but they are of course tied to these brilliant little frameworks that have been created and incorporated per map. Planetfall was doing this during the beta I believe. 

So you might say, "whoa... let's slow down here and not get into all of these problems by not requiring modules to be standalone".  That's a good position, and any developer out of grade school would get behind it.  But, it comes with another problem; ship sharing.

If I want to make a database of ships available, then I can do that in a fairly straight forward way right now.  I could probably have a system going in just a few days.  Ships already persist as independent critters.  Ship sharing is mostly a UI and database problem since I have already do the rest of the work. But, without standalone custom modules, there can be no custom modules on a shared ship.  The modules built into the game work, and I could even add more modules in the game.  But a strange custom module, that of course depends on a given map's scripts to function, can't work.

I like to think of myself as a pragmatic coder.  It's a necessary skill for survival in this business, especially solo game development.  I like 80% solutions, as becomes apparent for anyone who has known me for more than 5 minutes.  If I think pragmatically, that means the following:

Implement the ship sharing database on ship definitions as they are. Modest amount of work, big payout. Do not spend a month implementing stand alone custom modules, and 2 months working out the issues. Instead, work with those interesting in making them on two fronts. One, extend and improve PRPL to meet the needs of those that want to make map-bound custom modules (the current model for making them). Two, add capabilities to the game and solicit ideas to add to the game itself zero or more modules.

In other words, make it easier and add capabilities to PRPL to support the current model for implementing custom modules (map bound). If there is a good idea for another module that numerous people want, I will add it to the game as a built in game module.

Doing that does not stop me from implementing the ship sharing feature quickly, nor does it interfere with the ship preview implementation.  It does leave custom modules as something that is map specific, but I can perhaps add PRPL features to make that easier.  And as a final level of support, if the community can define one or more new modules, I'll add them into the game proper.

[stdout]

I think your pragmatic solution is the right one. The big payout in a short time frame makes it the right choice, in my opinion. The number of custom modules that are good enough to warrant being used on numerous maps would obviously be modules you'd want to add directly into the game.

I'm really looking forward to the ship sharing feature. There have been a lot of great ships designed and I'm looking forward to seeing them used on more maps.

[Prof]

I second that response. I would be quite happy with an easier way to PRPL modules onto ships, versus custom module implementation.
Perhaps some specific commands designed around modules?

[planetfall]

My 2 cents:

There needs to be a way to lock cores to a ship so that the ship treats them like modules, incl. splitting energy evenly with them and the other modules (using the UnitEnergy APIs?) and moving them whenever the ship moves. Currently they lag a bit behind moving ships, a little like guppies. Also like guppies, it's possible for a ship to move between the module and the ship in the Z-order. (If you disregard everything else in this post, please still consider this a guppy-based bug report.) If this is done, the only thing that would potentially give away that a module is custom would be the lack of range circles, and I'm not sure of a good way to do that one.

There also needs to be a way to test if a ship blueprint is indeed correct. For instance, the way I made custom player ships recognized is by name. A player could use a custom fleet, name a ship "MAKER", and have a maker from the bginning of a mission. This would seem to be in the spirit of fleet customization, except for the part where it could be a completely different design and maybe the spots where the maker modules are supposed to go are already occupied by other modules.

There also needs to be a way to add custom modules to spawner-made ships with similar ease (their names can't be grabbed by PRPL.)

A compromise could perhaps be a "custom string" in the ship editor. This would just be a string that could be assigned to a blueprint and read from a ship that has the blueprint. An example string might be "sniper:5,1;thingy:2,4" Whatever module-initializer script is in the map would then call GetShipCustomString on newly built ships, run the requisite string splits and spawn the requisite modules. This way you could still design and share ships with custom modules, but those modules would only work if that specific module is implemented in the map. It may also be beneficial to set a custom preview image so that ships with custom modules will preview correctly, though something tells me that will lead to ludicrous PRPL hash strings.

While it isn't as urgent, there's still the unresolved (?) bug of no text on screenmode cores that I haven't seen on your todo list in a while (either you've fixed it for an upcoming build or forgotten about it...). If that was fixed, it would go a long way towards creating UI on custom modules. I know at least one person has complained about the sprayer in daisy chain not being turnoffable.

Now some QOL things in the ship editor. It would be really useful to search the ship editor by name, and filter by module like is possible for the map editor. Something else that would help is the ability to tag ships and search for all ships matching or not matching given tag(s). One thing I've done is make multiple "factions" (sort of) each of which has recognizable ships. One has ships split down the middle, one has wings and lots of engines, one is very asymmetrical and blocky, etc, and I might be making a map where you play as one of these factions and want to filter to only one, or to filter only to ships made by one author, etc.

It'd be nice if holding a certain key in the ship editor displays the ship hull coordinates under the mouse, to use for custom module positioning.

Anyway, I am sure you have too much on your plate already. I'll leave you alone and procrastinate on my own projects.

[GoodMorning]

Agreed, with the below thoughts.

Here are my thoughts on ship/map interface...

• 
  If the script is intended to work with a specific map, then it can use globals to check for some flag(s) in a once block.
  
• 
  A hard-wired implementation of something like planetfall's custom module interface would be good. Naming issue mentioned above.
  
• 
  To what would you bind the "Self" command? Would you need ThisShip?
  
• 
  Could the script be able to check for the presence of another script in the map, for such things as cannon shots? "NAME.prpl" MapHasScript? Or...
  
• 
  Given that custom modules require attaching one script to the ship, could this be extended to two or more concatenated scripts? AddModuleScriptToUnit being a namespaced sibling of AddScriptToUnit, using only the script(s) which came with that module.
  
• 
  One thing I have missed is GetPositionRelativeToHull, and also SetShipInternalEnergy. These will become even more useful with custom modules.
  
• 
  One final note: We are going to want some form of UI. Mentioning while this is under discussion.
  

[knucracker]

I've added a line to my todo that points to this topic... so I won't forget and will implement some of these things.

So yes, if there are APIs that make it easy to anchor a core to a ship (by instance or type) and the game engine takes care of the rest (like positioning and z order), that would probably ease things a lot.

For an instance of a ship type, I might be able to ID ships by a generated GUID.  As in the hull and module data all run through MD5 to spit out a GUID.  Change anything on a ship, and it is a different ship type.  The chances of a hash collision aren't anything we have to worry about, ever.

So I'll finish up the changes to the game to show ship build stats and loadout preview, then fix a few of the bigger bugs, and that will be the next beta build.  Then I can take a look at the PRPL additions it takes to make life better for custom modules.  Along with that, I'll start looking at the ship sharing interface (like where in the UI it should be).

[GoodMorning]

One thing I forgot to mention:
Before beginning on a new and large addition to PRPL complexity, it is worth noting that we still are partially unsure of how to use the existing commands. Yes, I'm talking about the wiki (again).

[Sorrontis]

Sorrontis nods in agreement while reading this whole thread.

[stdout]

Virgil, are you wanting suggestions on how your ship sharing database will look and operate? I have some ideas but if you're not working on that yet, I'll store them for another time.

[knucracker]

It would be best to hold them for a tad... Right now I'm finishing up the ship loadout display and build state stuff.  After that I'll roll out a 1.0.3beta.  Then I'll start looking at both prpl and ship sharing stuff.

For ship sharing, I'm mostly interested in _where_ in the UI it makes the best sense (all things considered).  Is there an online browser that gets its own top level screen and you can pull ships into your local database?  Is it a mini browser that you find only when you are building a custom fleet at mission start?  That sort of thing.  Where it lands will depend on use cases and implementation time and complexity.

[stdout]

You told me to hold my ideas for a tad but then asked a specific question about it, so I'll answer.  ;D

For ship sharing, I'm mostly interested in _where_ in the UI it makes the best sense

In the game editor, click on "Add ships" on the right.

You have two tabs: Stock and Custom. I'd suggest a third tab for "Community" and in there have a similar browser like you have with custom.

For authors who create ships, they create a ship, add it to their local database. Then in the tab menu on the right, where their new custom ship shows up, there might be a button for "Submit" which submits it to the community ships database.

[yum-forum]

Nice idea!  :)