Project Communication Problems

[Richard Bruns]

When reading the Map Generator thread as part of my work on the Ecology model, I found this quote from Paul Crocker:

quote: BTW: I also opted out of taking on a major role because . . . I felt that people were worrying too much about minor details rather than tackling the basic framework (FE worrying more about adding coral reefs, etc than how the whole thing fits together).

And this one from F_Smith:

quote: I have gotten the feeling that my input is not proving valuable to ya'll, since most of the people on the project seem to disagree with my focus on a good object design as the heart of any program. So to avoid any more difficulties, I will now to go back to lurking, permenantly.

In other words, two people stopped working on the project as a result of the work I was doing.

I am concerned about this.

I joined the project in November of 1999. At that time, the project had been going for about a year and three demos had been produced.

When I write a program, I first code up a minimally functional core loop, test it, and then add new features to that loop. Most of my friends did the same thing, so I assumed it was standard practice. This worked fine with the procedural laguage we used, and at that time I didn't know that there were languages other than procedural languages.

So I thought that those three demos were the first iterations of the "core loop" that would serve as a structure for the more detailed models that were being produced at the time. I figured that the basic code framework had already been established, and that a well written and well documented procedural model would fit right in.

There were no programmers working on the tech model, so I tested it using my mathematical modeling knowledge and some procedural programs that were easy to write. At the end of this testing, I wrote a detailed design document. I figured that the coder would be able to turn the system into a procedural program like I had done and then fit that into Clash's core loop.

I didn't learn the fallacy of this until a couple months ago. By that time, the damage had already been done. I had spent over half a year using an inappropriate design process, and my model had alienated two people who knew two basic facts about Clash that I did not know:

1) We were not using a procedural programming language.

2) There was no "core loop" or basic program framework that my models would fit into.

Each of these people saw that I was wasting a lot of time by using a flawed design process. They saw this as a symptom of the inability of Clash to produce anything in an efficient manner, so they figured they would be wasting their time by trying to contribute.

They could be right.

In half a year of working on the project, I was never given a primer on what the state of the project's code framework was. I was not told what the programming language could and could not do. I was not given any instructions on how to make models that would be compatible with the programming language and the project framework. I was not told what could and could not be changed. I had to find out all of these things by trial and error, and the result was mostly error.

I wonder what would have happened if I had been given some simple information like this when I started working. If someone had just told me to read the first chapter of "Thinking in Java" last November, I probably would have been far more productive.

The past is over and we can't fix it, but we can take steps to make sure that mistakes are not repeated. I think that every Clash project worker should know the following:

1) The basics of the Java language and OO design.

2) The current state of the code/design framework.

3) What is already coded, and how that affects the models in development.

4) How the model relates to the rest of the project and how it will share data with the other models and the GUI.

Model makers will have to understand those issues before they can progress with any efficiency. Currently, the lack of this knowledge has resulted in a lot of wasted effort. I still don't understand some of the things listed above.

This lack of knowledge and communication also seems to be a big source of frustration. We have not created an environment where people can work intelligently and productively, and this is probably a factor in the high turnover rate. Paul Crocker left in part because of this issue, and F_Smith almost dropped out for the same reason. I think that this was an important factor in the retirement of many other people.

This could also be a part of our recruitment problem. Currently, people who want to work on one model have to go through mountains of unfiltered information before they can even start to see how their work fits in. If the information in parts 2 through 4 above was listed in one place, I think that people would have a much easier time jumping in and working on a little part of the game.

Basically, we have to develop better ways of working and sharing information if we are to be productive and efficient.

There are a few more communication issues I'd like to discuss, but this is the most important so we should concentrate on it for now.

[Mark_Everson]

Richard & All:

I didn't think, and still do not think, that your work on the technology model was in any important way misguided. However, I do completely agree with Paul Crocker's statement that people are spending way too much time digging far down into the details of models and not spending enough time worrying about how the high-level pieces fit together. And whether the thing will be fun. I think you need look no further than the recent Comprehensive Animals Modeling thread to see the sort of thing Paul was talking about. I think that this topic in aggregate is more likely to hurt the game than help it, because people coming to the forum see game participants going way overboard IMO into unrealistically complicated models of the world. I expect a fair fraction of them will leave the site chuckling never to return. I may be wrong, but this is just my impression of it based on some early feedback that I got on clash from a few people who design games professionally.

These individuals looked at an early design of Clash, which is not Nearly as complicated as what we have now, and said that it was hopeless to try to create such a complex game. I disagree with them, but when I see the world model getting ever more complicated, I get very concerned. More complicated means it's harder to have the AI do the right things, harder to do the interfaces properly, and harder to tune the behavior of the world when it doesn't come out right. I think F. Smith is right when he says that the object model the game is coded in should allow for this complexity. It will allow us to change direction rapidly if we decide there is one critical thing that needs to be made more complicated. But to actually attempt to utilize most of this potential complexity in the actual game mechanics will IMO kill the project.

So my plea, which I will place beside Richard's, is for everyone to think about things that are Absolutely Essential for gameplay, and to temporarily put aside everything else. If you can program, or think you can learn how to program in Java, then programming is the most important thing you could be doing. That is because only by actually putting some of the big ideas in the system into code will we start to learn if they are fun and work properly. I am not knocking the spreadsheet models of some areas, they are also valuable. But in truth we can't gauge the feel of the game from a spreadsheet.

If you don't think you are suitable for coding, and are just working at very small details in your area, especially if it is far from being actually programmed, please consider thinking about the interface for some area. We have had very little discussion of the player interfaces for the models in general, and this is a Big issue. Or take of fresh look at a model you are not familiar with and picture yourself playing using that model.

I need to think about the documentation you are requesting... I'll see what I can do, but Really that is what the web page is for. IMO you (Richard) have found a couple holes in the documentation over the time you have been working on the project. And furthermore, as one of the few programmers on the project, I need to spend more time programming and less writing long tracts. For those models that have active leaders, the leaders need to take the initiative to keep the summaries current. And now that we have an active Webmaster again, get the current summaries up on the web page. And at the start of each page should be a description of few paragraphs long describing what the player gets out of the model in terms of Fun. Not realism of the world model, fun. I have to admit that has default guy in charge of the military model since Harli took off, my progress has been lacking. If someone doesn't show up shortly (some possible irons in the fire now) to take over the area, I will do my best to post a coherent new web page for that area.

I also think describing fully the current state of the code is completely impractical. There are tens of thousands of lines of code, and a reasonably complete description would run many tens of pages. However, I am hoping to use some of the current code information on basic variables etc. to push forward the discussion of architecture that F. Smith suggested. So some of this will come out in the foreseeable future anyway.

[Beör]

Having recently emerged from lurkerhood, I have to agree with both of you. The real danger for this project lies in too much attention to details. Discussing whether cats, dogs or porcupines should be modelled is not very constructive, when essential models as the population model is not in place.
On the other hand I am sure that F_Smith would say that the detail is really not a problem. If he said that - I would agree wiht him too : Provided we can come up with a robust OOD, scalability and detail should be no problem.
I think that issuing a functioning demo 5 could be the all important milestone. If it can be shown that the basic framework works, we have something to build upon.
May I suggest that someone starts a thread with a short statement of what should be in demo 5, what has been achieved and what is lacking. It should also include a list of what will not be included in demo5, in order to avoid too much attention on issues that are not relevant at the moment.

Note: Just for fun I played civ 2 for a couple of hours this evening (in Europe that is):

WE CAN DO BETTER!
[This message has been edited by Beör (edited September 16, 2000).]

[Mark_Everson]

Beör: Look under "Demo 5 Central" on the web page.

[Richard Bruns]

Semi-Random Comments:

I think there is a vicious cycle that determines the actions of model designers:

1) We design a simple model.
2) We get bored because the model doesn't get programmed.
3) To relieve boredom, we add more features to the model or make new models.
4) Extra features and models scare off potential programmers.

Another thing is that most of the current model leaders place realism as one of their top priorities. A look at the members page shows that Rodrigo, Toubabo_Koomi, and I all listed realism as a priority for the game. Discussion seems to show this to be a priority for others as well. If it doesn't make sense and would never happen in reality, it ruins the game for us. Examples would be Zulus developing horseback riding or a horseman being produced in a city that just suffered population loss due to starvation. While some may scoff at modeling animal populations and attributes, we see it as absolutely necessary to preserve good gameplay.

Also, we tend to assume that the basic framework is already complete and that it is just waiting to be coded. I still assumed that until a couple days ago. I figured that all the framework was mostly finished and set in stone, and that the animals would just be put on the framework whenever it was done. The only people who know that the framework is messed up seem to be the programmers, and they don't have time to think about it or fix it.

And that is why I discuss communication. If I had known earlier that the animals thread would seem silly, I wouldn't have started it. I know now that there is a problem with the game framework, but I still have no idea how to do anything about it.

By the way, working on models does not cut into the time I spend learning Java. I can only handle so much arcane syntax at one time, so I have to switch to something else to preserve my sanity. I'm learning as fast as I can, and abandoning model work would do nothing to make me go any faster.

Javadoc can turn all of the comments in the code into HTML documentation. Some of the code I looked at was well commented, so why don't we just run javadoc and post the result?

I'd love to work on the military model, but I don't think Mark would like the result.

quote: IMO you (Richard) have found a couple holes in the documentation over the time you have been working on the project.

What does this mean?

[Richard Bruns]

Beör: The population model is in place. I finished it a while ago. I've even converted it to OO design and we discussed the code. But like most things, it is waiting to be programmed. F_Smith said it looked good and that he would program it whenever he had free time . . .

Meanwhile, I got bored and went off on tangents.

[Mark_Everson]

Hey Richard:

I think your vicious cycle argument is pretty reasonable. And I understand your arguments about realism. But there are always going to be things that are unrealistic in the game. And by loading down the game with tweaks to make things more realistic, as I said above, the AI gets tougher to program, micromanagement almost of necessity increases, interface complexity increases, etc. I just fear that if we did your "perfect" game, all the details would be right, but it would have lost its soul.

I still don't agree with F. Smith that our basic framework is messed up. But he seems to be willing to put in the work to do it his way, and I am willing to learn from his example.

I know what you mean when you say that working in the models doesn't cut into the time spent learning Java. I have an analogous circumstance when I'm just too damned tired to code, but I can still throw sentences together to deal with issues on the forum. Although sometimes when I'm that tired I do more harm than good .

Coincidentally, I was just working on getting the JavaDoc for the current code up earlier today. But there was some weird stuff going on in visual cafe (which should automatically do it) and so I didn't finish it in half hour a should have taken to put out the JavaDoc and stick it up on our website.

"Holes in documentation" was just about things that were basically locked into the design that weren't always reflected in the documents. Like the military model being at the MapSquare level...

On the military model... LOL I think you're right

[F_Smith]

Richard:

I do feel that the 'core loop' ("alpha prototype", as it's sometimes called) has not been developed yet. I can not stress this enough. I personally do not feel that the Demo 4 code can be built upon, without massive architecture changes.

I would also agree that the model designers should learn basic OO design. They are designing a computer game, not a board game. Computer games are built with objects. They should understand that much.

P.S. -- It's just me, but the population model is indeed what I feel must be coded next. I feel that would be the beginning of turning out an 'Alpha'. But that has to be Mark's call.

* * *

Mark:

I would like to talk about the Demo 4 code.

I don't personally feel that it's there yet. Please don't be upset -- I realize it took a *massive* amount of effort on your part. You did a lot of good stuff in there. It's quite big.

But (please don't be angry) I think the design could be improved. I think there are several issues that must be dealt with. The program infrastructure needs a serious second look.

I also feel that Richard pointed out exactly how the issues can be resolved.

What Richard is referring to is sometimes called 'prototyping', or 'extreme programming' (silly, but that's the nom du jour). You build a basic core. Bang around on that. Get feedback from many sources. Tweek. Once you're sure it's scalable and logical, you add another 'piece' (model). Repeat.

In building a 'Civ' game, I feel the 'core' is the gameworld. You build a map, and stock it with resources and people. Once you have a reasonable architecture, then you begin to put this world into motion, one model at a time. You add governments. You add economy. You add warfare, disease, weather, etc, one step at a time.

Please don't take this as a criticism of you personally. You've done a fine job. You've been extraordinarily industrious.

[axi]

Yikes! Maybe if I had read this thread, I wouldn't have posted my infrastructure model. I spent all that time modelling a feature that won't even be in demo 5! But you see, we would have to do infrastructure someway eventually and I thought that was THE biggest missing part from the econ model. If I have made it too complicated, just shoot me!

It seems that I have fallen victim of the loop Richard has mentioned; all my contribution to Clash so far has been into refining the models and filling in the gaps (in other words refine what was left unrefined between the refined parts) From all that, only two things have been actually coded:
a) The TF power circles in demo 4 which was partly Mark's and partly my idea
b) The beast, which is partly based in the govt model which is partly (in a very small proportion, I'm afraid) based on my ideas.
And I consider myself lucky; other people haven't seen any of their ideas realised yet.

That was my self-critique, a process everybody should go through once in a while. On to more constructive suggestions:

1. We all concentrate on the demo5 issues, which is a simplified set of all the basic models and leave furter modelling for a later date. I am even willing to put infrastructure aside, although I've just finished working on it.

2. Create an object-based list of all gamedata the models involve so far. They could be sorted according to level and their public/private status. Each figure there should have model procedures (object methods) behind it, able to compute it. Models (and modellers)are only allowed to pick from these variables for the necessary input. That way we can complete the data puzzle (a minimum of it first, then we could expand) and have a leakproof datamodel. Because I feel that the biggest problem here is model interconnections.

3. Programmers get into "extreme programming" mode and the rest of us into "extreme debugging" mode to assist them. As far as I know, the beast shows no progress these days. Shouldn't we continue by adding other stuff in it (f.e. riots) and proceed into merging it with the existing econ model, tech model and demo4 code? Shouldn't the existant econ and tech model code get published on the web now, as it was done with demo4 code and the Beast code?

If I'm saying nonsense, please excuse me; I've been alienated from forum life these days...



------------------
"In a time of universal deceit, telling the truth is a revolutionary act."
George Orwell

[Richard Bruns]

axi: The infrastructure stuff is good. It goes a long way towards making that "foundation" IMO. It may not be in demo 5, but it would be a good start for the first economy tech cases. It was good to post, because we will be able to make sure the other models will get along with it.

I agree with points 1 and 2. However, there is no technology code. All we have are my object plans and OO design, which were posted several weeks ago. We might be able to salvage some of Garth's code, but I haven't been able to analyze it to see of it will help.

F_Smith and Mark:

I'll probably get some flak for this, but I'll say it anyway:

I think that it could have been a mistake to concentrate on the military in the first demos. IMO the military cannot reasonably be modeled without doing other stuff first. The game world and code architecture won't be able to support it. My view is that the demo progression should go something like this:

1) Map Generation and Ecology Modeling to define the game world. This will be more of a test case then a playable demo.

2) Add farming, hunting, and the population model. Assume a primitive hunter/gatherer or agrarian civ with no real economy or advancement. Player controls all activity and the player's people are the only people.

3) Add basic economic activity and infrastructure. Now we are assuming early settled civilization. Again, player controls everything.

4) Add basic government, social, and riots models. This allows us to model an early kingdom with proper player interaction. This kingdom is still the only one on the globe.

5) Add basic military actions and diplomacy. This allows modeling of the interactions of multiple nations. At this point, the player/tester controls all civs.

6) Add multiplayer support. Start by turning the #5 interface into a true hotseat game, and then go to other communication types. I think it will be easier to get this done and debugged while the game world is still simple.

7) (Concurrently with 6) Develop the AI. We should develop and test it while the game is still simple. Once we know it is competent, we can tech it how to deal with the additional complexity.

8-?) Add technology growth in small increments. Each time technology allows something new, the other models are concurrently updated and refined. In this way, we slowly build up to the complexity of the modern world.

I think this would be the best way of building up the gameworld. We would be starting with the basic stuff and then adding things that rely on the earlier models. If we made sure that we had a good foundation for the later stuff, it would be easier to add.

I'm not suggesting that we scrap the existing work. I'm just saying that it might be good to put some of it aside until the basics are covered. I think that adding the ecology model after the economy infrastructure is in place would be much harder than doing the reverse. The game world should be built from the bottom up. If the task force and military model codes are the basis of the world, we will have a skewed modeling IMO. It may not be exciting to do the ecology first and watch the world develop, but I think it would make a better game foundation.

Obviously we can't go back to step 1 and follow the timeline I listed. We already have some of the models from later steps coded. But I do think we should develop an ecology only test case after we do demo 5. Then we should add step 2 while developing the final, scalable game architecture. After that, we can start transferring existing code to the new architecture in a logical pattern. This should go quickly because the code will already exist and the models would have already been tested. We just modify it so it fits the new architecture. At the end of this process, we should have a good architecture with all of the working models.

What do you think?
: Dons Asbestos Suit :
[This message has been edited by Richard Bruns (edited September 18, 2000).]

[roquijad]

I don't consider a built-up process (from ecology to military, FE) the best way to go. Parallel working is IMO better because of the abilities and preferences each of us has. Personally, FE, participating in the mil model doesn't attract me at all. I think we should keep going as we are in the sense of parallel development and taking care of model interconnections. We just need IMO a better coordination and focus for what's really important and urgent. As Mark and others have said, we tend to start discussions around details and get stuck on them.

I'd be personally happier if you, Mark, start to act a little more like a boss than the leader you've been so far. Fewer carrots and more sticks. That should help minimizing discussions about details and focusing efforts on the most important issues and general framework. We all need on ocassions a warning when a new idea can harm the game or make it unecessarily complex.

Please don't take the last paragraph wrong, Mark. You've been a great leader, but we (the rest of us) have this silly tendency to get trapped in discussions around details, realism or historical accuracy and you're the only one here with recognized "authority" to let us know when we're pushing it too far. You have earned our confidence and we in general trust your judgement, so I believe you should use this leadership a little bit more to guide this project through the right path. I personally would appreciate it.

Just my humble opinion.

[Richard Bruns]

We can still work concurrently, and in fact that is what I suggested at the end. We build and test the models seperately, and then add them to the overall game framework. So while the basic architecture is being built up like this, the models can be developed sepperately and then added on.

Is this off topic? And if so where should I put it?

[F_Smith]

Rodrigo:

A 'build up' process is the best way to write the code, I promise.

The models can be developed in paralell.

Altho there will be 'dependencies', so it might be a good idea to keep familiar with the basic 'data structure' of the program.

* * *

Richard:

This seems like exactly the right place for this discussion, to me.