It seems there is enough interest to discuss the planning stages of KDYv2. As the title might betray, there is a lot of technical details going around, so be so warned.

Right now, I'm trying to decide on a database design for how content gets stored. There are currently a few patterns in my head that I'm debating between:

Pattern 1: 'Items' Table and Detail Tables

The 'Items' table will hold things like the ID of a piece of content, it's name, who created it, when it was created. Things that are pretty universal. There are then going to be Detail tables where specialized data sits. Let's take three examples: Ships, Upgrade Types, and Damage Card Classes (and I chose these for a reason). the Detail_Ships table will hold things like the Hull Value, the Speed chart, the silhouette id, the upgrade bar, and so on. The Upgrade_Types will hold data like the path to the SVG icon for the upgrade. The Damage_Class table ("crew" and "ship" in armada) won't actually need to hold on to any pieces of data, because all the bases are covered on the common table (I actually dislike that inconsistency - if it appears in the common table, it should have a detail table).

Pattern 2: Independent tables

Every class of content is contained in their own table. Ships are in their own table, Squadrons, Upgrade Types, Dice, etc. The problem with this is searches and the front-page feed. Union-ing a bunch of tables in order to find the most recently created content is... problematic. There are also some implications when it comes to the API that I'm working on for TTS. Essentially I'd like to have the TTS integration be Type Agnostic. Meaning that I want to make it so that you can import item id 4568 and the importer will know it's a ship instead of having to tell the importer that it's a ship.

Pattern 3: 'Items' Table and Detail Tables as well as Meta-items Tables

Basically the same thing as above, except the only thing that gets stored in the Items table are things like Ships, Squadrons, Damage Cards, Upgrade Cards, etc. All of these have a detail table that can be joined with the Items as above. Other things, like Upgrade Types, Damage Classes, Silhouettes, Dice, and so on are actually stored in separate tables independent of the Items table completely. This is actually how KDY functions right now. My problem with this is that the Items table is actually fairly good thing to have if I want to list out "here's all the most recent content", but this model doesn't work well for including things like Dice in that feed. That's why I have to make a bit of an announcement when I add support for a new Upgrade Type or Keyword. You guys don't see that.

Pattern 4: Full Distro aka ALL THE TABLES!

This one I'm still forming in my head. This takes pattern 1 to the extreme. Instead of a central items table where some content fits into it and some doesn't, imagine having ALL pieces of content on their own table, but link them together using a very very simple IDs table. The IDs table would have only a few fields. HashID, ContentType and ContentId. You send a HashId, it then looks that up, decides what table to refer to based on ContentType and pulls all the information from (mostly) one table using the ContentId.

The issue remains, however: searches and feeds get hairy. I could make it so that ALL searchable fields (like an Upgrade Card's Text or a Squadron's name) get stored in another table that can be searched, but I worry about having data in so many places. HOWEVER, this may end up helping quite a bit when it comes to internationalization. Imagine having the same card in multiple languages, for example. This means that a single Squadron Card could have multiple entries in the Text table for it's name - one for each language that it supports. Issue with this: multiple data types. Ace Squadron special text would have to be stored in a different table than Squadron Names because one needs to be a text field while the other is a smaller varchar... That's not a deal-breaker, but it does complicate things.

To fix the "latest content" feed issue presented by the similarity between Pattern 4 and Pattern 2, I would create an Activity table. When someone adds a Ship card, it get's added to the Activity table along with a few other important values. This would allow for people to subscribe to specific feeds. Want to track what I'm doing? Click on "Watch FoaS" and now stuff that I make shows up on your home page. Is that to Social-media-y? maybe, but I kinda dig it.

I feel like this is the most complicated execution, though. There's a lot of moving parts and it's a bit daunting.

14 minutes ago, FoaS said:

This would allow for people to

You missed an ending to that sentence.

I don't know how easy it is to implement, but I tend to prefer (assuming I understand it correctly) Pattern 4. But really only because personally I like having everything categorized as much as possible. I don't know how I would approach the issue of multiple languages though.

Rendering content

Whenever you hit "save ship" or what have you, an image of the bit of content gets created. For upgrade cards, its the card - for ships, it's the ship base AND the card. Renderers are what tells KDY how to generate that image. For those curious on a technical level, I use a program called wkhtmltoimage. It takes a website and essentially takes a screenshot of it and saves it as an image. This is all server-side so it's pretty consistent, if a tad CPU intensive.

Every piece of content has at least 2 Renderers: for Upgrades it's the High-Quality and Printer-Friendly card front. For ship's it's the High-Quality Dial, High-Quality Card Front, Low-Quality Base, and Low-Quality Card Front. Even factions have their own renderers: HQ Ship Card Back, LQ Squadron Card Back, LQ Token, HQ Token, etc.

Looking forward to KDYv2, I want to remove some of the rigidness of the current rendering system. I'd really like to make it so that people can have KDY render a card how they want. If you want to make a renderer that outputs a card to look like the Stele Open style cards or the Alt-Art cards that FFG does? But that alt-art will be an issue.

Suppose you want to make a new Squadron card renderer called "Data Minimalist" one that just uses icons wherever possible and doesn't do a whole lot of text unless necessary. Now should you be stuck using the same art for "Data Minimalist" as "KDY HQ Default? Probably not. It may end up being that you CAN'T use the same art because the on-card image sizes are different - maybe the images on Data Minimalist are designed to take up the entire card.

Just thinking of the UI implications of this is... staggering. Multiple image uploads, selecting what image to use for which renderer.

On Genres.

A lot of folks have been using KDY to create cards for non-Star Wars things. More power to them. But it does get a little cluttered. Imagine having to dig through a bunch of WW2 Aircraft Carriers to find the Ton-Falk carrier, a SW ship. A genres system could serve as a good way to drill down into what you're looking for and to keep things a little more neat. So what's the problem?

Well, for one: What should have a genre attached to it? Clearly, Ships, Squadrons, Upgrades, and what not should, but what about Upgrade Types? If I'm working on a Star Trek ship, and I want to make a Warp Core upgrade type with the idea that I'll be making a series of Warp Core upgrades, then I should be able to do that. But now, someone who creates a Star Wars ship can see "Warp Core" as an upgrade type, which clearly doesn't apply. So clearly Upgrade Types need to have a genre.

But now if I were to create a new ship, Star Wars is the default genre, fair, and if I change the genre to "Star Trek" by way of a dropdown box, then the options on the possible icons to add to your upgrade bar should change too... And so should dice types, and Ship Silhouette options - and mind you if the Ship Silhoutte changes then the TTS Default Model selector will also change, and if that changes so will the TTS Default Paint Job selector - you see the chain reaction that could happen.

Well, that's annoying, because it means that's going to be AJAX calls and a lot of Javascript to create new elements and painful. So do I move to a multi-page wizard for ships (which gets into how do I store that temporary info and handle a change in step 1 when you're on step 3) or do I fortify and just write the dang javascript (which I hate, mind you)?

This actually presents another structural issue: Visibility and what is "Official"

Right now on KDY there are 19 upgrade types, 13 of which are official, 6 of which have been added by me for myself or the community. When you go to create a new ship, you can see all of them. Now imagine if 20 people added 3 new upgrade types. now that's 79 upgrade types you'll have to sort through just to find the one you want. I could categorize them, based on whether they are Official, Community-endorsed (like Cargo and Grav Well by DiabloAzul), or if you made them.

Let's assume we categorize those upgrade types by exactly those values: "Official", "Community", "Mine", "Other Users" ... well, we just established above that Upgrade Types should be filtered by Genres... so what happens when I select "Star Trek" as my ship's genre... suddenly "Official" is empty because "Warp Core" Isn't, well, Official.... But If I created a "FoaS-verse" genre, and added a "Sensor" upgrade type to that genre, that should mean that "Sensors" should appear in the Official list when I'm creating a ship for the FoaS-verse genre?

But won't that mean we have multiple Star Trek genres floating around because everyone has their own idea on what Dice or Upgrade Types should appear for the Star Trek genre? Maybe I like the idea of "Photon Torpedo" being it's own federation-only upgrade type while someone else would rather see a more generic "Heavy Weapon" upgrade type. Maybe I want to do an SFB version of Star Trek with Lyran, Hydran, and Tholians whereas someone else wants to have Cardassians and Borg.

Stuff get's complicated, and quick.

15 minutes ago, FoaS said:

Stuff get's complicated, and quick.

Man, organizing this stuff sounds like so much fun, implementing it in Javascript not so much. If it were Java, maybe I could have helped somewhat. . . .

The following is pure speculation, in an attempt to provide ideas, in case they haven't occurred to you:

Is it possible to simplify it a bit? For existing game systems, have

'Official', i.e. those that are introduced by the company
'Community', i.e. those that are officially endorsed, like your DA example
'Yours', i.e. those that are created by the user
'Other' everything else.

Then, for non-actual game systems (like what I assume Star Trek to be?), just don't add anything to'Official'. Then, if a given classification is empty, don't display it as an option*. Will that not work?

That way, every component has a 'genre' and 'classification' attribute. If a given classification set is empty, don't display it as an option. When doing queries for displaying, check the genre, if it applies classification and display it in the appropriate section.

*Alternatively, you could have an attribute that determines whether the game system exists, and not check for empty sets, but associate either the 4 classes or 3 classes depending on the bool value of the Exists attribute.

9 minutes ago, GhostofNobodyInParticular said:

Man, organizing this stuff sounds like so much fun, implementing it in Javascript not so much. If it were Java, maybe I could have helped somewhat. . . .

The following is pure speculation, in an attempt to provide ideas, in case they haven't occurred to you:

Is it possible to simplify it a bit? For existing game systems, have

'Official', i.e. those that are introduced by the company
'Community', i.e. those that are officially endorsed, like your DA example
'Yours', i.e. those that are created by the user
'Other' everything else.

Then, for non-actual game systems (like what I assume Star Trek to be?), just don't add anything to'Official'. Then, if a given classification is empty, don't display it as an option*. Will that not work?

That way, every component has a 'genre' and 'classification' attribute. If a given classification set is empty, don't display it as an option. When doing queries for displaying, check the genre, if it applies classification and display it in the appropriate section.

*Alternatively, you could have an attribute that determines whether the game system exists, and not check for empty sets, but associate either the 4 classes or 3 classes depending on the bool value of the Exists attribute.

It is fun, whilst being a mind-@#$%

I've never tried building a Java program on this web-host - I don't even know if that is an option. Given that I pretty much think in PHP most of the time, I feel like it's just easier to go with the tried and true there, despite the reliance on client-side Javascript for some aspects.

I like your solution: make it so that on Unofficial Genres the Official option on Upgrade Types doesn't even appear... That is simpler and fairly elegant. I can also make it so that Genres can be classified as Official, Community, Public, Unlisted or Private - and any component related to the Genre can be set to anything that doesn't exceed the visibility of the genre itself.

Official can only ever be set by an admin. Community can be set by Contributors. Public means that it will appear in the "Other" field unless you're the one who made it (at which point it appears in the "Yours" field). Unlisted means that anyone can see the content on it's info page, but it won't appear in any options (unless you're the user who made it, at which point it appears in "Yours") and Private means that no one can ever see it except for the person who made it.

Unlisted is very handy for components like ships and squadrons, but not necessarily for things like Upgrade Types - so I'm debating on that one.

I may do a "favorites" list, too. This way people can say "I want quicker access to these 5 upgrade types that these 3 regular users made, but I don't want to have to dig through everyone's public upgrade types"

To be honest to me the most important improvement would be to switch to a more pretty card template.

(double post)

26 minutes ago, DScipio said:

To be honest to me the most important improvement would be to switch to a more pretty card template.

Not for nothing, Scipio, but that came off as significantly rude.

I've clearly worked my butt off, and will continue to work my butt off, to make and improve KDY and this came across as very dashing to that. Now if you have some constructive advice for the rendering, I'm all for it, but saying "it's just ugly" doesn't fly with me.

Continuing on rendering,

I use a program called wkhtmltoimage to render cards. The basics of it is that there is a special rendering page on the server that looks like the final card and wkhtmltoimage takes a screenshot of that image.

What's this mean to you? Well, the way I see it is that when you create a new renderer, you'll be able to set parameters for each element much like you would with styling an HTML page with css - because that's basically what you're doing. You can style all sorts of block elements with background colors, borders and text with italics or weight, even be able to change the font to something supported (as an admin, I can add more fonts if people really want them).

here's an example of the proto-type renderer building system that I've made. These attributes are just a fraction of what I intend on exposing, but for each element that exists on a card, this is what you can expect (more or less). Additionally, you'll get a live preview of what the parameters you put in will mean.

Being one of the resident Luddites, most of this goes over my head. However, would it be possible to save personal formatting settings once set. So once I personalised a card, all others I made would use the same format? Maybe card style settings would be better as part of user profile settings. Perhaps with an import to my style button to change someone elses card to your existing format.

9 minutes ago, cynanbloodbane said:

Being one of the resident Luddites, most of this goes over my head. However, would it be possible to save personal formatting settings once set. So once I personalised a card, all others I made would use the same format? Maybe card style settings would be better as part of user profile settings. Perhaps with an import to my style button to change someone elses card to your existing format.

As another Luddite I think this would be neat.

Sort of. My plan is that you can, when you create a card, choose what renderers to use. it's multiple choice, so you can choose to have one card rendered with five different renderers. To put it another way, you would set up your renderers before hand and then when you go to create a card, you can choose what renderers to use - be it my initial renderer, your customs, a community choice (like the Stele-open style) or maybe one that someone else made and made public. It wouldn't be that hard to have a set of default pre-selected in your user settings, I suppose, but that would save you only a few mouse clicks.

Also, I'll be making video tutorials on how to make the most use of all these features, too.

That sounds great. I was just looking at the picture you posted above, and thinking that that was a lot to go through each time I made a card.

2 minutes ago, FoaS said:

Also, I'll be making video tutorials on how to make the most use of all these features, too.

Awesome. Thank you so much for doing all this work for everybody else to enjoy man.

9 minutes ago, cynanbloodbane said:

That sounds great. I was just looking at the picture you posted above, and thinking that that was a lot to go through each time I made a card.

Oh gods no. I'm not THAT cruel.

7 minutes ago, Megatronrex said:

Awesome. Thank you so much for doing all this work for everybody else to enjoy man.

I enjoy making the tools more than I enjoy the game. Not just Armada. I did the same for Minecraft back in the day. It's how I roll.

On TTS Models with a splash of 3D,

One of the reasons why I'm going through this re-write is to offer support for KDY content on TTS, which I've gone over before. Obviously, to have the full experience of using TTS, 3d models will be a thing. Now, I could just add some 3d models and call it good, but what's the fun in that? Enter in Paintjobs.

Suppose I have a 3d model of, say, a Victory class Star Destroyer. Suppose you make a ship card for the Republic that uses a VSD. Without any tweaking, when you spawn this new VSD of yours, it'll have some default texture. My plan is to have it so that you can go into KDY, and create a new texture for your ship. Now instead of making it so that you have to upload a scratch-built texture, what you'll be able to do is create a new texture using some color values and a mask texture. Think of it like painting a miniature: You start with your base coat. Now you can layer on a red trim color using a certain mask, and maybe an republic seal on top of that in white. All the while, the panels and what not will remain intact.

My primary inspiration for this is EVE Online. Let's take a certain ship from there as an example: This is the Hel

Now, if this were KDY, you could build a new paintjob something like this

To do this, you would choose a Dark Grey basecoat, add a new layer that has a gradient mask in Orange, and then add a new layer for that star symbol in near-white.

I'll be supplying a number of masks per ship at the get-go, but folks will actually be able to add their own masks (though, it's a pretty advanced process, which I WILL provide tutorials on for those who have 3d experience or want to give it a go).

You will even have the option to spawn a specific skin into TTS as a one off. Suppose you normally use the standard painjob for the Nebulon-B, but you want to spawn in something special to represent the Yavaris. You'll be able to spawn in the exact same ship id, but with a different paintjob on the fly.

More on renderers...

This post is brought to you by lots of coffee and bags under my eyes. I don't really expect anyone to really pick up what I'm putting down, but I need to get this out on "paper"

I've just made a realization when I sat down and started thinking through card renderers: these things are gonna get complex, but I hope to make it as user-friendly as possible. This is going to seem a bit innocuous, but take a look at an upgrade card with a ship-type, like a Title for example. You see how the little ship-type icon appears to the right of the upgrade type icon? Well, what happens when you have two types of upgrade icons on a single upgrade card (like boarding parties) and a ship-type? The current renderer moves the ship type icon over to the right just a nudge - all well and good, but now I have to figure out how to parameter that for custom renderers.

I think what's going to end up happening is that I'm going to write a system where you can add "containers" to your card renderers - boxes that may be styled unto themselves using certain parameters, or may just serve as layout containers - all up to you. Those containers will be be able to - well - pieces of card data to them as you see fit, and if you enter in the right settings, containers will expand and collapse to adjust for fluid content without anything being hard-coded.

The user-experience implications on this are going to be interesting to say the least, too, because as I get more complex on what renderers can do, the more I need to think to the next level on how to harness how powerful it'll be for your average user.

Tried my hand at something today at work, and it looks AWESOME!

Spinny spin spin!

21 hours ago, FoaS said:

Tried my hand at something today at work, and it looks AWESOME!

Spinny spin spin!

Sweet!

Oh my gods, using SVGs instead of Pants for web images is awesome. CSS transforms on top of that gets you some really neat stuff.

Poll time:

For those of you who use KDY, take a look at an item detail page: http://kdyards.com/squadrons.view.php?id=257 for example.

See where the item's info is listed? I'm trying to find out what would be worth keeping and what can go lower down on the page. I for one never look at the card info on the sidebar because it's on the card already (though, the problem is that some custom renderers may not show the same information on the card as others, so I can't rely on the card all the time).

8 hours ago, FoaS said:

Poll time:

For those of you who use KDY, take a look at an item detail page: http://kdyards.com/squadrons.view.php?id=257 for example.

See where the item's info is listed? I'm trying to find out what would be worth keeping and what can go lower down on the page. I for one never look at the card info on the sidebar because it's on the card already (though, the problem is that some custom renderers may not show the same information on the card as others, so I can't rely on the card all the time).

I seldom use KDY, but when I do, I go straight for the card, as I assume everything's there, and its format, being like that of Armada, allows me to take the information in more easily.