Hello,

The purpose of this thread is to announce a "Big project in its early stage", which at the moment doesn't have a name. The directory where I store my code is called "ArmyBase", but that's already taken, so I'm open to suggestion. Or else, I might just call it "Clotilde", because I think it's a nice sounding name.

I'm not very comfortable with going public with it yet, as it is in a very early stage of development, but the discussions in the "NetERC website - input requested!" thread prompted me to announce it. I will copy paste and adapt the relevant parts of my post there below for ease of reference.

It will probably be of interest to many of us, and more than any others, to ACs and ERCs.



So here's the story :

I was setting out to make an experimental list. Well, I don't know if you're like this, but I found it very painful, lots of layout issue and I'm not an expert with any stuff like Acrobat or Word or whatever.

However, I know a thing or two about web development (or at least a scattering of techniques useful on the web), and I am the kind of lazy guy who would rather develop a software from the ground than fight with the layout options of MSword.

So the idea is to make a web based application, that could store complete lists for EA, from units and weapon statlines to lists with all their options, point costs, etc.

Then, from there, the goal is to be able to :


--------------------------------------------------------------------
Desired features list
--------------------------------------------------------------------

1) have a system of permission per user and per user groups

2) export data in a format that would be understandable by the application itself, and human-readable enough that someone web-competent could develop his own stuff based on the data.

3) import data in the same format.

4) display, on a web type interface (i.e. : web pages) :
- - - - > unit listings in a way akin to what the current lists are doing, with full stats, background/lore/fluff text and possibly image galleries
- - - - > lists with core, support, allied choices and upgrade, i.e.: Lists as usable as those published
- - - - > quick reference sheets

5) generate and export the same "view" (unit datasheets, army lists, quick reference sheets) in a paper friendly way (web based probably at first, PDF as a probable future feature)

6) Allow people with sufficient permission (i.e.:ACs ) to modify and add data to official lists, so that updated lists are available instantly

7) Allow people with sufficient permission (i.e. : hand-registered taccommers) to create their own lists, as variants, house lists, experimental stuff, etc.

9) More THINGS ! There are lots of THINGS that could be plugged on such a structure, from army-builder style sub-applications to statistic extraction from lists to whatever. Of course, one cannot ever plan for too much THINGS.

And there is no "8" because I don't want sunshades in my list, dammit !



To get there, here are the development phases involved, in rough order :

--------------------------------------------------------------------
Plausible developement Phasing
--------------------------------------------------------------------

1) Define the SQL data structure (the way things are stored in a database). This is mostly done but I will require some help to make it better, I will expand on it later in this post.

2) define the structured data format I want to use in the application (only just started, relatively straightforward, JSON will be the obvious choice for me)

3) develop SQL procedures and various middleware to :
- - - - > produce the aforementioned data structures from the database
- - - - > be able to insert/update the correct stuff in the DB, taking the aforementioned structure.
Nota : this stage is likely to be the most technical and the most time consuming; this also imply that if I get this done, motivation and time won't be nearly as hard to get to do the rest. import/export functionality are almost free at this stage, since the structured JSON will be the export format.

4) implement the user & permission system. This imply development of the SQL structures and associated code (relatively straightforward, but tedious and meticulous task if we don't want this to have gaping security breach; luckily, a good friend of mine is a security expert: that might help); after this stage, the stuff can basically go public (it still wont be usable for most interesting applications)

5) develop a basic display interface. Basic means ugly.

6) develop a basic input interface. Basic still means ugly.

7) refine such display to make it nice to look at, comfortable to use, and produce alternate layout for printing and use on paper. (fun stuff for me)

9) expand from there (Add link to galleries, quick references extractions, celebrating with champagne, etc).

And there is still no "8", because.


Now, back to reality, where am I with all that ? Well, the basic data structure is defined (like, I have my MySQL structure ready), I started to define the intermediate data structures (step 2) and that's all for now.

Here's a colour code so I can update you with informations :

done : means I'm basically done with that stage, barring a few adjustments if later needed.
doingdoingdoingdoing : I am currently working on this, the lighter the most advanced.
To do : Still to be done.

This was a relatively short phase, but it is a very important one. Basically, the complexity of all the other stuff is conditioned by the choices I make here. The simpler the database, the easier the code, but the less powerful the application.

This structure I have now can do everything I found in marine, guards, eldar, ork lists, but i still have to re-read all the lists carefully to make sure that Clotilde (please help me find a name, or Clotilde it will be !) can manage all that is currently existing.

Additionally, the current structure can cope from the start with some stuff that are not used anywhere but could be interesting (for example, making you buy "detachment packages", for example paying n points and getting a marine company, which is 4 detachments : 2 tacs, one Assault and one dev).



Keep in mind that this is all a LOT of work; also keep in mind that while motivation is strong at this point, I have a consuming RL job (I'm an IT engineer if you didn't guess), a wife, a son, like to do long roller-skating sessions, have started rock climbing recently, have armies to paint, and am an avid reader. So, stuff might move very fast or stall, and I would be a liar if I made any promises, or even give you an ETA on all this.

What I can commit to do is keep you all informed on my progress, and answer any questions you might have on all this. I'll start a thread about this as soon as I have the time and a name for the project.

I'm open to suggestions of course. For a name, for neat ideas, for fun ideas, whatever.

If you have a pet thing you think would be nice to do in a list some day, please tell me. It's much easier to make it possible in the early stages.


Oh, and by the way, if you don't realise all the usefulness of such an application (I realised I kept somewhat technical in my wording all along), it implies things like instant army compendium compilation, indeed a living army compendium with no compilation work involved, clearly labelled status of lists (be they netEA official, FERC official, EUK official, experimental, fanlists... indeed as many status as one might want), instant and automatic formatting of variant, house lists, reference sheets...

Now, since my original post (in the other thread), I got a very interesting idea suggested by Elsmore : I didn't even care to think of it myself, but of course the first possible way to make this more interesting is to make it more generic. In the sense that you could use it for other games. Strange as it might seems (it is usually a kind of knee jerk reaction by people in my profession in presence of a neat development project), I didn't think of it myself.

Well, right now what I have is pretty suited to E:A, and pretty specific to it.

I could make some critical area, like the weapon statline (what is a weapon statline made of ?) and the unit statline generic without much hassle. In fact, that is the first thing I'll do the next time I open my DB structure.

If you need some explanation to understand this underlying structure I'm babbling about and the constraints it implied, read on. If you already know, jump after the two "quote" blocks.


About unit structures :





About lists themselves :




Now, why am I explaining this stuff (which is probably obvious to some of you anyway, and possibly still obscure for some others) ? Because It would be nice, with minor adjustments, to be able to use the same tool to store, compile and use unit datas and lists for other games, like, say, BFG or Seeds of War for example.
I don't know the Seeds of War system at all, I must confess I just downloaded the rules and will finally take a good look at them.
It's been a long time since last I opened the BFG rulebook (but I will re-read it soon).
As far as I know, there is no specific system for Exodus war yet.
I'd really like to be able to manage an Adeptus titanicus game.
Netepic would be cool.
I will have to at least take a look at other games I don't know anything about but their names ("Command horizon" for example).

Now, as the database structure is making assumption about what is a list and how it is structured, so If I don't know what to accommodate for, I might make something that might have been usable for another system, but isn't.

I have no interest in Wh40k and most 28mm games, and of course this application is much more useful for games that are still developing, or being maintained by a community.

Keeping in mind that my main focus is still E:A; as making things really generic is usually multiplying the complexity (ease and duration of development and maintenance) by a large factor while still falling short of the full lists of the stuff you wanted to achieve, if something is too hard to accommodate, I simply won't.

Concerning lists structure, I think I will have to make sure to be able to allow some kind of modular list building (I suspect some sort of bug lists will want that one day or another, haven't reviewed all the nids list around yet ), but do you have anything specific in mind that you would really like to be able to do, or a game you think would be really nice to be able to manage that way ? I will need some explanations about the structures involved, or better and simpler, downloadable rules are the easiest option.


I got SOW Force organisation charts under my eyes at the moment, trying to see if they can fit in Clotilde as it is. It actually might, though the rendering would probably be a bit wordy. I will keep posting as I become able to assess what is possible.


After I'll have reviewed the possibly interested game systems and the ideas I encourage you all to suggest while I still can take them in account easily, I will be able to estimate which generalization fall into the "freebie" category, which one fall into the "elegant and easy", which goes into "lots of work and complications" and which are in the "How to make my own start-up" category.

I will try my best to answer the questions you may have, assess your suggestions, and keep you posted on my progress.


Reminder again : I won't give any ETA, since it is all a LOT of work, even without trying to go beyond the scope of E:A, and I can't decently commit to anything. So the "When" questions are likely to receive very poor answers at best.


Ah, And help me find another name for it, or Clotilde it will be, and then we'll have to find what C.L.O.T.I.L.D.E. might possibly mean. It might very well be quite harder than to find a better name.



* that mean Clotilde will be able to display the "1 core = n support" restriction, or the "no more than 30% points in allies" one, but it won't understand what it means. I will probably want to add it at a later stage, to be able to get an "army builder" feature, but it isn't done.

As far as list building goes I'd suggest you chat to Adam77 if your not already.

Good luck with the database design...I'd say you would be better tailoring a database for each game rather than one for all as a) they won't share common attributes and b) it will honkingly big in no time at all!

If you want a hand with the database design then drop me a mail. I've 10 years experience in database design in the workplace.

I can't offer a huge amount of time, but I cam certainly help out and perhaps put you in contact with additional resources who might have more time.

_________________
Tom Webb
Author Page: http://www.newtonwebb.com
Twitter: http://twitter.com/thewebb
Facebook: http://www.facebook.com/thenewtonwebb
Instagram: http://www.instagram.com/thenewtonwebb

So basically a blank army-list where an AC canput in all the contents needed for it and every list would have the same lyout?

_________________
We are returned!
http://www.epic-wargaming.de/

I'm counting 30 tables as things stands, without making the statlines generic yet, but it will only be 2 more tables, so I will definitely do it. This fall into the "elegant and easy" stuff.
In that count, I include junction tables but nothing pertaining to users, groups and permission system, nor anything like versions and history management (stuff 'id really like to have at some point). some of the structures are a bit funky and will imply a bit of head scratching when coding, but I think I will be able to handle it.

I will hold off the next steps until I have reviewed all the E:A lists and at least taken a look to other games list structures.

So far, things looks good : I only have minor adjustment to make to do all the core lists I've looked at
Codex Marines and several other marine lists I looked at, Ghazgkhull and most other ork lists, all eldar lists with minor adjustments (funky aspects transport options wording), dark eldar and necrons with minor adjustments, nids (9.2.1) are good.

Importantly, most of the "minor adjustments" I have to make are the same, so things should be relatively easy so long as I am content with E:A. Outside of E:A, SoW organisations could be managed with the same kind of adjustments, and a different display at the end (but this is both easy to do and irrelevant to the base structure).


I think I will consider redesigning the list part of my base to manage the restrictions from the start. There are different kinds of these, so far I can see :
- core/support/sub-support, "pyramidal" kind of arrangements
- "at least n" and "up to n" kind of restrictions at formation level
- "up to percentage of your points may be spent on..." kind of things.

I will need to have the most complete list of these before making this choice; most prominently, I'll have to try to think of some "modular" type of construction that can't actually be reduced to these kinds of restrictions (it's amazing what wording and layout can do). I think Adam77 might be able to help me there.

Nota : upgrades (or "extras") are stuff that can be added to another formation, and they are already managed in a satisfying way from what I can see (i.e : it can cope with everything I found so far). As well, "at least" and "up to" restrictions inside the formations (upgrades, "may include up to 3 wraithlord for n points") kind of things are already in, as well as the ability to get "packages". I have to make room for some more "notes lines" which are sometime heavily used (necrons, Dark Eldars) at the least. The part that is not really structured is the way "core formations" and "support formations" are related to each other. The categories themselves are already in.


"Big" isn't too frightening. Space is cheap. Complexity is my main preoccupation, because time isn't. There is a certain amount of tables that forces you to ponder for very long before doing even something simple. I'd like to stay below that threshold. We're not there yet, notably because "what a unit is" and "how a list is built" are still separate problems. I'd like "user, groups and permissions" to be able to be taken separately from "versions and history" as well; this will hopefully keep the complexity in a manageable state all the way. If I can't keep such aspects somewhat separate problems, it will be much harder to split the work into manageable bitz.




At the moment, no problem with the DB design, actually once I'm set and what will go in there, I can do it fast enough. The part that will be the most technical and tedious will be when I will be designing the procedures to extract and particularly to insert stuff easily. I am trying to start that as soon as possible, since I'm much more confident and used to everything else involved. But thank you ! It's nice to know I may ask for advice/bit of help if I'm struggling somewhere (it will undoubtedly happen one day or another).

When things will have progressed a bit, I will see about making some of the code public if it is of interest to other. I can't guarantee that it will be the cleanest or the most elegant stuff ever, though

Kind of that yes.

To go from the ground up, on one hand, one could declare special rules, weapons, and units, that have some stats and such and such weapons and such and such special rules.

On the other hand, one could declare detachments that are made of such and such units and optionally such and such additional units for such cost, can take such and such upgrades, as core, support, allied choices or whatever.

Then one could see the result as a formatted unit listing and army list. The system will understand such things as alternate weapon loadouts, normal, big and 'uge warbands, transport options, etc, and display them accordingly (i.e : in a very similar way to what the current lists available look like).

In the end (low priority but easy to do and the kind of stuff I actually enjoy doing, so if we get there it will be done for sure), we'll have many layout options, for example to have a background and layout specific for each list, illustrations, background for units, etc, and of course the possibility to have alternate layout like black and white, no background for printing, or condensed "quick reference sheets". The structure of a list has to fit in the base, and as I said all the existing lists for E:A will fit (because I will see to it if they don't already, and because actually there are very few different building principle at work), as well as Seed Of War lists as far as I could check; but the way one display it (the rendering "layout") can and will have a lot of options and possibility.

If you look at the current lists, a unit is displayed in a quite standardized way, and the "unit listing" part is very straightforward.

Then the list itself, which display the costs, and the restrictions on what you can have, are displayed with quite some variety (one might suspect this is partly due to the unspoken "it has to fit on one page" rule) but the underlying structure is actually pretty standard. Clotilde will be able to offer many layout options for the list itself, as well as the unit listing.

My goal is to be able to AT LEAST render the lists the way we have them right now in paper.



Now, about who can do what.

Things like special rules are pretty well defined. There won't be a lot of those added once the existing ones are in. Weapons will see more movement, but if you already have "bolter", "Missile launcher", "chainswords" and "bolt pistols" defined, chances are that you may already make a few new marine infantry unit without having to input any new weapon.
Similarly, if you want 8 stand strong tactical formations for your homebrew chapter, so long as "tactical marines" are defined, you don't have to do much.

The key word in my first example is of course the "one" in "one could".
well, who is one depends on the status of the weapon, unit or list we are looking at.
If something has a status like "Net:E.A Official", only the Net:EA comity guys can modify or input new stuff. Net:EA Champions can only modify or add new stuff in their own list.

But basically, anyone (registered in the base, and quite probably by hand since I don't want no f**cking bots in there), say any taccomers who care to ask, can create his own lists, units, special rules, whatever. Core army if you want. It will have a "fan" status. He will be able to use official stuff if he wants (using existing bolters or tactical space marines, for example), but not to modify it.

If he HAS to have bolters that have a 15cm AP6+ shooting attack as well as the basic official stats, he can do it by creating his own bolter, internally called say "bolter_blacklegion_test" and use it in his list.

Then, if he want to go public and receive community opinions, he ticks a check box, creates a thread as usual on the forum, post a link to his list and wait for answers. If the project is gathering attention, he will still be able to get some kind of stamp of approval from rule comities and army champions by the usual way ("experimental list", "Net:E.A approved"...), and his stuff become available to others who want to use them in their own homebrew, while he retains (he or the peoples of his choice) the permission to make it evolve and whatever.

When stuff is made public (one ticks the "make this list visible to others" box), everyone can see the result. There could be various levels of publicity when a list is only visible to its maker, to a group of registered user, to all registered users, and completely public.


The idea is to offer ease of development when designing or maintaining any list, from Official to home-brew. The way things stands, you will be able to make it public or private and have a single person, a group or even a voting comity to modify things. It will encourage units or weapons to have the same stats everywhere, because it will be less work to do, but it won't enforce it. We could still have the usual imperial marauder and the WE variant included in the Krieg list for example, or different tactical marines stats for different lists.

I hope it helps clarify things, but do not hesitate to ask all you want. Explaining stuff helps me make things clearer in my mind as well.

I realise my formulation wasn't clear enough : The help I need is not with the SQL and DB design itself; what I need help for is to see types of lists structures that are not used in E:A yet, but could be nice to have, be it for future development or to be able to use the same facility for another game (BattleFleet gothic, Seeds of War, or any game of your choice).

Explain me your idea (preferably in the thread, but PMs and mails are OK if you want to be sneaky) or show me the stuff (point me to downloadable rules and force charts/lists), and if I can do it without doubling the workload, I will.

At one point, probably around the end of the week, I will "freeze" the DB structure so as to be able to proceed with the rest. Get your suggestions in while you still can !

For example, I have made it possible to force the player to buy several formations at the same time, as "packages". No existing E:A list does that, but I thought it would be nice to be able to do it.

I'll stay out of the design, for the good of humanity. I can throw out names though.

The two that come to mind are "Architect of Fate", which is perhaps too GW specific for a cross-system builder, or "Armored Bastion" for some good ol' TacComs incomprehensibility.

_________________
SG

Ghost's Paint Blog, where everything goes that isn't something else.

I've just realised this morning listening to the radio that what I though was just an absurd little joke (taking a random first name) was in fact in absolute bad taste. I never made the connection with the current hurricane (the name was possibly subconsciously suggested by the news).

My sincere apologies to everyone I might have offended, I plead stupidity.

I will edit the previous posts with another first name ASAP.

"Armoured Bastion" certainly would make a fine tradishunal codename. We'll see what else come up

Looks like a really exciting project