A concept for an alternative civ: Civ shell

MrBaggins · February 13, 2003, 19:04

I was pondering the idea of what would make the civ concept 'perfect' and the truth is... there is no one true way.

In designing a mod, I thought how useful it would be to have access to a genuine DB, even an Access or MySQL DB.

I pondered what the essentials for a civ game would be:

* A graphics engine and UI, using DirectX to ensure performance and so as not to reinvent too much of the wheel... including

-> map (multi-layer) support- terrain & overlays. Sprite, 'region' and route (E.G. trade route) support.

* ODBC access to a DB, that comprises all game state. The map table would be duplicated in memory, for rendering concerns.

* A parser, including C basics, plus local numeric, string and database (including recordset) handling.

* An event system (with definable events except for StartTurn & End turn) Uses a priority system: BeginTurn starts at 1000000, and it counts down to EndTurn, at 0. The event system definitions should allow for triggers (UI and game state and event prevention/reenabling.

* Customizable dialogs, somewhat like the definitions in Mirc. Buttons should be able to trigger functions. Triggered functions should have access to dialog state.

* MP functionality from the start, yet including hooks for AI functionality

* Separate AI and diplomacy modules, in a natively compiled language, for speed. Includes heuristic definitions in text files, for flexibility. Its a little blue-sky, but you might want to consider using a genetic-adaptive approach, using a database as a repository. Theoretically, periodically, these db's could be gathered centrally to compete, and ultimate improve the default 'better case' data.

The game engine, including formulas would be defined and run in the parsed event driven shell, and be opaque. There would be a 'default' game world, but any amount of modification would be possible, by the effectively limitless shell.

Modification could be aided by relatively simple CASE tools... allowing for simple 'event scripting'.

Complete modifications would also be possible. If you didn't like the government system, and wanted to simulate SE, then this could obviously be incorporated. If you didn't like how growth was calculated, then, similarly... this could be altered to your purposes too.

MrBaggins

LDiCesare · February 14, 2003, 17:36

I'm afraid what you are describing exists as many names: C, LISP, C++, java, Basic and others... If you want a project where everything is customizable, then you need an open source game, like freeciv. The complexity of learning C vs. SLIC for instance is not so huge if you look at the amount of stuff you can do in C that you can't in SLIC.

MrBaggins · February 14, 2003, 19:15

You completely miss the point, LDiCesare: you mention programming languages... mostly compiled programming languages. A programming language certainly would be required to create the basic structure, but none of those languages inherently handle maps/UI/parsing/event system and so on. These can be created in those languages, certainly.

I'm suggesting a complied/parsed system... where only the foundations are laid in stone, yes, in a programming language. Any game functionality beyond the absolute bare minimum, would be defined in a native to civ-shell parsed language. Data storage is transparent... and available to anyone who has access to an ODBC tool.

Freeciv is certainly not designed from the ground to be entirely transparent. Many game concepts are interrelated, and its data storage is proprietory. It is not intended or designed in a way to make concept manipulation easy. Certainly not by the general public.

DarkCloud · February 14, 2003, 23:58

LDiCaesar- I think he is suggesting something along the lines of NeverWinter Nights customablility- where you can edit the c-Code and hack into the program; but in which you can also modify the game engine using the programmers tools.

It seems taht mr. baggins just wants open source code! (an expanded version of Fantastic World's)

MrBaggins · February 15, 2003, 00:04

Right... except the graphics engine... for perfomance concerns, and the parser and event engine, because they exist at a meta-level above the 'game code'.

LDiCesare · February 15, 2003, 08:58

LISP and Basic are interpreted, java can be too.
I didn't want to sound sarcastic, though it may look that way. What I mean is that if you make a core engine with parsable addons, you'll always have people want more. For example, you make an engine working with square maps, I want hexagons.
I think what you want is a modular open source project, probably based on something like windows dll (or unix .so) so you can replace one module by another easily, and additionnally some of these modules read data from files.
UI is typically something that is managed by changing dlls instead of interpreted text files IMO.

MrBaggins · February 15, 2003, 09:06

dialog UI's can be dynamically defined... and are in, for instance, mirc... so why not have them be text based.

How many civ modders/scenario developers can create a .dll vs change a text file? I'd say a massive majority.

If the ability to write a .dll were so ubiquitous, then people wouldn't complain about the lack of 'x' in games, they'd simply change it themselves.

As for the hexagon map issue... if there was demand for different map tile shape support, it could be added later.

MrBaggins

LDiCesare · February 17, 2003, 17:24

Coding a dll is in fact much harder than writing text files, but, compared to SLIC, not that much. You just need to have well defined Application Programming Interfaces. If you make it in Basic, it is probably easy enough for any serious mod maker.
And the hexagon map is just an example of stuff that require changing code. These happen all the time. Everytime I add a new concept in Clash code, I get people who ask for more. And I can't see it ever stopping. Your program will always be limited in terms of what can be done strictly by scripting, unless you give an opening in the scripting language to call some code (dll or whatever). That is what MS does with Basic, by the way. Excel macros for instance can launch whatever program you want (most of the time, one you don't want, like a virus, but that's the idea).

About defining a UI by text, it is possible, but today programmers tend to use tools which allow them to build the UI graphically instead of through text (code) because a good UI is hard to think of as text. Those who do code by text often make a drawing on the side to see what they are doing. But I agree, it could be done, particularly if you use something like VB (interpreted).

Urban Ranger · February 19, 2003, 06:15

The biggest problem is most players won't pay $40 to buy a game shell that they can't play.

MrBaggins · February 21, 2003, 14:22

Quote:

Originally posted by Urban Ranger
The biggest problem is most players won't pay $40 to buy a game shell that they can't play.

#1 No one said anything about charging $40 (although I don't have anything against a commercial product, per se.) In any event, non-commercial modifications will be FOC and redistributable.

#2 There will be a game to play. The big difference is, that it will be infinitely mutable, without recompiling.

Quote:

Posted by MrBaggins, in the original thread
There would be a 'default' game world, but any amount of modification would be possible, by the effectively limitless shell.

MrBaggins · February 21, 2003, 14:44

Quote:

Originally posted by LDiCesare
Coding a dll is in fact much harder than writing text files, but, compared to SLIC, not that much. You just need to have well defined Application Programming Interfaces. If you make it in Basic, it is probably easy enough for any serious mod maker.
And the hexagon map is just an example of stuff that require changing code. These happen all the time. Everytime I add a new concept in Clash code, I get people who ask for more. And I can't see it ever stopping. Your program will always be limited in terms of what can be done strictly by scripting, unless you give an opening in the scripting language to call some code (dll or whatever). That is what MS does with Basic, by the way. Excel macros for instance can launch whatever program you want (most of the time, one you don't want, like a virus, but that's the idea).

About defining a UI by text, it is possible, but today programmers tend to use tools which allow them to build the UI graphically instead of through text (code) because a good UI is hard to think of as text. Those who do code by text often make a drawing on the side to see what they are doing. But I agree, it could be done, particularly if you use something like VB (interpreted).

Whilst complete modification of the game system would be about as complex as SLIC, simple modification (such as simple events) would not be. The complexity of a mod would be limited by the modmakers desire and aptitude to program, without having to reinvent the wheel, or be limited in any manner.

Secondly, there is a difference between a parsed language and a dll... one requires a compiler, the other is run-time interpretted.. meaning in-game RAD is possible. You also don't need to buy a commercial compiler or grapple with a PD one.

The only downside to an interpreted language AT ALL is the performance issue, and thats a moot point when it comes to game logic, particularly with increasing processor speeds.

The parsed language was always intended to allow for external DLL calls, in addition... for the just the AI, at first, in theory. Although I intend weighted (not static) heuristic files to form the basis of descision making, in concert with a player by player game-state awareness model (including recon,) with decaying certainty.

The functionality I'm considering within the parsed language is to control the display of the map, by layer, including adding tile overlays, map overlays, paths and sprites, access any persistent game object and as I've said external executables.

Beyond the basic premise of a (multilayer capable) Isometric tiled map... what could possibly be desired beyond this? A relational database can model ANY data structure. A structured language can model any game state calculation or event.

What can you possibly conceive that is not part of this, beyond... as I've said... (multilayer capable) Isometric tiled map? Its hardly limiting... in any regard. Any 'Civ-style' scenario you could dream of could be conceived.

And if you don't want a tiled map... go make a Populous, or Panzer General clone or something

Regarding the UI being text defined (with templates)... thats how its done where the intent is to allow for user defined UI's... as per Mirc and, say, CtP2.

Programmers prebuild their dialogs and windows, because they are intended to be fixed. You don't want a fixed system in a game intended to be modified.

There is no functional downside to including a text defined UI system... just the initial complexity of the code permitting it.