I think I could code it, making sure movement and battle forces are done according to the rules.

I've had some success in similar things, having worked on it some time ago, and in when I created an SFB damage allocation program, which tracked what were essentially a battleforce for each player in a scenario, keeping track of damage on all ships and having an intelligent damage allocator routine (ie it wouldn't ask you to hit a phaser if you'd already declined to do so).

It's not HARD to do all that for F&E, just tedious. The hard part is knowing the F&E rules well enough to not have to be constantly rewriting things, and also to know when you need to get a ruling when trying to code something rather than just pick a solution to some ambiguous bit of the rules yourself.

I don't know if you are aware Eric, but I play F&E continually and have for quite some time now, and have found a lot of things that needed clarification via rulings (which Chuck has been very good about doing). I've finally gotten to the point where I'm pretty certain about most of the rules sticky points. There are some I haven't brought up yet, but I will when necessary.

****

I don't know why you call it a simple project though. No one else has, that I am aware of.

By Randy Blair (Randyblair) on Tuesday, March 11, 2014 - 08:50 am: Edit

---

Quote:

I wonder if your next version will be down to 1 Parsec hexes though ;) (and yeah, that can be done just as easily as 100 pc hexes)

---

---

Quote:

yeah, I could do that, but would need to copy your database on my dev server in order to write the code that updates it.

---

---

Quote:

Is there any real F&E/SFB mod or future project that has rules at that level, some intermediate thing?

---

By Chuck Strong (Raider) on Tuesday, March 11, 2014 - 09:41 am: Edit

Eric: What are the 100+ data fields that make up the properties of a counter -- do you have a link?

By Eric S. Smith (Badsyntax) on Tuesday, March 11, 2014 - 11:27 am: Edit

Randy: Sounds cool. I hope to see more of it. It'd be awesome to have a granular system that would let you do huge fleet battles with F&E, or get down to individual frigates for a 2 ships skirmish.

Chuck: Not really, the best I can do is a transposed list of column labels in the excel file I build the database with. It may be hard to read, but here you go, 209 columns that are currently defined (and some of those really need split up, like cost+fighters, and all the special rules). Once the special rules and rule references all get parsed and various columns split up, I'd expect the total unique variable count for units to be 300-400. Even though a CA may not be a CV, it is a ship in the same database, and needs all those columns (even if they are all null) in order to be properly parsed en masse with other ships. On an outputted SIT for human eyes, things like "CVEG=FALSE" may be ignored, but "CVEG=True" would become "CVEG Capable;" as part of the notes section, so a SIT utilizing all 400 of these values wouldn't be much bigger, if at all, than the current one. And just a note, I also have many values from the SFB ships they mirror, so clicking on a Fed CA would show you the 4 Photons, 8 Ph1s, 30 power, etc, and show refits based on the current date (totally fluffy, not required at all, but *I* thought it'd be neato). Oh, and this doesn't have the 100 or so various factors I was planning on tracking *per ship*, like total distance moved, total battles, total times in battle line, total times crippled, damage contributed, year built, etc, etc, etc.

Example is a Federation BB:

Status =
Race = Federation
Designation = BB
Alt =
Included =
Refits =
Sequence = 1
Counter = Counter
Classification = Battleships
Area = Alpha
Timeframe = General

Factors = 20(4)/10(2)
Uncrippled Values, Attack = 20
Uncrippled Values, Defense = 20
Uncrippled Values, Scout =
Uncrippled Values, Escort =
Uncrippled Values, Mauler =
Uncrippled Values, PPD =
Uncrippled Values, SFG =
Uncrippled Values, W =
Uncrippled Values, S =
Uncrippled Values, T =
Uncrippled Values, U =
Uncrippled Values, F =
Uncrippled Values, M =
Uncrippled Values, D =
Uncrippled Values, B =
Uncrippled Values, G =
Uncrippled Values, J =
Uncrippled Values, PFT_MWP =
Uncrippled Values, DB =
Uncrippled Values, Hanger =
Uncrippled Values, SSS =
Uncrippled Values, FCR =
Uncrippled Values, Fighters = 4
Fighters, Type = F15
Fighters, # = 4
Fighters, Type =
Fighters, # =
Fighters, Type =
Fighters, # =
Cripped Values, Attack_C = 10
Cripped Values, Defense_C = 10
Cripped Values, Scout_C =
Cripped Values, Escort_C =
Cripped Values, Mauler_C =
Cripped Values, PPD_C =
Cripped Values, SFG_C =
Cripped Values, W_C =
Cripped Values, S_C =
Cripped Values, T_C =
Cripped Values, U_C =
Cripped Values, F_C =
Cripped Values, M_C =
Cripped Values, D_C =
Cripped Values, J_C =
Cripped Values, B_C =
Cripped Values, G_C =
Cripped Values, PFT_MWP_C =
Cripped Values, DB_C =
Cripped Values, Hanger_C =
Cripped Values, SSS_C =
Cripped Values, FCR_C =
Cripped Values, Fighters_C = 2

SFB_Rule = 2
SFBRef = 73
SFBProd = R5
[F&EProd] = AO
CR = 10
YIS = 175
BaseHull = BB
Hull_Size = 2


Counter Data, Silhouette = BB
Counter Data, SilSize =
Counter Data, TopText =
Counter Data, Center =
Counter Data, BottomText =
Counter Data, TopText_C =
Counter Data, Center_C =
Counter Data, BottomText_C =
OrigRace =
OrigHull =
HullType =


Conversions, Conversion1 = DN
Conversions, ConvCost1 = 27+8
Conversions, Conversion2 = DN+
Conversions, ConvCost2 = 25+8
Conversions, Conversion3 = DNG
Conversions, ConvCost3 = 23+8
Conversions, Conversion4 = DNH
Conversions, ConvCost4 = 20+8
Conversions, Conversion5 =
Conversions, ConvCost5 =
Conversions, Conversion6 =
Conversions, ConvCost6 =
Conversions, Conversion7 =
Conversions, ConvCost7 =
Conversions, Conversion8 =
Conversions, ConvCost8 =
Conversions, Conversion9 =
Conversions, ConvCost9 =
Conversions, Substitutions =

Construction, Build1Type = Build
Construction, Build1Cost = 36+8
Construction, Build1Time =
Construction, Build2Type =
Construction, Build2Cost =
Construction, Build2Time =
Construction, Build3Type =
Construction, Build3Cost =
Construction, Build3Time =
Construction, SalvageEP = 10.8
Construction, Build/T =
Construction, Build/Y =
Construction, Convert/T =
Construction, Convert/Y =
Construction, Sub/T =
Construction, Sub/Y =
Construction, Season =
Construction, Max# =
Construction, CountsAs =
Construction, BuildSlot = Battleship
Construction, Location = Capital Shipyard
Construction, On Site Assets =


Flags, Survey =
Flags, Tech =
Flags, BGSize =
Flags, GLSize =
Flags, Cloak =
Flags, EscortType =
Flags, PPD_SFG =
Flags, CmdCost =
Flags, DepotSlot = 5
Flags, PodWt =
Flags, MW =
Flags, CarrierClass = Single/Escort?
Capacity, Pers =
Capacity, EP =
Capacity, CPF = ?
Capacity, #BAM =
Capacity, Modular =
AF for EW, EW7 =
AF for EW, EW6 =
AF for EW, EW5 =
AF for EW, EW4 =
AF for EW, EW3 =
AF for EW, EW2 =
AF for EW, EW1 =
AF for EW (Crippled), EW4_C =
AF for EW (Crippled), EW3_C =
AF for EW (Crippled), EW2_C =
AF for EW (Crippled), EW1_C =
Tug EW with Scout Pods, TugEW0 =
Tug EW with Scout Pods, TugEW2AF =
Tug EW with Scout Pods, TugEW2Pods =
Tug EW with Scout Pods, TugEWLTT =
Pod Capacity, PodsStd =
Pod Capacity, PodsOL =
Pod Capacity, Pods# =
Shock, Dice =
Shock, Roll =
Shock, AF/Shock =
Shock, AF/Ok =
Repairs, RepStd =
Repairs, RepField =
Repairs, RepRapid =
SIDS, SIDS_Dmg =
SIDS, SIDS_Crip =
SIDS, SIDS_Dest =
SIDS, SIDS_SelfRep =
SMN =
RetroPt =
Raids Allowed, Standard = FALSE
Raids Allowed, Commando = FALSE
Raids Allowed, Drone = FALSE
Raids Allowed, FightersPF = FALSE
Raids Allowed, Blockade = FALSE
ReactFightersPF =
Garrison Planet =
Garrison Province =
Supply Llines, Disrupt =
Supply Llines, Block_Sup =
Supply Llines, Open_Sup =
Retrograde, Block_Retro =
Retrograde, Open_Retro =
Escorts = FALSE
Consorts =
Prod_Status = CNJ
RescueSize = 2A
CVEG = FALSE
FEGEscorts = 3
Capture =
DefensivePin = Standard
Range, Tactical =
Range, Strategic =
Range, Extension =
Alternate Romulans, Rom_YIS =
Alternate Romulans, Replacement =

UnitType = Warship
SpecificCategoryDefinition =
FriendlyName = Mars Battleship
RuleReferences = (436.0); (318.31); (318.435);
ShortNote = (431.376) Cannot be accelerated; (436.27)(544.423) Can only be repaired by same race SB/STF/PSB's;
LongNote = ALL DATA regarding DN to BB conversions is controversial and provisional and has not been approved.
Names =
SSDs =
Filename =
Version = 0.5
AsOf = 10MAR14

By Randy Blair (Randyblair) on Tuesday, March 11, 2014 - 12:32 pm: Edit

Now bear in mind that I'm a dev wannabe here, but can't you just create a property and apply it to the ship object? Like ship.mauler for instance?

Please forgive me if my syntax is not right, but what I'm seeing is a huge flat database that I'm not sure *has* to be that way.

By Eric S. Smith (Badsyntax) on Tuesday, March 11, 2014 - 02:03 pm: Edit

Oh sure, you could just have 20 or so values, and every else defined with various flags (Mauler7, Mauler10, Mauler12, Mauler7_NoShock, Mauler10_NoShock, Mauler12_NoShock, Mauler12_ShockOn6, etc).

And that is kinda simpler in some ways on data input side initially.

Then you start to code, and your code simply fills with hundreds of thousands of if statements. Want to find all your maulers, you have to enumerate through all those properties (if you defined them as part of a ship object, you are doing what I've done so that wouldn't apply) and that can get very expensive in code.

Say you want to find all the mauler factors in a given fleet of 100 ships. We enumerate through 100 ship objects, doing an "If Mauler7 or Mauler10 or Mauler7_NoShock or .... etc" which ends up being very expensive in terms of CPU cycles, not to mention considerably more bugs.

If you define each of those as a property, you can simply sum up an individual property, which is very easy to do.

Also, having all those values in a flat database lets you see issues and inconsistencies. Take a look at my SIT updates for huge numbers of minor little things I noticed that weren't consistent.

But mostly its a matter of planning. You can't just "shoot from the hip" when writing a big application like this. Its a project, it needs a defined goal, a plan, and scope. If you start small and say only "original F&E ships" are in it, you may finish it. But then you'll get seriously bogged down as you have to rewrite a large chunk of code for each new rule you implement. It ends up bogging down again.

I am betting that most of these projects that were started and failed, were that way because they implement some very basic rules in anticipation that it'd be easier just to add other stuff later, only to find that pretty much every bit of code already written has to be revisited for each update they make, and it becomes time prohibitive.

It isn't like F&E is growing much with 1 addon in the last decade, or that we get new rules every year. No reason not to take it as 1 big project, it'll be better in the end and far more likely to succeed.

Going back to maulers, lets say I define one with the following values:
# Mauler Damage
Shock Dice
Shock Total on Dice
These would be referred to as Ship.mauler.damage, ship.mauler.shockdice, ship.mauler.shocktotal and doing shock would be something like "If Dieroller(ship.mauler.shockdice,6)>ship.mauler.shocktotal then shock else noshock"

Then, SVC decides he wants a 30 point Andromedan Mauler that only has 20 damage towards the mauler and shocks on a 3d6 roll of 16+ in the hopefully soon to be released next module. If you already hard coded values you must revisit all the lines you have already coded that dealt with maulers. Having those values split out and defined in a flat file means I would have zero code changes, vs dozens if not hundreds if all you had defined with the previous mauler entries I had. And this is a *REALLY* simple example.

Oh, and don't get me started on relational databases. They are neat in concept, but those relations are better left in the code instead of ending up with dozens, if not hundreds of tables supporting your data that have to be joined and merged within SQL, when you code could easily eliminate all that overhead completely with a couple seconds startup time. There are very few examples of when I believe a relational database is useful, and right now I can't even think of any.

By Randy Blair (Randyblair) on Tuesday, March 11, 2014 - 02:43 pm: Edit

Wouldn't it then turn from ship.mauler to ship.SVCsuperBadassMauler?
Whereby you define SVCsuperBadassMauler somewhere else.
I'm hardly an expert, so I'm sincere in my questioning.

P.S. I can't look at your online SIT if I don't know where to look. Just sayin'...

By Chuck Strong (Raider) on Tuesday, March 11, 2014 - 03:02 pm: Edit

I'm no coder but very specified fields does make sense as we WILL forget and discover new properties that will need to be included whilst working the project and even after it is completed. The project needs to be able to expand as will be the case with the upcoming Minor Empires (as we will be adding new ship properties).

For example, just looking at the above I can see where we would need to have properties for HDWs and other modular ships that use POGs, COGs, FOPs, and HOGs…..

By Eric S. Smith (Badsyntax) on Tuesday, March 11, 2014 - 03:13 pm: Edit

Understood Randy, but SVC didn't want me sharing that online SIT yet. If he wants to jump in and say I can, I'll post it for all to see.

As for HDWs, I had a "modular" field that supported either "HDW", "SP", or "SK". This way you can add various module types (which had their own stats). However, I can say that this is a perfect example of how design counts for more. I know some ships can only have certain HDW, SP, or SK modules. So the module types will have to be listed as valid. Things like POG/COG/FOP/HOG are just HDW modules that are tracked separately and applied as an HDW module when mounted.

Tugs are actually the most complex ships in the game. Some pods slow it down, others don't, some are double sized, some tugs don't care, tugs can also be overloaded which completely changes what they are (from standard warship to slow). They can also tow some units which can slow them down. Then add in LTTs, theater transports, and various other ships that can carry tug pods. They are, by far, the most complicated ships in the game and will probably end up having 40 fields dedicated to the tugs and their pods.

By Richard B. Eitzen (Rbeitzen) on Tuesday, March 11, 2014 - 03:21 pm: Edit

Essentially you need to be able to create conglomerate units, that are a combination of existing counters.

Sparrowhawks are not conglomerate in this sense, but rather are conversions with different conversion rules, perhaps.

Another concern is the treatment of captured ships. Essentially you need to be able to create new ship types dynamically, so as to only need a record for ships that actually are captured and converted to the new owner's technology.

My thought is that traits of a unit are best handled by having a record of the actual traits that a unit have, and that traits it does not have are not recorded in any way. Then you just add code for new traits as they are realized.

This way the program can more easily be adapted to new expansions as they come out.

By Eric S. Smith (Badsyntax) on Tuesday, March 11, 2014 - 03:55 pm: Edit

Captured ships will be easy, just change the owner. I would track the original hull of the vessel separately from the original owner.

Actually, I had actually wrote a dynamic counter system that created the counters on the fly. This allowed captured ships to have their counter colors changed (http://goodsects.dyndns.org/zff.png) and could be done as they changed between sides. This allowed me to just draw the 10 or so basic hulls from each race, and generate hundreds of counters within a few seconds. This is one of those things I felt was necessary, as if you want a new ship just define the text values and the thing gets drawn automatically.

Thing is, your object classes within the application will need *all* traits defined, otherwise you'd have test for the existence of each property, which is CPU intensive. Essentially, you are making the definition of the ship easier for humans, and far more difficult for computers. I can write a simple website that lets you load up a ship and see only what applies without hurting the code.

And as for the whole new expansion thing, oh gosh, that is just unacceptable.

Lets use an unrealistically low number of 50 "flags", like mauler, carrier, scout, etc. When you define a Federation CA it may have none of these, a COV may have 5. Sounds simple right?

So you get a new module, and you plug in your new ship. Do you really think you'll remember every single possible flag that could be applied?

Then, a few years later, SVC comes out with some new rule. Now you have to go through 200 ships with a movement of 5 to add some flag. Sheesh, that'd be tough.

Hopping into excel, sorting by "speed", and doing a quick replace, takes seconds rather than days.

A tool will make ships easier to read for humans, but the code itself should have no such simplification or all the sudden humans can modify the ships, but they can't keep the code updated.

By Richard B. Eitzen (Rbeitzen) on Tuesday, March 11, 2014 - 04:04 pm: Edit

Some captured ships lose capabilities or fighter factors, this has to be accounted for.

My thought was that you could have a record of types of traits that a unit has.

Let us say that it is an array of integers.
If you search the array for the 'troop ship' type and it's not there, you just return a 0 for the factor. If it is there, you use an array of factors where the index corresponds to the index of the array element that corresponds to the type you are looking for (in this case troop ship).

As most units by far have very few actual traits, your records don't have to account for hundreds of fields of mostly zeroes (corresponding to traits that the unit doesn't have).

I'm thinking about how one would more effectively do this sort of thing - and easier on the human is probably more important than easier on the computer, as today's computers have much more powerful capabilities than those in the past.

As for easy to read, in the data file itself, you could have records like:

"Warship 8" (leaving off the things always in a record such as CA Federation and so on).

The program would automatically fill in the default values or use the default calculation method for a standard warship, ie 8 eco cost, move 6, 8/4 combat factors, 0 fighters of any type and so on. As you datafile would all be in text, someone who understood the format could easily modify it if they like.

Then when the program loads the datafile, any record that is illegal would just make a note in the current debug record file, and the user could look at that to fix anything he modified illegaly.

By Richard B. Eitzen (Rbeitzen) on Tuesday, March 11, 2014 - 04:21 pm: Edit

In fact, now that I think of it, I know how I would do it.

The data structure would just have members for the commonly used traits.

Instead of having 200 members for uncommonly used traits, it would just keep the string of english text used in the data file and search it for whatever uncommon trait data is being requested. As such requests are rare, they should not have much impact on things like clock cycles.

So, a data structure might have:

ShipType WARSHIP
ClassName 'CA'
OwningEmpire Federation
CombatFactor 8
FighterFactors 0
EWFactor 0
MoveFactor 6

OtherTraits "NONE"

or

SHIPTYPE TUG
Classname 'TG'
OwningEmpire Federation
CombatFactor 0
FighterFactors 6
EWFactor 4
MoveFactor 6

OtherTraits "SplitFactor 2-8/1-4 SCOUTPOD CARRIERPOD"

The code would know that anything with a combat factor of 0 needs means it needs to check OtherTraits for the actual factors.

By Eric S. Smith (Badsyntax) on Tuesday, March 11, 2014 - 04:25 pm: Edit

The fighter types would be dictated by race, if you switch to a new race, your fighters drop back down to nominal groups. It wouldn't be 2 different ships (well, the fed CVS/CVB are, but they also have lots of other rules)

In assembly checking for 0 is a line, checking for existence of a property of an object is a lot more than that.

Sure, a computer does millions of computations a second, but is your computer feel that fast to you? Thing is, each of those computations isn't just 1+1, it is FAR more complicated than that, and the 1+1 may only be 1% or less of the actual calculation. Thus, computers aren't as fast as you need, you gotta think smart and save CPU cycles or the user will get bored with spinning hour glasses.

My Fed SDS has 66 different traits currently, and there would be considerably more.

I used text based XML files for serialization of the objects, though that was for debugging. I'd move to binary XML for a production application as its much faster.

I would have no problem with a user creating a super-duper-crazy-insane BB with 1000 compot, 5000 F-111s, a 200 point mauler, that can carry base power augmentation modules and operates as a rescue tug with 40 EW. So I don't want to impose legality on ships being created, that is up to the users. Once both players say "this database is good" encryption can take place and other methods to make sure nobody hacks the game, but load time validation is unnecessary and carries with it extra startup overhead time.

When I "created" a Federation Heavy Cruiser, I said "hey, add 1 Fed CA to this fleet/hex/etc". Then I go to the database, lookup the Fed CA, and populate all the characteristics from that. The ship from that point onward is linked back to the Fed CA. You can change the name, how far it moved, its damaged state, but the original stats will all be Fed CA. If you change the Fed CA to CR 10 later, all Fed CA's in the game using that same database will be updated as well. That would invalidate the game though as the database changed, and all players would have to accept it in order for the changes to be applied.

If you want a really easy to use editor that lets you do something like:
Race:Fed
Hull:CA
Uncrippled_Compot_O:8
Uncrippled_Compot_D:8
Crippled_Compot_O:4
Crippled_Compot_D:4
Command_Rating=8
and so forth

That is fine, but nowhere will it be saved in that format as it takes longer to load than a binary XML file (or just flat binary), and when the computer loads it it'll set values of 0/false/null to all those things you didn't define.

But modifying the ships in excel (that looks much like a longer SIT) is so much easier, I'm betting everybody will be happy with that method.

Again, these are just my opinions on it based on my own experiences with it and my pretty darned extensive and a wee bit nerdy technology background.

If your doing the coding, use whatever method you want, pretty much any method anybody has mentioned would work in their own ways.

And just think about how many of those traits are used for a simple pin count, or fleet wide pin count, or if you wanted to find all your scouts or maulers, etc, etc... these things will come up, a LOT, and text searching is extremely slow and prohibitive.

By Ted Fay (Catwhoeatsphoto) on Tuesday, March 11, 2014 - 04:26 pm: Edit

---

Quote:

Captured ships will be easy, just change the owner. I would track the original hull of the vessel separately from the original owner.

---

By Richard B. Eitzen (Rbeitzen) on Tuesday, March 11, 2014 - 04:43 pm: Edit

I actually have done machine language / assembler programming for the 6502, the x86 processors back in the 90s, and some kind of IBM mainframe for 6 months (though only a little assembly, that was mostly COBOL doing maintainence on hundreds of interrelated banking software programs).

During my DOS days, when everything was VASTLY slower and memory was far more limited, I wrote assembly language routines to do graphics programming. So yes, I do understand these sort of things.

Nowadays I just stick to C++. And yes, I do feel that my current machine is incredibly fast.

I can save data files in text format using english words, and just use it that way. It's not any problem at all. Back in the 90s, Civilization II on the computer kept many traits in such a format, and you could easily edit them.

Finding all of your maulers is easy and fast, even if some of the data is stored in a text string. Look at how fast you can search a document for text. It's not a problem, because we're not dealing with a real time application that is trying to put up 60 frames of 3d rendered images a second, and you are just searching a couple hundred to a few thousand at most records. Zip done.

By Eric S. Smith (Badsyntax) on Tuesday, March 11, 2014 - 04:56 pm: Edit

The hydran rule would fall under a CAPTURED_HYBRID flag of 1 or 0. Or maybe a CAPTURED_FIGHTER_LOSS which is a # of fighter factors lost, and a CAPTURED_AF_GAIN for the AF change to account for those unique ships that should keep some fighters, but not all of them (HDWs?).

That flag would:
- Change fighter factors to 0
- Make attack=defense

and this would just be done on the resulting ship, the original template would be the same.

I have used Server 2012 on a $180K server, and felt its responsiveness leaves something to be desired. I have a 32 core/64gb of ram machine in my other room that also runs the latest operating systems kinda sluggishly (and yeah, I got fast ram, fast video, and SSDs). My primary tinker machine now is a corei7 3.2g and windows 8 is too slow for me. This is my perception though, I type 80 wpm, rarely use the mouse, and the slow user interfaces these days leave me waiting on the computer. Once I get to dos/ps/etc, things do run faster. But, I don't want to spend all that extra time coding something for DOS ;)

So Richard, are you going to write it?

By Richard B. Eitzen (Rbeitzen) on Tuesday, March 11, 2014 - 05:03 pm: Edit

Yes, that's the question isn't it?

I want to say yes, but at the same time it's not a decision to rush into (and I've been thinking it over for a long time).

By Richard B. Eitzen (Rbeitzen) on Tuesday, March 11, 2014 - 06:35 pm: Edit

So, anyone have a good suggestion on any online tutorial for learning windows programming? I already know C++, but all my coding experience is essentially in a DOS environment.

By Randy Blair (Randyblair) on Tuesday, March 11, 2014 - 07:52 pm: Edit

I'm using w3.

By Eric S. Smith (Badsyntax) on Tuesday, March 11, 2014 - 08:20 pm: Edit

Switch over to C#, the .NET libraries will save you huge amounts of time, and the learning curve is trivial. Plus, C# tutorials are all over the place, and you'll be hard pressed not to find lots of results in google when you run into a problem.

I'd say Java but its extremely problematic in my experience, and so few people use *nix/macs that it isn't worth the extra hassle and development time IMO. Plus, you can do it web based with C# if you go that route and the back end doesn't matter to the users anyway.

By Ken Kazinski (Kjkazinski) on Tuesday, March 11, 2014 - 08:51 pm: Edit

If you want to use C++ you will have to use the Microsoft Foundation Class (MFC) it wraps portions of the Windows API in C++ classes. You might want to look at sources like CodeProject. A number of people have provided libraries to make some tasks easier.

By Ken Kazinski (Kjkazinski) on Tuesday, March 11, 2014 - 09:16 pm: Edit

One of the problems with using text tags to define a unit is people tend to forget what a tag is or how it is formatted. By having separate "fields" you output the data in a consistent human readable format.

Putting on the Computer Science hat - text processing is one of the more CPU intensive processes versus comparing numbers. From a database perspective (or if you are using Linq across objects) it is faster to do a number field lookup than a text lookup.

I use a relational database for all the units in SFB. One of the reasons is I did not want a single sparse table but this was a design choice on my part.

When you start to put data into a defined structure you start to see where inconsistencies occur. Using the APT example, having a rule that states auxiliaries can not pin, now you have to define which units are auxiliaries. As is always the case, there are exceptions and each of those now need to be defined.

My experience has been that the YIS for many units is too early. A system using on a unit has a YIS that is after the YIS of a unit. This has been a function of modules being added without looking at the effect on the 7150 units in the game.

Data input and verification can be full time job - look at the SIT forums. It seems there are always updates or errors found. This is the nature of using a excel workbook format. I would like to see a database that outputs the current up to date data.

By John de Michele (Jdemichele) on Wednesday, March 12, 2014 - 11:21 am: Edit

How is Java extremely problematic? More development happens on Linux and Macs than I think you're giving credit for.

By Eric S. Smith (Badsyntax) on Wednesday, March 12, 2014 - 11:42 am: Edit

Have you even used java in windows??? I have only very rarely had to tinker with .NET, but java is a constant burden to our users. Update 51 had to be rolled back as it broke tons of things (and this isn't the first time). I've personally had tons of issues with it. The embedded ask malware toolbar makes me cringe, and we have to remove it from users machines constantly.

Not saying there isn't any development, but compared to windows (which is on the vast majority of desktops at home, and in the office) the mac/linux development is a tiny fragment of the size of the windows community. Talking desktops here, as sure, java is more popular with android and embedded linux is ubiquitous.

If your going to write a game for windows, java has a higher potential to be error prone. I have seen some exceptions that were great, but many more that were horrible (buggy/unstable).

But, some people love it, and like furry conventions, it doesn't affect me, so more power to ya! I'll *try* it no matter what language it was written in!

If Microsoft keeps releasing garbage like Windows 8, Server 2012, and Visual Studio 2013, the other solutions will start looking better and better though!