"The time has come," the Walrus said, "to talk of many things…"

[Ozymandias]

Gentlemen!

We now have an extraordinary team together, and I think it time for us to choose a direction.

I’m going to begin by suggesting that we put aside both the .exe patching and .biq/.sav utility approaches. My reasoning is quite simple: nothing we do, by either of those means, can (for example) fix how the AI handles artillery - and that, of course, is just the tip of the proverbial iceberg.

That leaves us with the 3 other avenues we've been exploring and discussing. To recap, these are:

1. Building an entirely new game on top of an existing game engine, like Unity or Godot.
2. Building a new game, entirely from scratch.
3. Building a new game on top of an existing, open-source project (all but inevitably based upon either Civ2 or ToT, but I will being an "*" next to "Freeciv.")

Last night, I found myself watching a few science fiction short videos made using the Unity engine, and all were of impeccable Hollywood quality (one starred Sigourney Weaver) and I can't imagine that Godot is much different. The many appeals here are obvious, including the simple delight in becoming acquainted with using these tools.

I feel confident that I can act as a "translator" between coders and non-coders (along those lines, I'm going to totally redo my-shall we say-misbegotten attempt to explain Object-Oriented modeling; I do believe it will be worth the effort.)

On the other hand, given that Civ 3 is 20 years old, and the image does come to mind of using nukes against guys armed with only sharp, pointy sticks.

The closest "comparable" ("start up" speak) is Freeciv, which weighs in at about 400,000 lines of C code. And I simply cannot see any way that that wouldn't bore our aforementioned Four Horsemen to tears. Also (for example) WildWeazel has been talking about making a clone game for years, and I certainly don't expect him to suddenly change his mind. (Seriously - if anyone hasn't already "exhaled yet, kindly do )

So far, I've spent a fair amount of time looking into Freeciv because, among all known options, it stands out like a gem. As I've mentioned, it's written in about 400,000 lines of C code - organized into one of the best structured sets of code bases I've seen, Full Stop, both structurally and functionally (HERE are ~250 examples; here's a coding roadmap; and, lastly, a page on, "Game Anatomy & Modding."

It's not Object Oriented (and I believe - for reasons I'll explain elsewhere - that an OO approach is critical, for many reasons.) Nonetheless, it's basic unit of organization – the "Ruleset" - is, not only "close enough for jazz and government work," it is an intriguing approach, unto itself. It is vastly flexible, and (on the page that last link will take you to) there is the ongoing Ruleset development to make the game play more like Civ3 than Civ2. (I also gave some information about them earlier, in a different thread.)

Oh: ad it also has built in Rulesets for:

• Escalation towards war - no more "ROP Pearl Harbors."
• Built-in Event Scripting

Lastly, all of its code is fully available under the GNU General Public License.

I'm trusting that my vote - for Phase 1 of our project - is obvious.

We have already briefly discussed a 3 phase implementation for (OK, I think a "shorthand" name for our efforts would be extremely hand right about now: I've been using "C3+" in my notes - any objections / other thoughts?)

To recap:

1. The topmost items on our Great Combined Sets Of Wish Lists.
2. Everything else, short of:
3. MAJOR modifications along the lines of multiple game board levels, etc.

To this we must add a "Phase 0" analysis and design Phase - which (trust me) will be a gazillion times easier building on Freeciv than going from scratch.

- Now, all of that being said, I humbly suggest that (obvious efforts in design and development along the way aside) our Four Heavyweights choose what you most want to do - and we'll work it into the framework above ...

Spoiler Here is a great sacrifice which I am willing to make, regardless of whatever path(s) we take - :

By 1998, I was managing a team of 8 Project Managers; we were rebuilding one of the Big Name Investment Banks systems, from the ground up. For my first successful startup (still going, with a market cap of $600 million, the "get up and start" roadmap I and my team drew up was a 15' long and 3' deep Gantt chart. I mention this because I really don't care much for - and I am using this term in the loosest possible sense - "Project Manager" (NOT "managing" ANYTHING ) helping to make sure every effort is well enough in alignment to proceed) that I hereby officially volunteer to act in this "quasi capacity," if needed / desired / begged for / etc.

So - Said Heavyweights: name it; pick it; get some consensus, for (off the top of my head) -

• A graphical "repackaging" - and, of course, Per aspera ad astra! beyond that.
• Serious "forward looking, "Phase 3" changes like multiple map board levels, etc.
• Decompiling / recompiling anything which you think worth the effort - Example: it might make good sense to keep following in the footsteps of St. Antal1987 ( ) as a parallel to my hypothesized Phases 0 &1.

And, now, my Dear Fellows, 'tis time to ruminate (wiederkäuen, I hope ) regroup ... in short- Rock 'N' Roll!

 

[Ozymandias]

@Blue Monkey @Civinator @Flintlock @Lanzelot @Vuldacon @WildWeazel (dear God, I hope I've not missed anyone!) - I know it's only been 2 days, but:

• Everything I've suggested in the post above - at every level, and in every detail - are just that: suggestions.
• If I've structured the first post in any misbegotten fashion, please just say so. I have never once, in the past 30 years, had my ego "auto-engage" in any mishap I've made, anywhere, anytime. Whether or not anything at all in that first post flies or falls, my truest point is that I just think it's really time to agree upon which show(s) we're going to be getting on the road. And I do mean shows. I see no reason why cannot be simultaneously working on:
  • "Civ3+" Phase I.
    • .exe./.sav exploration, improvements, and hints to guide us forward. Better yet:
    • Releases of patches based upon the work @Puppeteer and @Flintlock are doing can be given to the Community at large, hopefully with some possibilities that these can be announced as "Deliverables," keeping everyone , outside our Merrie Band, on their toes for the next Release, of any stripe ( ) After all, so very many groups, doing mods as well as efforts like ours, having quietly imply faded away, not infrequently, even over the course of (any) a handful of years.
  • Whatever interest there is in future Phases for "Civ3+ v. 2.0," like multiple map level etc.
    
  • A complete - baseline? - project using Godot to completely recontextualize/improve All Things Graphical.

I also simply believe that, right here at the beginning, everything which can be, should be, coordinated, so that:

• We all know what's going on.
• Any requirements - "hooks"; real or pseudo APIs; etc. - for "post Phase I" implementation should be evaluated for any sort(s) of hooks or features - which can be built in, well ahead of time, accordingly.

I also wish to extend any further apologies, as needed. @Blue Monkey & I had begun discussing doing a complete rebuild under the umbrella of a 501(c)(3), some years ago, before illness damned near took my life. And my time remains short enough, now, that any long term project which I undertake (like this one) must begin with the only type of full court press I know.

I further fully believe that, once we're on that path, working together, to help Sisyphus finally get that boulder over the hill, we'll quickly become an organically self organizing group, and then (to quote my favorite poet) "All shall be well and all manner of thing shall be well."

In short, working with you guys is both truly fun, and truly worth it - and I am already, "All in."

EXCELSIOR!

-Z

 

[Puppeteer]

I hesitate to inject myself as I view myself as one of the lesser consequential–or lesser persistently dedicated–members. But I also hate to leave Oz hanging.

My read of the room–something that I'm notoriously bad at–is that there are a couple of directions with coding momentum and motivation: new-game-with-Godot (or Unity), and exe patching. And there are a number of interests of what could be if we all followed a different path.

I'm not personally sure there's one option the group could pick by consensus and then carry forward with a majority of interest and continued motivation. Given that, I'm thinking two or three subgroups of people highly motivated in a particular direction may be the way to go. That would be a bad business decision, but this is a passion project.

I see interest, motivation, and even momentum in a 'from scratch' clone using Godot–my personal bias is obvious here–and the same for exe patching with the arrival of @Flintlock and the revival of past efforts. (Does memory patching count as exe patching? I guess I've been counting it as so.)

Unless I'm missing it, I don't see anyone itching to roll up their sleeves and try to adapt FreeCiv, Civ4, or any other game or 4x game engine. The idea and business case are appealing, but again it's a passion project.

In summary, I'm seeing two-ish factions of dirty-hands coders, and my thought is it may be more productive to pursue multiple options rather than try to get everyone on board with one plan:

• New clone game using Godot and C#, reading and/or importing CivIII-native media and data
• .exe patching / in-memory patching
• If there is a third direction with motivated coders behind it, I missed that

 

[WildWeazel]

@Quintillus and @Lanzelot I'd especially like to hear your thoughts on this, and vs my argument here on this direction. I was probably overly harsh there, but the point stands: it's going to come down to the balance of what we can keep and what it would take to create that much on our own.

 

[Ozymandias]

[...] But I also hate to leave Oz hanging.

My read of the room [ is that ] there are a number of interests of what could be if we all followed a different path.

I'm not personally sure there's one option the group could pick by consensus and then carry forward with a majority of interest and continued motivation. Given that, I'm thinking two or three subgroups of people highly motivated in a particular direction may be the way to go. That would be a bad business decision, but this is a passion project. I see interest, motivation, and even momentum in a 'from scratch' clone using Godot–my personal bias is obvious here–and the same for exe patching with the arrival of @Flintlock and the revival of past efforts.

In summary, I'm seeing two-ish factions of dirty-hands coders, and my thought is it may be more productive to pursue multiple options rather than try to get everyone on board with one plan:

• New clone game using Godot and C#, reading and/or importing CivIII-native media and data
• .exe patching / in-memory patching

Amigo, this is precisely why I asked in the first place. And yours is a perfect answer: I believe that we can all sign on to this being a project of passion; You've narrowed your own passions to two possibilities. (Also, for the record, I've also counted both run time decompiling and memory patching as .exe patching.)

If there is a third direction with motivated coders behind it [...] I'm missing it, I don't see anyone itching to roll up their sleeves and try to adapt FreeCiv, Civ4, or any other game or 4x game engine.

I'm actually behind any & all of those 3 options - And why I expressed concern about boredom for heavyweight coders.

I think that any all .exe patch work, which anyone is seriously into, should simply go on no matter what ... BUT our initial thoughts and foci were, and have been, on an upgraded (new) game, as only a smidgen of our "Wish List" items can be accommodated this way.

So I think most (many? any?) of us are into a new game - and why I mentioned that Freeciv is just shy of 400,000 lines of code. We need a simple "raising of hands" as to who really wants a new game, and who would commit to one of the two paths - whose natures we both agree on:

• From scratch, using Godot or one of its kindred.
• Building upon an existing code base.

So now we need some further clarifications:

• How many of us are genuinely willing to work on a new game?

If so, how many of us are:

• Willing / wanting to develop it using a new game engine ("AI") ?
  
• Willing / wanting to develop it using an existing of 400,000 lines of code?

I phrase these questions, in these ways, for what I hope are obvious reasons - and now I'm going to drill down a bit:There is no reason, at all, for use to use the sort of "waterfall methodology" I was weaned on, but I believe that a simple "rule of thumb" which I used in the Dark Ages can be adapted here. There's no reason to go into details, but - for possibly archaic reasons - I knew that, for planning purposes, delivering a "chunk" (technical term ...) of 100 lines of C code would take (depending on the nature of the effort) 4 - 5 "full time person weeks." So let's just take a hatched to that, and cut it down to 2 weeks, using some sort of "agile" method. This is why I mentioned Freeciv's 400,000 lines of code. Using my "100 Lines Of C Code Rule," my best guess is that 400,000 lines of code, divided by 200 (2 weeks for 100 lines of code) = 2,000 "person weeks," which (divided by another rule of thumb that a full time, and dedicated, person actually works about 200 days/year = 10 "person years" of effort. And I'm guessing it would about the same (plus learning curve time) for Godot ...

... OR, we could use @Quintillus' editor as a "reverse engine API" to craft-and graft (TM) an existing code base into a Civ3 "full compatibility framework" and take it from there.

- Also, no matter the approach, there is always the matter of three or four levels of integrated design work (and did I mention that I already have a fairly complete detailed "AI model floating around my fevered brain? ( )

Now - Thank you again, me bucko, and keep the ball rolling - maybe I'll put up a simple poll

 

[Ozymandias]

@Quintillus and @Lanzelot I'd especially like to hear your thoughts on this, and vs my argument here on this direction. I was probably overly harsh there, but the point stands: it's going to come down to the balance of what we can keep and what it would take to create that much on our own.

I've just re-read your post and I'm not certain what your conclusion is, vis-à-vis a time/utility/benefit analysis?

 

[Quintillus]

I'm glad I waited to chime in instead of doing so immediately; Oz's post #5 clarifies his points for me, most notably about the reason for mentioning FreeCiv's size-of-code-base.

WildWeazel's summary as he linked in post #4 matches my gut expectation for adopting an external game, although he has looked into the specifics more. There's kind of two arguments here, which both point out challenges:

1. 400,000 lines of code is going to take a long time to develop (as Oz mentioned). This is true. While I suspect with modern programming languages we could do far better than 100 lines of code in 4-5 weeks (not having to worry about things such as memory management and pointers, as is necessary in C, and having some nifty libraries such as LINQ in C# that make some tasks much easier), it would undeniably take a long time to arrive at a working game from scratch. Put another way, I think there's a reason most free time games don't get very far, and don't have much polish, whereas for most indie games that do have success (Banished and Factorio to name a couple), there are people who dedicate themselves to it full time for awhile. The "self sustaining group" Oz mentioned in post #2 is essentially what FreeCiv accomplished, albeit with a more Civ2-like target.
2. Adopting a 400,000 line code base and morphing it into something that does something substantially different is also a very large task (as WildWeazel has mentioned). This is also very likely to be true. It can take months to become familiar enough to be adept in a new, sizeable codebase, as I've seen with my current job that started last summer. Refactoring it to do something different is going to take a lot of time, particularly as none of us are already FreeCiv contributors - even if the documentation is relatively good.

As a point of reference, a few years ago I did a line count on my editor, and (including comments and whitespace lines), it was roughly 50,000 lines. I never kept track of how much time I spent on it, but if I ballpark figure it to 1 years of full-time equivalent work, that's about 1000 lines of Java per week (including boilerplate auto-generated things like getters and setters). Even if my estimate is off by half, and it was 2 years, that's about 500 lines per week. But perhaps the most instructive figure is 50,000 lines per decade, as my primary side project. At that rate, with three people, it would take about 27 years to reach where FreeCiv is (150,000 lines per decade).

There are a lot of variables, some positive, some negative. My level of expertise was far lower when I started the editor; I could write it more efficiently today. On the flip side, I had relatively more free time then, and more interest in coding in that free time (as it wasn't a day job yet; I was studying other things in college as well), so the amount of time and lines written were higher earlier. Perhaps if I re-ran the line count today, it would be 70,000, shaving a decade or so off that estimate. And of course, line counts are a poor proxy of productivity, as made famous by the IBM/Microsoft collaboration on OS/2, which fell apart in part due to IBM's insistence of measuring productivity in lines of code, and Microsoft's belief that doing so encouraged poor programming practices. I generally agree with Microsoft on that, and am only quoting lines of code because of lack of another metric. The estimate is poor for all these reasons, as well as others (e.g. FreeCiv, being in C, will be more verbose). But for an order of magnitude estimate, I think it's fair to say we're talking a matter of years at least, not months.

I also agree with Puppeteer that it is important to keep in mind that this is a passion progress. At some points it has started to feel like a business project, and I for one do not have the mental bandwidth to handle an additional business project right now. I've been struggling enough with my main day job business project during the pandemic (I thrive off interaction with people), and have found the only thing I'm really productive at currently are passion projects. IMO, especially at the early "get off the ground" phase, the project management should be like bumpers at a bowling alley, keeping us in the general line but not trying to get us to hit a strike. Once we've got the hang of rolling the ball down the lane enough, we can remove the bumpers and focus on hitting more pins. Or to use another analogy, we're like the Samuel Langley, Otto Lilienthal, or the Wright Brothers, trying to figure out how to fly, not Vickers or Hawker trying to create planes to fight in World War II. We need ideas and an awareness of the challenges involved with various approaches, but above all we need enthusiasm about the end goal.

I'm not sure what level of commitment I am ready for. I suspect I am going to be on the forums for a long time, but am currently burnt out on coding in general. The pandemic is a major cause of this, so it may alleviate once a return to normalcy occurs, but it's at least a short-term concern. I'm also less into Civ than I was in 2009, when I embarked on editor-writing. That is more a function of discovering other games I enjoy as much as Civ. But much like my career direction decisions, what my long-term level of interest and commitment is feels like something I could only reliably answer once I'm in a more normal living situation, around people again and more aware of if the burnout I am feeling is temporary due the pandemic, or indicates a longer-term career change I should be making. Even in that latter case, it could either increase or decrease my interest - perhaps I'll be more interested in coding on side projects once I am not doing it for my day job, or perhaps my interests will move on from coding altogether.

What I do know in the short term is:

1. Diving into a 400,000 line code base (and worse, in C) and trying to wrangle it into something else is not something that sounds like a fun side project to me. Puppeteer's reading of the room is accurate in my case.
2. Starting from scratch sounds intellectually interesting, even if the prospects for a full open source Civ III are years distant, although how we get that plane off the ground remains an open question, and one that in my current state of burnout I do not expect to accomplish by myself. My activity also tends to ebb and flow, and lately it's been ebbing (though December/January were relatively high points for my enthusiasm for side projects; probably part of why it's ebbing now).
3. I still have some interest in expanding my editor. It could perhaps be used to accelerate early phases, although one of the big question marks is whether it could realistically support animations. It's probably a bad idea to try to convert it into a full game, versus using a game engine such as Godot, but it still sounds more interesting than adopting FreeCiv to me. More likely, I'll still occasionally make incremental updates. It's kind of my "chicken soup" side project in that I'm familiar with it and can make incremental improvements that deliver value to the community without huge time efforts. Even so, it has at times gone 5+ months between updates, illustrating the "ebb" part of "ebb and flow".

 

[Lanzelot]

I have been pondering similar questions in my head for the last week or so, too. I started to favor the "do it from scratch in C#" approach, and now after just reading @WildWeazel 's, @Ozymandias 's, @Quintillus ' and @Puppeteer 's thoughts here and over in that Analysis thread, I feel confirmed in that. The time we may save by being able to re-use some components of these other games, may be more than eaten up by the time it takes to understand huge amounts of 90's C coding, throwing away the parts we can't use or that even hinder us, and becoming familiar with the code base to a point where we can actually modify it without breaking things left and right...

The last point is what I deem very important. I have the impression, that most of you are more comfortable with managed languages (Java/C#/Python)? And I can tell you from own experience , that if you come back to C/C++ after a longer period of programming in Java or C#, you are prone to make subtle errors either with those pointers/memory management or because of those "subtle differences" between C++ and a managed language. (Those implicit copy-constructor calls that the compiler adds for you in the most unexpected places, come to mind here...)

Anyway, we could easily end up spending more time on analyzing strange inexplicable crashes, buffer-overflows and memory leaks than doing productive work...

But that doesn't mean we need to do everything from scratch. (More on that later.)

However, there is one point where I disagree with the majority here: I feel that we cannot afford pursuing many differing diverging approaches at the same time. If we want to have a chance to "be better than the original with less resources at our disposal than the original" (and in a reasonably timeframe), we really need to focus and be very effective. And I think we need someone (let's call it "lead architect", though he probably isn't), who keeps the big picture in mind and makes sure that everyone is on the same page and that all the single pieces will in the end fit together. I have seen many projects, successful ones as well as complete failures, and in my experience the ones that have a crisp plan of what to do and how to do it, before they start coding, are the most successful ones. Projects where everyone just starts hacking code into the keyboard (as much as we all love to do this...) are just as likely to fail as the ones that start with on over-boarding abundance of design and specification papers... -- the design needs to be flexible enough to allow for adjustments in case it turns out during the implementation phase, that some things that were originally designed, are impossible to do in practice. (This will happen inevitably... ) But a design (which is kept up-to-date as we go!) is necessary, especially in a project like this, with peoples from different timezones, different cultures and different mindsets/backgrounds, and where it is to be expected that people will drop out and fresh people will join. If we have well-written documents in place that explain, where we are headed and what has already been achieved, it will be much easier to not lose the know-how of the people who left and to bring new people who join up to speed.

The overall design/architecture will probably not be done by a single person, but by the entire team. No single person will probably have the entire knowledge about all parts of Civ3 that is required to write such a document, but together we might have a chance. We need a complete list of the components we need, and how these interact with each other, e.g. to name just a few

• .sav file parser and renderer
• component that manages cities, their production, buildings, citizens, commerce
• component (or data-structures) that manage the Civs, their cities, units and relations to other Civs
  
• a map component (where is everything located? what is visible to whom? etc)
• rules engine
• graphics engine to display the map on screen
• graphics engine for the UI screens
• sound engine
  
• component to manage tech trees and tech cost

And other people will probably think of many more things the game will need. So we need to brainstorm for a while, what is needed for the finished game, and then we can

• think about what can be re-used from elsewhere (yes, I do think we don't need to do everything from scratch!)
• delegate the things that we do need to do ourselves to the people who feel most comfortable with them (some may be more interested in/capable of working in the graphics area, others more on the "backbone")

What can we re-use? I am pretty confident, that CivAssistII will be a valuable source of reusable components. For example the .sav-file parser contained in CivAssistII seems to be pretty complete: it displays the map correctly, all units on the map, all tile improvements, all cities and their currently accumulated food and shields, all borders and even the forest chop status for each tile. Lot's of other algorithms can probably also be taken over from CAII: corruption, flip-risk, palace-jump formula. Stuff like that.
And all of that is already in C#.

And there are other tools and helper programs that can probably be "looted for spare parts": a combat calculator, Gramphos' MultiTool, MapStat, ainwood's replay viewer, various editors (like Quintillus' Editor! ).

We only need to investigate, what we could use and of which tools we can obtain the sources. Converting these tools/components from C or Java to C# and adjusting them so that they fit into our architecture is certainly doable. (At least "more doable" than converting an entire game like FreeCiv, CtP or Civ4 to Civ3...! )

What do you think?

 

[Puppeteer]

Would Ainwood be ok with licensing the code under the MIT license? As far as I know, he's been pretty tight about the code to date. It's also clearly relying on some out-of-date .NET APIs, but unlike FreeCiv, I would love to adapt the CAII code to current C#.

For that matter, I don't think code for the other projects you mention is readily available, especially for review in use in writing MIT-licensed code. (Well, Quintillus is hopefully on-board.)


As a side note, I have taken to thinking of 'the map' as an index, not a meaningful data structure in itself. There is a collection of tiles, units, cities, and such, yes, and they all have coordinates and other object properties, but 'the map' is just a relationship lookup index or set of indices. I came to this conclusion after noting the duplication of data between the map in the sav file and other entities. Like the map data stores a city ID and top-unit ID if present, but that's redundant to the city and unit coordinates. But when drawing the map it makes a lot more sense e.g. to have an index that says "draw a red warrior at 2,2" rather than parse the whole unit collection every redraw.

 

[Ozymandias]

Thank you all for your candor. as well as detailed comments, and explanations.

So, it sounds as though- so far - we have learned that using a 400,000 line code base to launch our project is unappealing (as I feared it would be, simply because of how excellent, and very much cutting-edge, our tech comrades are), and that beginning an entirely new style (meaning learning, and then using, much more advanced tools, like Godot) has its own set of very much questionable issues, from the point of view of developing a new game. And, from almost any POV, these means that 3 of our 4 Heavyweight Tech gurus (and I cannot emphasize how much I genuinely understand this) prefer different directions altogether.

Al that being fully said, I'm. comfortable going with Freeciv, because:

• For any game or other type of code building, etc., you always need some sort of functional description of what your building. This is necessary, irrespective of which language, code base, or engine is used ...
• And the thread/list which @Civinator began, in what already feels (to me, anyway) like a long time ago, is - or could be - the beginnings of either a "laundry/wish list," or the beginnings of how we begin to undertake a new effort.

(As an aside,I am remorseful that I introduced "business speak" into this conversation, so early on - But it the only one I know get projects of this scope started, even made purely of pass ion - off the ground. But perhaps it's been fruitful, as I cannot imagine anyone not recognizing a dividing line between One's Daily Drudge and Passion; this is one of the reasons why I - however clumsily - offered up being the coordinator of any and/or all of what is needed, from helping to organize our respective Wish Lists towards something which code, and coding efforts can be done. Another simple reality is that, were we to proceed under the "umbrella" 501(c)(3)) - non-profit corp. - approach, and I think we all know who be tending to that. And I would do so with joy, because this would mean that we'd sufficiently nailed down the project, in "legal stone" while we continued to keep on happily doing whatever that might be (BTW, I pretty sure that any documented work for a 501(c)(3) would be a tax deduction, based upon either your billing rates, and/or your salary.)

This all brings me back to my insistence that any effort we collectively undertake by done in an OO fashion: not only facilitate communications between The Most Tech Savvy and the "Much Less So" among us. First off, an OO development strategy would,I believe, be the best methodology if we choose to pursue either the "building from scratch" or "building on top of a code base" approaches. (At least, I think so: I've not kept up on the best-practice methods regarding rapid methodology, for code storage-libraries "down stream" development release methods,development of for 5

Beyond that, waning passion, and/or unexpected events in one's R/L, should simply be expected. Using an OO approach might make possible the resurrection any "orphaned" items. Tthis one of many reasons why I keep mentioning Freeciv: that a single OO module - whether still the in Visio (the Microsoft charting program I use) or pen and in - can be rely completed. Also recall my mentioning that provides a common :language for coders and no-coders.

Furthermore, each "thing" (an individual unit) or "aspect" (what are the rules needled or that Unit to properly move across a Tile, so that - as a random example - a Battleship doesn't "float" four Tiles inland, to bombard your Capital from a Mountain Tile?

Freeciv already has rules in place to keep your Battleship from becoming a lethal Noah's Arc. Yes: it plays like Civ2, but these Rulesets can be incrementally treated, and then as OO objects. And the construction of Rulests certainly seems easy enough, and its integrity etc. is testable via an online utility ...

,,. OK, I've forgotten to mention that the game is a servant/client design - which I believe makes our job easier, as fault isolation is much easier; and we have full aces to the code so (1) it's portable and (2) preserving aspects of this might facilitate multiplayer options.

Do, what needs to be done? -

1. Anyone interested should play a round or two of the game.
2. Rulesets should then be compared to every variable and rule in Civ3, hopefully ensuring that "plug compatibility" resulting from combining the 2 games can be defined (i.e., do all Unis and Tiles have the sane Factors (From Unit movement Factor to Terrain Tile Movement Cost; etc.) The more of these which already exist, the easier our job.
3. We the proceed incrementally, making Freeciv more and more like Civ3+ (or whatever we wind up calling) it.)

That's it: an incremental conversion and implementation, in whatever steps/releases we decide. And releases of a functioning, , plug-compatible will (I think) an ever-increasing interest with ithe overall C&C community.

One last item: I think I've neglected to mention that Freeciv uses .dlls - and I caught a mention of it being possible for each Civ to have its own .dll! How's that for modding options?

AND we can basically use Quintillus' editor (along with the only service to- I assume - check a new, individual Ruleset's integrity ...

And so you have my vote, with a further emphasis that "hooks" can be built in for any future, complex implementation. Accordingly, my suggestion would be to:

1. Become famiiar witt the game.
2. Idenitfy what game assets (and aspects of play) are important, and which of the extraordinarily well catalogued (and well documented) Rulesets apply.
3. Rinse;repeat.
4. Become, and stay, well-informed about whatever anyone else is doing, and vice-versa, and coordinate and "cross pollnate," wherever possible.

Lastly, I will also soon begin the Final Quest for the Holy Grail - Civ3's source code - by attemptng to contact Soren, Himself, within the next week or so.

Depending upon the involvement of our Tech savvy folks, I'm betting that we might possibly be able to roll out a, "proof of concept" release within3-4 months - and then see who else might want to help. And, for "proof of concept," I specificaly mean a fully Unit and Terrain compatibe platform, almost certainly still "working" more lie Civ2 than Civ3.

- Anbd I beliee I relly, reallly do have a way to make a vstly more intelligent AI, using simple mans, with (among many other items) making Armies, Artillery, and genuine AI strategy work together, utilizing a siimple, "beehive-like"system.

 

[Quintillus]

I like the idea of reaching out to Ainwood et. al. about the potential to re-use parts of other utilities. I believe my editor and Puppeteer's work is the only open-source work amongst those, however, so it can't be taken for granted. But I agree with Puppeteer that adopting CAII's code is likely to be more appealing than adopting FreeCiv's code (more on that later). It also has some clear advantages in Civ3 compatibility.

WildWeazel has a high level design document, but it probably does make sense to come up with more specific ones as we get to certain areas, so we don't wind up with a bunch of incompatible components if nothing else. My preference would be to take an incremental approach; as an example, WildWeazel's high-level document divides the approach into 17 sections; I don't think we need low-level requirements for all 17 before starting, but it would be helpful to have the first two or three, with some awareness of how it might interact with the rest. It's also a good point that keeping good documentation will help with getting more people who are interested to the "contributing" phase.

I took a look at some of the Rulesets that Oz mentioned in this post. The summary is that they look like a relatively nice, human-readable way to customize the rules within the bounds of what FreeCiv supports, but I don't think they would make it easier to add new features to FreeCiv where it doesn't already support something that FreeCiv supports. It did further my thoughts on that approach, however; my initial thoughts there are if we still want to explore that route, it would make sense to start with adding a very small feature to FreeCiv, while also cataloguing what the gap is between FreeCiv and Civ III. I think this is more or less what Ozymandias mentioned in the "what needs to be done" section.

I'm still not necessarily convinced that's the way to go versus the Godot route, but I now see more of a path for testing the feasibility of it.

I also suspect Lanzelot is right that - at least where there is overlap in skill sets - focus will be important given ambitions. In my mind, that doesn't preclude Flintlock's .exe approach (which is a different skill set - although perhaps Flintlock would also be skilled at FreeCiv approach or even the Godot approach). However, early on (and now that we have discussion moving again, I'm more okay with it being "early on" and not diving in to code), it may be necessary to test the waters in a few approaches to better inform ourselves what the depth of each approach is.

(At a meta level, I think it also is a good thing that higher-level discussion has been rekindled. While there was some effort to start writing code last month, with discussion having died down and code being seen as a way to show progress, I like this new discussion we are having, and I think it is more properly framing any current coding/code examining efforts as still preliminary/exploratory/prototypes. I'm also more comfortable with the design discussions as we're getting more people's input, and balancing more ideas)

 

[Flintlock]

I’m going to begin by suggesting that we put aside both the .exe patching and .biq/.sav utility approaches. My reasoning is quite simple: nothing we do, by either of those means, can (for example) fix how the AI handles artillery

Is that a challenge?

The thing with the AI and artillery is that it actually does already know how to use artillery offensively, it's just only willing to do so with units that it's captured. So fixing its behavior might be as simple as fooling it into thinking that all of its artillery has been captured. But still I get your point, there are many desired mods that are not feasible to implement even through EXE patching, the best example IMO is an increase to the 32 civ limit.



I've been holding off on commenting because this doesn't feel like *my* project. For me, and I think this applies to others here based on what I've read, I'm interested in this project and can imagine myself contributing code to it but I can't imagine myself devoting years to it, which is not to say that I definitely won't. The broad technical decisions like which language to use should ultimately be made by anyone who *is* willing to devote years.

Now in spite of that I'm going to offer my own bit of advice which is that for modability, C# is hands down the best choice. The most moddable game I've ever played/modded was Rimworld, and that was thanks mostly to C#/.NET, and also to the devs' work making the code modular. @Ozymandias mentioned that in FreeCiv each civ can have its own DLL. Rimworld does one better, every game object and even many game mechanics can be overridden by custom classes loaded from DLLs. What's more, the C# ecosystem is designed to facilitate that. So unlike in C/C++ there are no header files to worry about, there's no build environment, there's no worrying about DLL compatibility due to implementation defined behavior across compilers, etc. To mod Rimworld, you just load up your IDE then add Rimworld.dll as a dependency and you can just use all its types and functions. You can define a class that inherits from one in the base DLL then tell the game that whenever it spawns one of your modded objects, that object should be an instance of that modded class. It all just works, there's no need to create a modding API because the game's internal interface is the modding API and it's all automatically available through autocomplete. There's no need to worry about mod cross compatibility because all .NET DLLs are compatible across OS's.

although perhaps Flintlock would also be skilled at FreeCiv approach or even the Godot approach

I don't know if I'd be more skilled at that, but I'm sure I'd have more fun reimplementing things from scratch, even the engine.

 

[WildWeazel]

Oy, this thread got away from me. (But thanks to all for chiming in!) I'm probably not adding much that isn't already said, but just to lend my opinion:

Oz, you make a good case. This certainly has technical merit. Freeciv is the most mature baseline of the things we've looked at. In fact it's probably the most technically successful open source strategy game ever. If this were a business venture it may have the best ROI, and we could throw resources at it to make sure the right people are doing the work. Here though it all comes down to what people choose to spend their time on, and I'm not hearing much enthusiasm.

To be honest, my biggest hangup with it is the C language. I'm not confident with it, it's going to be slower going than C#, and I just don't want to dive into it in my free time. I know it's pretty lame to respond with "but I don't wanna write C!" which in business would be shorthand for a resignation, but I fear it would just sap our motivation right off the bat. On the other hand we're enthused by the prospect of starting fresh with a cool new engine, and it's really hard to outweigh that on a volunteer passion project.

Now, that said: the above is reflective of our current team. To say something shouldn't be done because we're not interested is putting the cart before the horse. If there are people who are interested and have the skills (and especially if they're familiar with Freeciv), I'd say go for it. I wonder if it's worth putting some feelers out in both communities, not for interest in the concept but to see who actually can and would contribute. As I said before, at this early stage having more irons in the fire can only help.

 

[WildWeazel]

By the way, this is neither here nor there, but just to avoid any confusion I think people are using "game engine" in two different ways. There's the core gameplay logic that we'd possibly reuse from another game (as in this proposal), and then there's an off-the-shelf framework (as in Godot or Unity). I don't really have a better term for the former, but "game engine" formally refers to the latter. Making a game "from scratch" presumably means using Godot/Unity. I don't think anyone here really wants to write a whole game without those tools.

Side note: @Flintlock we should talk about Rimworld modding! I haven't played but it's a case study I wanted to look at for designing the mod system.

 

[Blue Monkey]

I've kept silent for a couple of unrelated personal reasons, but more importantly because there doesn't seem much I can meaningfully contribute to the decision making at this point. I'm definitely in, but whatever technical skills i have are for visual design (static graphics, mapping, etc.). So I can only agree that (a) we need to craft a project that is doable within our lifetimes (b) reaching consensus on the fundamental level of programming language/coding/game engine will allow actual work to start.

That momentum will motivate everyone involved to pursue creative discussions at a "how" level rather than "what-if".

 

[Civinator]

I've kept silent ... because there doesn't seem much I can meaningfully contribute to the decision making at this point.

That is exactly my position. This is a decision for the programmers. I am enjoying the benefits Flintlock is giving to Civ 3 and I am glad about any progress that is added to Civ 3.

 

[Blue Monkey]

I posted some remarks from my experience with mapping & terrain graphics in the thread started by Puppeteer. I've just been thinking that it may be a bit too tangential to the purpose of that thread. So i'm wondering if - at this stage of the project - it's worth creating a thread to discuss terrain and mapping from a scenario design and graphics creation perspective that is separate from the programming considerations. Mixing the levels in one discussion may be hindering rather than aiding the overall game design. Perhaps it's premature to start a thread. It's just a question.

To give just one practical example - The answer to "Should Flood Plains be an overlay or a base terrain?" is at a level closer to the player / scenario designer's experience, and the consensus may help the people dealing with the coding, arrays, etc. to best use their time.

 

[Puppeteer]

I think that could be useful soon-ish. I've always found it odd that there seems to be no consistency in what is overlay and what is base terrain. Hills, mountains, and flood plains are overlays but can't be chopped or cleared like forests, jungle, and marsh. Also, hills and mountains may have bonus grasslands underneath them. Weird. Maybe it makes sense from a map generation algorithm. (Oh, and then there are volcanoes which can't be improved and are animated. :/ )

I guess it makes sense to me that we can start nibbling at the Civ3 end and the final-destination end, but planning too much in the middle seems premature to me. I know Oz is really excited about AI, but I can't even begin to think about implementing it because I have absolutely zero idea of what the inputs will be. I've mentally refactored the legacy map code several times already, but even there it's still to early to properly separate the pieces, although I'm getting some ideas.

Questions like whether base terrain and overlay terrain should still be a thing are worth having sooner, though, in my mind. And to some degree how graphics work, because if we're adding tile types this per-tile graphic system will become impossible to manage quickly unless we're happy with hard edges to terrain transitions, but I think we can do better than that without exponentially increasing tile graphics sets.

Another topic may be core entities: what is the difference between airfields, cities, colonies, goody huts, and units? They all have coordinates on the map, a beginning of existence and/or end, and a visual representation in the map view. Can cities be modded to be mobile? (Must construct additional pylons!) Can colonies grow to be towns? Can airfields grow into colonies? In other words, is there one core "thing" that is modded into cities and units and such, or are they distinct concepts? For that matter, terrain can change type already due to global warming; can terrain move? Be terraformed? be replaced by entirely new terrain?

 

[Blue Monkey]

(a) I'm not sure what you mean by "middle" in this context. During my professional tech support analyst days to some people three levels meant hardware, machine code, programming language. For others it was binary, assembly, programming, or hex, programming lang, user interface, or OS, shell, UI ... so do you mean programming language level, game engine at the db & function level, then player experience?

(b) I have some specific ideas & inclinations as to mapping & terrain. But I'm preoccupied over the next few days. Finally got an appointment for the COVID vaccination - in another town - for one thing. So if someone else feels the urge to start a thread feel free. If not I'll start one when I'm free to focus on it.

 

[Puppeteer]

I guess I'm talking about data structures and object models. Our constraints for a new game are full backwards compatibility with existing graphics, audio, civilopedia, mods and saves (most likely via one-way conversion), and we have a laundry list of bug fixes, limit removal, and new features.

My background is in production support, in dealing where ideas, code, infrastructure, and libraries meet reality, so I guess as I code and design I always have that conflict in mind. Every choice we make opens some doors and shuts others. I want/need to know inputs, outputs, mediums, and formats.

So our current anchors/endpoints are the Civ3 media and data on one end, and a yet-nebulous C# object structure, save schema, and Godot-sensible media formats on the other. The middle would be working on procedural terrain generation when we don't have tile schema or a concept of how we're going to enable more tile types being drawn next to each other, or coding AI when we have no meaningful game data or player API/controls. Not to pick on Oz; those are very cool things, but my approach to coding sees no way to define the inputs or outputs for those yet.

One of the wish list features are navigable canals. It's definitely worth talking about from both a game modder point of view and a coder point of view if those are tile improvements ("boat roads"), overlay terrain, terraforming of existing terrain into a new tile type, etc.. But it's a bit early for me to think much about whether they slow land unit travel like rivers do before Engineering and how that restriction would be implemented in code. (Also questions like can they allow adjacent irrigation, is there a defense bonus or attack penalty...good designer questions, but perhaps too early for how to code it.) But discussing what each thing is and how it's like or unlike other things may help guide the object format/schema and game rule/game engine system design.

But that's how my brain works. Maybe it's not the right way to approach it.

I'm not going to lead/drive new design work just now. I've got my thing going with decoding the file data and figuring out graphic tile selection. I've already changed my mind several times on whether it will be possible to mix my read-and-display-from-pcx map bits with a newer style display.