Nic's HCE Wishlist

 

In no particular order, so while numbering is used to follow existing guidelines in using wish number to refer to it, you shouldn't assume the earlier ones are the most important to me. Neither is the quantity of verbiage on a topic any indication : here the professional inclinations show themselves, it's all somewhat interlocked in a cohesive design in my mind, as I've been tackling those same decisions on personal and professional projects in the past, and still do

 

So technical aspects sometimes have been expanded on, etc.

Especially in the early items, but time marches on.... For whom the bell tolls... erh, Tony told me to hurry up

So some of the little(st) items are very dear to the designer in me, like augmented viconds, campaign mode, etc.

 

1 - ID numbering scheme and DB scheme refactoring, ultimately legacy free (haha) (the two go hand in hand in my mind, see my more extensive write-up on this topic later in the thread). ID numbering scheme should be key based, the key being generated and managed with standard techniques like hash maps, etc. Most important, the ID used in game should have no dependency on whatever scheme Access (or any other DB system used for the PE with this new scheme) uses internally to manage individual records across many tables.

New DB scheme would then be using existing data layout and migrating it, eventually even retaining old IDs for existing data (far from impossible) to that new ID scheme. Also, from a loading data perspective in the GE and SE (and any other future tools), the way data is loaded would change to something like this : first look into the scenario for instances or custom asset classes, then the battleset, then the global DB.

 

2 - Lua integration for scripting (both programming and config scripts/external data handling) and in a roundabout way, ANSI C (or any language that can be wrapped with C ) plug-in programming (Lua includes a way to load external binary code that follows its guidelines for binary modules).

Dedicated write-up follows in this thread.

 

3 - Multiplayer, with authoritative server, whether this is done P2P or server/client from a network protocol and transaction level is implementation dependent. Conceptually, I strongly believe there should be one (or more machines working in distributed fashion, like seti@home) server, who has authority on the game world, and decides on the validity of data. Even more strongly, I believe that the less calculations one does on one's machine that affects one's assets, the better. Cheating is a reality, and when you make it easy....

Sadly, that can be a strike against integrating scripting, but not if you have an authority directing and arbitrating the validity of the data flowing between players, and coherence of the game world.

More info farther along.

 

4 - Per Scenario Instancing of assets, to allow modelling of damaged ship, limited ammo and supplies, unique custom platforms, etc. More info in following write-ups in the thread

 

5 - Supply/Limited Ammo : Again, my vote goes for Akula's idea for the point system, which can then be used to build the system I describe later on in this thread, which models ammo limitations with slightly more detail.

Basically, I would like to see specific ammo limitations to model situations where you have limited amount of a particular ammo. This would be implementing by maximum caps, with a default value for unlimited beyond the point system (meaning if you don't have enough points, well you can't have any of that), zero for not available at all and a numerical maximum value that's decremented every time you buy such ammo (or whatever else, it can be easily expanded) and expend the points for it. So to get a particular ammo, you need to have enough points to purchase when resupplying but there has to be some left. I'll come back to it.

 

6 - Realistic speed/depth changes : I don't mind so much the group window reflecting the orders status for a group, but individual subs, ships, a/c changing altitude and speed instantly because of a group change...

Granted, at the unit level in a surface/sub formation, a group order doesn't always change speeds/depth immediately since those units could be on patrol, catching up with the group, etc.

 

7 - More functional unit window : I want to be able to give orders to individual platforms in the unit window, beyond the formation editor.. If what I do puts it out of the formation and I don't take it out of the group, then it'll try to catch up with it once I'm not giving it my attention, e.g micro managing it any more, or whatever realistic consequences to taking a unit out of formation without dividing it from the group first.

Still, this is more about more functionality in the unit window...

 

8 - Slightly more complex modelling of aircraft ops : modelling individual a/c very simply but more complex than now. Maybe a happy medium between Flight Commander 2 and our present situation, e.g. data modelling of individual a/c without going into so much movement detail as FC2, something like that. And the AI for it, or means to implement doctrine/SOP like in many games do for their ground units (TacOps, hi pete )

 

9- Ground combat Ops, operational, somewhat tactical using a TacOps like system of SOP, direct orders, and AI execution, but at a higher organisational level, possibly. (or scalable)

But a simple system, as far as modelling weapons,etc. but allowing some tactics fun.

 

10 - Comms/Data links modelling, and contextual sitrep (right click unit and group menus is my 10.5 wishlist item)

Comms/Data links modelling : something with basic ranges, that drives the contextual sitrep item.

Contextual sitrep, is that when you select assets that don't have the global picture, you get some indication of what it is they can and can't see, maybe by shading contacts that are not contacts for that group/unit ? (been playing some FC2 again lately, and that's how you know if you can target a certain bogey/bandit : you might know it's in front of you but can't see it so it's shaded/grayed out)

All this is again a cry for more Unit window functionality : I love the unit window vs multiple zoom/tracking windows in ANW. I just with it did more....

 

10.5 - Right-click contextual menus for groups/units, bases, even empty spot on the map (you'd get latitude/longitude/depth/weather/sea state, etc in the menu, or an option to show them. Example, obviously )

 

11 - Advanced Viconds, including taking (back) bases, juryrigging them for use, and ditto with platforms, even in a sufficiently long scenario or campaign.

 

12- Campaigns : possibility to really string along scenarios and use results from previous ones, including viconds, but also unit damage/destruction, Supply/Ammo pool points, etc.

Again, scripting would simplify doing a lot of this, as well as allow other programmer to help without needing the source code to HCE

 

13- ECM/Jammer control : being able to control ECM/Jammer like other sensors.

 

14- Extended/Custom Range Rings for Formation & Bases : Ideally, user configurable for each formation or base. If not, and they have to be "hard coded" then, vastly extend each ring in the base case. Seconding existing requests for that feature

 

15- Extended A/C Patrol abilities : When I send an Orion on an ASW Patrol from a base outside its range rings, I'd like that the AI controlled patrol would search a zone at the end of the patrol path, which gets it to the zone. Similar to other feature requests.

 

16- Time Controls in SE : Ability to not only set a precise start time to a scenario, but also ability to move along the timeframe of a scenario inside the SE, quite like in the H2/H3/ANW SE.

This would allow us to "spawn" units later on, etc.

 

17- Partial "viconds" and scenario events : Ability to set goals or viconds that are activated before the end of the scenario, which couple to point 16, gives scenario editors the ability to set conditional events/unit dispatch, etc.

For example, need to destroy TF1 before the next day for a certain event to happen and reinforcements to appear at a landbase, etc.

 

Possibly more to follow, write-ups are coming later on tonight and tomorrow at the very least as posts in this thread.

 

Edit : corrections + added 13, 14 and 15 (Aug 4th 08, 19:36ish)

Added 16, 17 (Aug 7th, 2008)

Case for Lua Scripting :

 

note : This article goes a bit further in terms of technical details regarding implementation, to help Tony in his exploration of that possibility. I'm of course, ready to answer anyone's questions on the topic.

It's also a work in progress

 

Lua is very simple, and easy to embed into an application, as that's what it was designed for.

It's ANSI C, hence can be "glued" to any set of programming language/runtime environment.

It has a fast garbage collector, meaning the end users, aka gamer, who wants to mod, or add nifty features to his scenarios and battlesets can more than dabble with the scripting, without having to know much about programming fundamentals, and in particular, memory management.

To boot, Lua can also be used as just a configuration language, which is what probably how most end users in HCE would view and use it.

Implementing it in the way I envision (and Tony, if you want to do it, I'd be more than happy to help) would give the instancing feature I've mentioned for free : exposing the various structures that hold game-time information to Lua, would allow us to do something like this :

 

Carrier1 = new Ship("Nimitz");

Carrier1.damagepoints = 700; -- original value being whatever

(more realistic and extensive examples to come)

 

It opens us a whole world of community interaction with the game, without having to make it open source, or even share the C source at all, hence not running into licensing issues.

Some serious modding can be done through Lua, including the possibility of writing new external code in C (or other languages, as long as it's wrapped with Lua C API) to override existing behaviour, be it through a callback mechanism, or by setting up the game loop in a script file at game load time.

World of Warcraft uses Lua for the UI : they implemented a set of UI widgets that can be created and configured from user scripts, as well as a library of functions calls and data variables that can be manipulated in user scripts.

 

The possibilities are quite exhaustive, one might say endless, and also very powerful, while allowing your normal user to leverage it.

Of course, this is not magical, you have to do some work in the game engine, etc. to expose stuff to Lua, but then, even Tony can code without having to rebuild the whole thing.

The same executable could be used for scenario editing simply by changing its set of initialization scripts.

Extending the application without rebuilding it, aka modding it, becomes possible through user written scripts.

 

Configuration wise, it could have lists in script form that the GE/SE loads at initialization, describing images, sounds, videos, etc. that the UI uses. .

Other internal parameters that don't use external (outside the program itself) resources could be exposed for configuration, like colors used for untextured land and sea, fonts for text, etc.

Like .ini files, or batch files (to a certain extent, don't let that scare you off, hehe)

 

Of course, scripts can be generated from user choices in tools, etc.

So that manual editing is not the only possibility, but guarantees that anything meant to be exposed for modding/editing/etc. can be so at least in text form.

That Lua is a complete programming language, and really, really fast at what it does is a bonus.

 

It could render possible writing AI/PO for individual ship or ship classes, since at the simplest level, being able to do simple if then constructs, loops, variable assignments, and the like are the basic tools of progrmaming, hence of AI programming.

 

Lua does not enforce Object Oriented programming, just like C, so don't think of Java or Python, or C# when you think scripting. Or basic, visual or not. It's very simple and powerful, and through its table construct (a sort of associative array if you will) allows the developer to build his own object system if needed.

This is one of the reasons its performance is so good : simplicity of the innards, not including a complex object system and object hierarchy, etc.

This simplicity also allows you to build your own object or whatever system with it, for your own particular needs.

In that simplicity lies its true power and flexibility : you can keep things procedural or modular if you want, or build an object hierarchy with multiple inheritances (you'll have to implement it, and well, multiple inheritance is crazy, since you can do most of it with single inheritance and composite patterns), etc.

 

Exposing HCE's innards to Lua doesn't have to be all done manually : there are a few tools out there that can generate bindings for Lua from sourcecode. Of course, you have to prepare the source for that, but that's beyond the topic of this writeup. Again, I reiterate my offer to help with this endeavour : it would open up such a world of possibilities, as well as allowing long term community maintenance of HCE without having the C source code, since a well planned scripting implementation coupled to a lightweight C API would expose everything needed to keep the game alive for years to come.

 

It's really not very complex work, and is not very intrusive on an existing codebase : after all, you can pick and choose where the Lua virtual machine interacts with the game engine.

Again, this work is what Tony would do, not the end user, who would only reap the benefits, and wouldn't have to touch it if he doesn't want to, albeit probably everyone would at least use it insofar as nearly everyone would tweak config files if there are any

 

As Lua is a real programming language, with no expensive development tools needed to use it (it's open source in a very liberal way (not GPL)), it's very simple to use : you only need a text editor, as the virtual machine compiles the scripts from text form to its internal representation when they're loaded.

A few debuggers exists for it, and it includes a debugging api, for the more involved script programming.

Also, you can extend it with dll like modules written in C that you can load from scripts with a dedicated command (require iirc), that could call HCE's external C API on top of adding capability to Lua inside HCE

 

Communication between Lua and "native" code, is done through a C api, which has Lua calls for the Lua side and C calls for the C side. It's done through a memory stack, through the usual push/pop calls, as well as other utilities to manipulate the stack. Lua uses those same calls for internal use, as any application's scripts will.

But this allows the modification of a variable in Lua to also modify its counterpart in C code, and vice versa, affecting script variables from inside the engine, be it in-game or in-editor.

Where to get more information on Lua :

 

Official website : http://www.lua.org/

 

About Lua @ above site, for a quick flyover : http://www.lua.org/about.html

 

Lua-Users wiki home page (good for community built tools, like automated code binders, language bindings, etc.): http://lua-users.org/wiki/

 

A list of known projects using Lua : http://www.lua.org/uses.html

 

 

Edit : added some content, corrections, as well as external references on Lua, for those who might be interested

Case for more complexity in Ammo Points system :

 

(note : I apologize in advance for the so so quality of the text and any misunderstandings stemming from it, as I had to edit/rewrite a lot of it in a very limited time frame, cutting down on my original drafts, which tended to be quite longer than the final result..)

 

The proposed ammo system :

 

First, it's first for a/c loadouts, but could easily be expanded to other ammo types (exercise for the reader )

It would still be a point pool for a/c ammo, but it would have additional constraints that would limit the amount of ammo of a certain type that could be bought through the point pool system of replenishment. Ideally, this should be an optional feature on the scenario/campaign level, features revamp allowing, .

Meaning that by default, everything would have the default max value indicating no limits beyond having points to buy it.

 

It remains to be seen whether it would be per loadout type (intercept, cap, cas, etc, iron bombs, precis, etc.) or by weapon type, as I think that you might as well do it per weapons so the system can be extended as is to other weaponry or assets/supplies if desired. Weapon limitations have the inherent side effect of limiting loadouts that use said weapon or equipment, achieving the loadout limit goal.

 

For clarity's sake, in the text that follows I'm assuming per weapon type limits, as in missile/shell/etc.

 

Either way, there would be a cap, that would be decremented by 1 everytime this type is purchased through the point system. So the record that keeps track of your aircraft ammo points would also keep track of maximums.

A simple method like having unlimited weapons/loadouts have a max of -1 (so no decrementing, always available) while limited weapons would have their totals stocked in that field, and decremented appropriately when purchased.

If this is not clear, please say, I'll try another tack

Especially if any still think it's as much work as keeping track of exact weapon amounts : the whole point of this is not to have to do this, by having the default behaviour of no additional constraints beyond having the points to buy it.

 

Why ? many have asked.

Well, to be able to model specific ammo stock shortages, just like can happen in real warfare, rather than just limit them in a general way through just the point system.

eg. not just saying you can't have any of this kind of cruise missiles or asm, but that you only have 1 or 12, or whatever of them.

This is very interesting from an operational perspective, as it's relatively simple (especially in view that it would be built on the by then existing point system) but opens up a new world of complexity in the kind of situation we can model and represent, as you would have to make difficult choices on when and how to use your aces.

 

For starters, this is really not that hard to do, and would even be easier to do with Lua integrated (plus, authors could mod the system for their scenarios and battlesets)

I say this, because once it's a given that a major overhaul is being considered and worked on, it's not much more work to add to it at that point. If not, it's important to do the overhaul with view of ongoing modifications down the line, especially if it's to be tested iteratively by the community. But I digress : that's more to do with development strategies than the ammo points system.

 

Akula proposed and elaborated the point system that will be the basis for replenishment mechanisms in HCE.

As I posted early on in his thread, I found it to be a very simple and elegant solution to a complex problem.

We don't want to switch the focus to micro management of supplies and ammo, so you can't give us too many details to deal with as the work necessary to manage it grows with the number of units to do it for.

Not forgetting that using a very simple system to start with limits the number of bug sources, and simplifies building on it.

 

So what I'm pushing for would be built on the underlying point system, after we've collectively verified that it's working to our expectations and is not taking away from the game's "fun factor" (hehe)

As I've mentioned somewhere else, I think the first iteration should be just the point system as outlined by Akula and Tony.

 

An alternative :

 

One important point that's been raised by others : point value should model both volume and weight in that a missile or any other replacement system that takes up a lot of volume in cargo space should cost more than a similarly weighed cargo that takes up less volume. Reading the point about the Phoenix missiles posted earlier today in the replenishment thread (iirc) brought this to mind.

I think that even if we stick with a pure point systems with no caps per item (well, a/c weapons being my first concern, but the system I present, again, can be easily expanded to cover anything that can be replenished), we should be able to modify costs and point pools on a scenario/campaign basis as to be able to model the situation as a designer sees fit.

In fact, if having maximum caps for certain kind of ammo is not possible, I really think that we should be able to edit the point pool for replenishment vessels and onboard stores for other assets, as well as cost values for replenishment items, including but not limited to ammo, as to reflect potential limitations : if I can raise the cost for a certain kind of missile to the point that buying a couple (or a couple loadouts including it) will severely impair one's ability to earn victory in that scenario by stripping his points pool bare to buy those missiles.

 

So that's one other possible solution to being able to limit particular ammo/etc in a scenario or campaign.

Both could even coexist.

My point being mostly that we should implement simple, additional constraints to the points system.

Overhauling the ID scheme : A proposal for a hashkey/hashmap resource ID scheme and accompanying database scheme

 

note : I'm using the word addendum to mean the "mini-db" facilities discussed in this write-up, that is platform/weapon or other records contained in a scenario or battleset.

Again, I apologize for any repetition or messed up sentences you might encounter due to my haste in finishing those write-ups...

 

This is to make a case for a new scheme to at first supplement the old one, but eventually should completely replace it, at least ID wise, but possibly scrapping the old DB system for a brand new one that's more flexible.

Discussion and writeup follows

 

For those who might not know, let me give you a crash course in what a hashmap is.

Basically, it's a way to generate a unique key from an object or datum (piece of data)'s properties, like it's name, size in bytes in RAM, etc.

This key is generated by a formula akin to the ones used to generate (pseudo) random numbers on computers. It's a little mathematical construct that lowers the chance of two "objects" generating the same key, and in the cases you get "collisions", e.g. two identical keys, a simple mechanism deals with it by adding one to that ID, verifying that ID/Key is free and then assigning it to the new record who was giving us a duplicate key.

Using 32 bits for the key, would give us over 4 billion unique keys, more than enough for the next couple of centuries of HCE development (yes, this a geek pun, referring to Gates saying about having 1 meg of RAM...)

Btw, this is the technique used by many serious DB Management system nowadays to generate record keys.

That's the hashkey. The hashmap is a structure that lets you tie the key to a record or piece of data in a meaningful way, a bit like an indexed array, except that instead of consecutive numbering starting from 0 or 1, here the indexes are determined by their accompanying data.

 

The old ID scheme has to go, period.

If for just one reason : hardcoded ID number significations. Or rather, that the engine expects certain numbers to mean something specific, and not just an ID to an arbitraty record.

I don't know how far along the work to decouple IDs from engine code is, but obviously work has been done in that direction, at the very least for high ID images.

As for the DB schema, I think it's clear why it has to go (managing more than a few DB in an installation quickly becomes a feat of juggling )

 

We need a new scheme, where the GE or SE won't expect picture IDs to be in this range or that, etc.

Furthermore, the in-game (included editor) numbers should have no correlation to the ID record number in whatever db they are (just this will simplify DB management, import/export greatly, as tools won't have to replicate the DB internal ID scheme)

So in your DB/PE, you just let Access (or possibly another DB system if you prefer) number the records as it wants, as the formula for an item's key (the ID actually used in GE/SE) would be universal and a matter of maths.

An hashkey built on the record's name or a combination of the record's fields using a proper hash generator would give you over 4 billion unique IDs using 32 bit numbers. Enough.

And you have a system to deal with collision. Of course, everyone must use the same map, I"ll talk about ways to manage this later on.

That would be for the common DB, that I call the "global DB" in my wishlist and write-ups.

 

It might be better to have temp IDs for addendum records that are generated when they're loaded into the game or editor from a scenario and battleset, so there is no need to manage user content, as it has no absolute ID across the community until it's part of the commondb (aka the global official DB, which is last in line for asset lookup, after the battleset and scenario addendii, e.g scenario lookup first, then battleset then global DB).

The engine/editor just uses temp IDs generated at runtime as mentioned above for them.

Then, the chances of conflicting IDs is much lessened.

Of course, we'll need a community wide policy on incorporating new records to the global/commondb, or any other global DBs concentrating on a past or future era, geopolitical situation, etc.

Thing is, in this scheme, specialized DBs, as well as the mini-dbs I call addendums, can always rely on the global DB to look up records they can't find first in the scenario addendum or the battleset addendum.

Of course, records in addendums would also have IDs, but they would be "temp IDs" or "local IDs", in the sense that they mean nothing as far as the global DB is concerned.

 

That means, and I know I'm most likely repeating myself to the reader, that for multiplayer, even if there isn't a central server, there must be a "host" or "arbiter", which is authoritative as far as IDs go (maybe whoever loads the scenario decides the in-game IDs. Anyhow, having hashed based IDs would help with networking, as you'd come up with a similar scheme to pass data around and to which object it applies, etc.) I think that in any case, one machine would have to be authoritative and be the law in a MP setup, even in P2P, to prevent some easy cheating. Personally, I favor server/client architecture, but that's another writeup coming up (or more in a distributed computing scheme, where the server is virtual and made up of all the machines participating in the online game, like SETI@Home, etc.). Sorry, but it's a very important point in bringing MP to HCE, if you want people to play, especially new players : the scent of easy cheating must not viciously coil itself around HCE MP

 

In fact, in that scheme the hash based keys of the global DB would only be used to quickly retrieve records from it at load time, when preparing the data for the scenario. Ditto, for the platform display.

It probably works that way in HCE's internals already : load stuff from commondb, copy it to memory record used in GE/SE operations, etc.

So in all likelyhood, the major work would be revamping asset loading routines.

I'd love to hear more on this, Tony or anyone else familiar with the internal workings ?

The way I see it, existing records could even keep their current IDs, to maintain compatibility with old scenario and battlesets, and the new scheme would be applied to new entries to the global or commondb.

It could be made to work under the current DB scheme, where everything is either in commondb, or in the Battleset DB, simply by prepending a unique ID to each DB, so that the engine would know where to look and could give meaningful error messages when it can't find it

 

To finish, for now, my goal is to start or restart discussion on this topic, so that we can revamp resource management in HCE to simplify matters for the whole community, whether using a system based on the ideas exposed here, or something else altogether is not important to me.

 

I will post another write-up on ways to manage the IDs, so that we don't have to deal with conflicts between user and official content on an annoyingly regular basis.

Thanks to all for reading so far.

Added points 13, 14, 15, 16 and 17

Items 1 thru 17 noted in master wishlist.