Map Generator Model

[Mark_Everson]

F_Smith:

I didn't mean to chase you away, just to change the topic. The drumbeat of OO design principles truly just wasn't being helpful At This Stage IMO. So please feel free to abandon your lurkerhood whenever it suits you

Mark

[F_Smith]

Mark:

Just wondering if you have had a chance to look at that "Civ II Evolution" game project that the patron saint posted.

From that page's 'Status' section--

The development will take three stages:

[*]Preparation: The construction of the software framework. A lot of work, but it's virtually done now. [*]Rules Development: Concurrently implement new ideas, test them and develop the AI. [*]Modernization: The rules are fixed now. Artifical intelligence and user interface are eternal subject of improvement. [/list]


So I'd like to make one last stab at this -- ya'll should not be fine-tuning the game rules (the models) yet. Because they will have to hang off of the basic program framework, and a simple framework change can change everything about the model. You can't build a car by asking one person to make the tires, another to make an engine, another to design a body, all with little to no coordination of design. It almost certainly will not work out when it comes time to put the pieces together. I've seen this happen before.

I really believe, from my experience in software development, that this is a seriously important deal-breaker. It can (and has on more than one occasion) ruin a perfectly good project. I feel I'm only trying to save your project. So forgive me if I'm being 'anal' about this. But I'm pretty sure this has to be your next step, if the project is to ever be finished.

[Mannheim Tanker]

I'm using my gaming alias here, but y'all know me as Paul Crocker I've also returned from my lurkerhood to echo F Smith's concerns. I'm involved in an incredibly complex project at work (government projects seem to always have much more complexity than a sane mind would deem necessary). We're grappling with similar problems - we have contractors around the country developing separate modules for a hardware/software system. A major part of my job has been to coordinate the integration of these modules - and I've noticed that working out many of the small details at this stage is a fruitless battle since core design changes often make these details irrelevant. I'm sure you've much more experience in this than me, Mark, but I just wanted to underline what F_Smith is saying for the others that don't have experience in developing complex projects.

BTW: I also opted out of taking on a major role because of 1) time restrictions,
2) 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).

When time (and energy) permits, I hope to rejoin the team in a larger role. In the mean time, I'll continue to lurk - and wish y'all the best in making progress on Clash! I still see progress being made - I just hope everyone keeps the long-range focus that's necessary!

[F_Smith]

Mark:

Actually, it's the other way around.

The gaming industry typically consists of small companies with a handful of programmers and no actual architects on hand (they can't afford the skilled people -- most of those companies don't pay much, and only employ people willing to work for cheap because they love games). And they often end up with 'cowboy' coding as their 'methodology', often with a focus on the single angle they are interested in -- usually graphics.

The few game designers who tend to have an over-arching vision for a game are the obvious ones -- Sid Meier, Blizzard, EA, etc. One perfect clue that a company did *not* do the design well is a lack of customizability. Personally, I think we're trying to keep ya'll from becoming one of those 'others'.

As far as examples, there are several. But one comes to mind almost immediately: the tech model. You have people spending oodles of time on algorithms that won't get used. Developing instances of tech objects that haven't been designed yet. All that work will have to be redone, almost certainly.

You see, first the code framework must be laid out. The specifics of the tech system don't matter yet. Once designed, the framework will be able to handle any tech system you design -- which will allow you to change, tweak, and fine-tune the tech system to your heart's content.

What *should* you do, in my opinion? First, take the tech system as proposed. Break it into objects. Define those objects -- especially the required methods. The functionality in those methods (this is where the algorithms come in) will change later, but it is imperitive to know what the types of behaviors will be! Then code up a prototype, with one or two examples of each object. Then distribute that prototype to people, and let them play with it. After getting all feedback, only then do you begin to worry about the specifics of all the various 'techs'. This gives you the demos you want, more excitement from the participants, a faster development cycle, and on, and on.

Specifically, you have a tech system with 4 levels. Question number one -- are these to be 4 seperate objects? Will some inherit from others? Will some encapsulate others? Are some actually the same object?

Answering just this first question will go a long way. And the choice between inheritance and encapsulation will have a major impact on the shape of the final product.

How do you feel the tech objects should be arranged? Encapsulate or inherit?

As far as fun, that means (to me) that it has to be a well-designed program. Nothing is more of a fun-killer than a poorly designed interface! And actually, ya'll and the Civ2E people are engaged in exactly the same kind of project -- creating a game program. The rules of the games will be slightly different (but not so different as the ones in an RTS, or a FPS). But the rules don't matter, since a good game program framework will be able to handle any rules if it's designed well. The module types that both projects need will be identical. Only the implementations will differ.

[Mark_Everson]

All I can say is IMO before you model objects you need to model the World. How can we define an object hierarchy before we even know what Happens in the model. If we don't even know for sure the car Has tires, how can we define the 'tire' object and its interactions? Before we didn't Know for sure the 'things' or interactions in the tech model. Any generic OO model at that point would have been so general as to be useless IMO. In terms of the tech model Now (but we Just got there) it seems to me fairly simple... Levels 1-3 techs are really the same type of object, and level 4 (applications) is different. Probably the two object types will share an interface since there is some commonality between them. Garth will probably do this shortly. What is the big deal? Richard, afaik doesn't kapish OO programming so how in the heck was he supposed to do the OO part?

However this is all horribly OT. If you want to discuss further, please copy some of this stuff into a new thread... and give it a push.

added afterwards:

I'm sure you can tell I have never had a software class since Fortran . If it helps any Garth is also much more into the code organization thing than I, so your savior may be entering stage left soon.

[This message has been edited by Mark_Everson (edited March 07, 2000).]

[Mark_Everson]

F_Smith:

I know your intentions are good , and I'm glad you're back!

F_Smith and Paul:

Yes I have looked at Civ2E, both before and again recently. Maybe there's a defect in my understanding, but IMO the projects are completely different. They are implementing an already existing and Tested and (somewhat) balanced rules framework. Their approach is quite reasonable for Their project, but IMO Not for Clash. I think their approach is what is generally used in the gaming industry, and you can see for yourself how many Atrocious games come out. We are trying to use the 'Sid' design philosophy of continually playing what you can cobble together to test at all times for fun and playability. Sure there will be lots of wasted effort involved, but this Isn't engineering. We don't know what the framework looks like yet... how can we make detailed object models?

Some people are talking about really detailed things in the Clash models. The only details I'm interested in now is ones we can throw into a demo to see if our basic concepts are Fun. I wish we had more people who were more interested in the big picture and how everything fits together, but that's life...

Perhaps I'm just the wrong person to be thinking about this, but I just can't see how we can plan the software framework before we have some knowledge of the models and their interactions. Thats what IMO we are trying to develop now. But there is a third factor that is not present in the kind of software projects the two of you have experience with. This has to Be Fun. We need to have some small details (just first guesses) to be able to gauge the Fun.

Maybe one of you can outline exactly what you think we Should be doing. The examples so far haven't made a good impression on me. There already are a lot of getters and setters... and putting in more are trivial. I get the idea that there are things beyond that that you are saying. I know we need objects for the models, but you can't envision the objects before you have the model, at least at any detailed level. And keep in mind that whatever the prescription it can't slow things down too much. We need as much continuous obvious progress as we can get IMO.

[F_Smith]

Mark:

You answered your own question in your first sentence -- ". . . before you model objects, you need to model the world." Model the world in an object model, which has not been done yet for the tech model. You just did that, tho, in deciding that there are two types of tech objects.

As you pointed out, it looks like ya'll have 2 objects required by a tech model -- basically, a 'theory' or 'field of knowledge' object and an 'application' object. This suggests that the concept of breaking the model into 4 levels is a mistake that can limit the models realism.

For a specific example -- what about applications that only require a single, basic piece of knowledge? Does it in fact make sense to require that to be a '4th' level tech object?

Is it possible that a more accurate way to model this might be to have 'application' objects encapsulate 'field of knowledge' objects as requirements? An application can require one, two, four, a million differing 'fields of knowledge', each 'field of knowledge' can have it's own level of specificity.

This obviously gives much more power and flexibility than a static model, and more customizability as well.

This hierarchy supports your tech model, and also supports any changes you might wish to make -- even if you chose to completely re-do the tech model to include magic, or psionics, or whatever. Once this framework is coded, you can go back for game-play reasons and force a 4-tiered structure if you wish.

So the second step, now that you've defined two tech objects (we'll call them 'fields of knowledge' and 'application', for now), is to define their behaviors.

What methods do you think each should have? What behaviors do they have in common? Should they each extend an abstract 'technology' object? Or would you rather use an interface? Personally, I'd almost certainly inherit from a 'tech' object, because that will make it easier to handle them later, in loops.

So, specifically,

[*]What methods should 'field of knowledge' have?[*]What methods should 'application' have?[*]What methods should be moved up to the 'technology' abstract class?[/list=a]

I'll create a thread, and also paste this there. I'll look for your response in the new thread.

[Richard Bruns]

I've had these ideas for a while but never got around to posting them:

I would like to see a realistic planetary map. The cylander approximation doesn't seem right to me. So I experimented with various map arrangements until I fimally came up with the simple idea of approximating the planet with a cube.

A cube inscribed in the sphere of the planet, with the poles normal to the top and bottom faces, should be a simple and effective way of modeling a spherical planet. The shapes are topologically identical and there would be a lot less distortion than any flat map system.

This can be done by defining six square maps and setting rules for how the edges line up. Normally, the screen would only have to display one square and a few rows of the adjacent squares. Scrolling over and changing between the squares should not be too hard.

The four equatorial squares would each cover ninety degrees of longitude and the latitudes from 45 south to 45 north. The two polar squares would cover all latitudes greater than 45.

I think that each of these squares should have a side length of some multiple of ninety. This would allow equatorial squares to correspond to latitudes and longitudes, which would create an intuitive mapping system IMO.

The map editor should allow scenario makers to set the rules for edge connections. A flat map could be made by arranging the squares in a 2x3 grid and setting the outside edges to No Connection. A map of the asteroid belt could be made by creating a line of all six squares and making the two sides connect. Again, this shouldn't take too much effort, and the customizability options would be well worth it.

[Lord God Jinnai]

I have a better idea IMO. Its based on an old game SimEarth. Basically you have your zoomed map which is flat or can be slanted like now, but what you see on the screen isn't disorted. On the side or whereever you have a sphere of the world with a square on it (can be a retangle since a square is a rectangle). The square doesn't move. It's always dead center, but you can move the mouse around and the globe will spin. We can make it so it doesn't do this too fast. That's not hard. Anway, then wherever you look at on the map nothing is distorted.

[Richard Bruns]

It seems to me that such a thing would be really hard to program. The cube's distortion would be about the same as the distortion of most flat maps.

[alms66]

I really like LGJ's idea. In fact, it's what I would have liked to have done from the start, but when someone suggested using hexes instead of squares, Mark said that too much work was put into the map already and going back to change it would be too much trouble, so I assumed the same would be said for this idea.

[Mannheim Tanker]

Hi all. I'm returning from Lurkerhood now that I've managed to get a hold on real life stuff (I had just moved across country and started a new job when I took my "vacation" back in Feb). First, I can add some insight to the discussion on map projections:

We discussed this in incredibly gory detail last year (do a search and you'll see). Since my job involves a great deal of cartography, I might add some insight to this discussion...When you make a map, you can have ONLY two of the following (unless you do it on a true, revolving sphere)

1. True direction
2. True area
3. True distance

Pick any two. We decided that in the interests of coding, and for simplifying the interaction with the map, it was best to have uniform tiles (same size as you move around the map). Sure, the cylinder isn't perfect - but NO projection is perfect (see above). Unless Mark plans on modeling a sphere (spheroid actually). I'd personally prefer an Alber Equal Area or UTM projection, but I won't confuse the issue by pushing THAT one Unless someone can point out a REALLY good reason why we should go to a cube, I'd say we should scrap this discussion and move on to other issues.

Edit: I should add that LGJ's idea is a good one, but it still involves a projection - just one that minimizes distortion when viewed at large scales (zoomed in). You would still need to use another projection to show the "big picture" (ie the whole world on a single map)
[This message has been edited by Mannheim Tanker (edited May 30, 2000).]

[Richard Bruns]

The Clash map is a Cartesian grid. Any map projection that is not based on two mutually perpendicular sets of parallel lines will mess up the relationship between what the player sees and what the computer is calculating, thus making life miserable in any number of ways. For this reason we cannot use equal area projections, a true sphere, or anything that bends longitude lines.

There are two kinds of maps that would work with the Clash gridding system:

1) A Mercator projection
2) A cube

The mercator projection, which is used in most games, has many flaws. Any movement near the poles will be seriously distorted, and moving over the poles is impossible.

A cube would model the planet much more accurately while keeping a Cartesian grid. It would also be relatively easy to implement, unlike most map projections.

I think that the polar movement ability and the greater accuracy of the cube compared to the Mercator map would justify the time spent making the cube map. Also, the six-square approach is a lot more customizable than any other type of mapping system.

[Mark_Everson]

Richard:

We've already done some of the map AI and its all based on cylindrical maps. All the code has a flat map based on diamond-shaped tiles already. We've just had to lock in more and more as time goes by or we'd never be able to make any progress...

Anyway, We have Extremely limited coding resources. Until we get the first implemetation of most things done, the things that work already need to stay as-is. I agree it wouldn't be all that difficult to make the changes you propose, and I appreciate the thought that went into making something that works by only moderately tweaking the existing setup. But I personally don't really find the improvements in gameplay from your suggestion to be particularly compelling... Its Very difficult to supply an army up where the distortions become quite large anyway.

LGJ:

Cool suggestion. Perhaps Much later in the project we could look at implementing an appropriate transformation. It would probably look really great, and would be useful for jumping large distances in the detail maps.

[This message has been edited by Mark_Everson (edited May 30, 2000).]

[Mannheim Tanker]

On a side note, an equal area "would" work - I use them every day at work. The down side is that you can't view the entire map at once...something that would also happen with your cube-map. In any case, as Mark said, this is a dead issue, so I'll shelve it right here.

On another note, I think I've found something that would work well in conjunction with LGJ's idea: Being able to rotate the map (like in ANNO 1602 by Sunflower Gmbh.) would allows the player to view the map from different perspectives. This works great on a 3-d type map (such as we're doing). Not sure how tough that is to code though... in any case, I think we need to keep LGJ's zoom mode in mind for future work.