IWETHEY v. 0.3.0 | TODO
1,095 registered users | 1 active user | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New [Civlike] Anybody see any problems with this structure?
Still a work in progress, but if anybody has any massive holes they'd like to point out, go ahead.

[link|http://www.oz.net/~inthane/baseclass.html|Here.]

Don't criticize the HTML - it ain't mine.
They say a city in the desert lies/ The vanity of an ancient king/ But the city lies in broken pieces/ Where the wind howls and the vultures sing/ These are the works of man/ This is the sum of our ambition...
New Re: [Civlike] Anybody see any problems with this structure?
I have a couple of comments. Please take them with a grain of salt, since you know your domain better than I.

(1) sectionAsIso bothers me. It seems you are mixing display logic with the domain logic. I would rather see independent renderers that had renderAsSquare and renderAsIso methods. This could eliminate ISO as a map type and then take a look at the essential differences between square and hex maps (which I don't think is captured in the design so far).

(2) I would suggest Location as a better name for Point (Point brings to mind a mathematical point with no dimensions). Your call however.

(3) Several objects have individual x/y/z attributes. Does it make sense to have this objects have a single Point (or Location) attribute?

Just some general comments ... some of the interfaces look ackward. Have you implemented any of this and used it in a mini application? If not, I suggest you try it out on a small example first before you commit yourself too deeply to this design. Often just the act of trying out an interface will expose holes and misfeatures.
--
-- Jim Weirich jweirich@one.net [link|http://w3.one.net/~jweirich|http://w3.one.net/~jweirich]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
New Agreement -
what's the relationship between a point and a tile?

(I'd argue that a map is a collection of tiles...and that a tile has a point(x,y,z).)

Next question - is a city a tile? (It is in Civs and SMAC...but to make it a tile, implies that it can't move, and a fantasy type game may allow for cities to move).

New That's why City derives from Placeable.
It's something you stick on top of a tile - not integral to the tile itself. And yes, it does let you create mobile cities. :D

(It also makes it easier to remove the City object when somebody drops a planetbuster on it...)
They say a city in the desert lies/ The vanity of an ancient king/ But the city lies in broken pieces/ Where the wind howls and the vultures sing/ These are the works of man/ This is the sum of our ambition...
New Thanks.
Taken with the salt intended. Exactly the kind of thing I was looking for.

sectionAsIso actually is a workaround for an interesting problem - there are actually two types of "isomorphic" maps. One type is a regular "square" map, displayed in an isometric manner, similar to the maps in X-Com: UFO Defense. These have "flat" edges to the maps. The other is the "jagged" isometric map, that has used in the Civilization games since Civ II. Instead of taking a rectangular map, and rotating it 45 degrees, it rotates each square 45 degrees, then squishes them closer together, creating a jagged, but square edge. You're right, sectionAsIso should probably be offloaded to a display renderer, but it's such an interesting problem, I'm sorely tempted to implement it.

Location does work better than point, thanks. Also, the X/Y/Z variables will be replaced with Point - but I was thinking it would be good to overload the functions so people can toss X/Y/Z coordinates at them if they decide to. Is this a good idea, or bad?

The first thing I'm going to write on this will be the classic game of [link|http://www.classicempire.com/help.html|Empire] - two terrain types, eight military units (IIRC), and no tech tree. Should be simple enough, right? :P

I appreciate the feedback! Thanks!
They say a city in the desert lies/ The vanity of an ancient king/ But the city lies in broken pieces/ Where the wind howls and the vultures sing/ These are the works of man/ This is the sum of our ambition...
New My 2nd favorite song, Thane. Knew you were cool... :)

Many fears are born of stupidity and ignorance -
Which you should be feeding with rumour and generalisation.
BOfH, 2002 "Episode" 10
New My .sig? Yup, great song.
They say a city in the desert lies/ The vanity of an ancient king/ But the city lies in broken pieces/ Where the wind howls and the vultures sing/ These are the works of man/ This is the sum of our ambition...
New Here's one I forgot to mention
I actually jotted this down, but must have lost it in the editting process.

The function ChangeAttribute returns TRUE on success, and throws an exception if the attribute doesn't exist, or if it can't take the new value (for some reason).

Is there any time it could possibly return false? It sounds like you couldn't decide between returning errors via a return flag, or via exceptions and munged the two approaches together. (Not an uncommon problem ... at least one version of the DOM spec had the same issue).
--
-- Jim Weirich jweirich@one.net [link|http://w3.one.net/~jweirich|http://w3.one.net/~jweirich]
---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
New Re: [Civlike] Anybody see any problems with this structure?
>>>>>>>>>>
1.3.1.1.4. Raises Move_Fail_Out_of_Points
1.3.1.1.5. Raises Move_Fail_Treaty
<<<<<<<<<<

I think those should not be in Map (or in Tile). Map can compute how many points a move takes (even that is doubitable), but I don't think it cares if unit has enough points to move. Also, map can keep track of which treaty applies to which tile, but unit should know which treaties affect it.
--

Less Is More. In my book, About Face, I introduce over 50 powerful design axioms. This is one of them.

--Alan Cooper. The Inmates Are Running the Asylum
New Good points. Thanks.
New OT: *Great* .sig! (new thread)
Created as new thread #102392 titled [link|/forums/render/content/show?contentid=102392|OT: *Great* .sig!]


   [link|mailto:MyUserId@MyISP.CountryCode|Christian R. Conrad]
(I live in Finland, and my e-mail in-box is at the Saunalahti company.)
Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link|http://z.iwethey.org/forums/render/content/show?contentid=71575|Ashton Brown]
New Re: [Civlike] Anybody see any problems with this structure?
I would think that moving is a function of units, not the map itself. Heck, pathfinding is a sufficently messy problem to warrent it's own class, which would take a map, two locations and a unit. That way you could easily have multiple path finders for different types of movements and units.

LineOfSight could be treated as a specific pathfinding object then. If your going to have some form of fog of war, then you might want to make visibility a map property also, and keep that updated as units are moved. That gets rather mess though if you want to keep seperate maps for different players.

You seem to lack a function to return the value of the attribute. QueryAttribute only tells you if it exists, not what the value is.

Jay

Jay

New It may need it's own class...
but it can be a function of the map. (It's not that hard)

Basically, you use Dijkstra's (or Floyd's) algorithm to find the shortest path - with movement modifiers representing the resistance.

But I'd probably put it in it's own class - only because you want to pass into it the movement types available to the unit so that it can compute shortest possible distance regardless of the type of the unit.
Expand Edited by Simon_Jester May 17, 2003, 11:38:05 AM EDT
Expand Edited by Simon_Jester May 17, 2003, 11:39:54 AM EDT
     [Civlike] Anybody see any problems with this structure? - (inthane-chan) - (12)
         Re: [Civlike] Anybody see any problems with this structure? - (JimWeirich) - (6)
             Agreement - - (Simon_Jester) - (1)
                 That's why City derives from Placeable. - (inthane-chan)
             Thanks. - (inthane-chan) - (2)
                 My 2nd favorite song, Thane. Knew you were cool... :) -NT - (tseliot) - (1)
                     My .sig? Yup, great song. -NT - (inthane-chan)
             Here's one I forgot to mention - (JimWeirich)
         Re: [Civlike] Anybody see any problems with this structure? - (Arkadiy) - (2)
             Good points. Thanks. -NT - (inthane-chan)
             OT: *Great* .sig! (new thread) - (CRConrad)
         Re: [Civlike] Anybody see any problems with this structure? - (JayMehaffey) - (1)
             It may need it's own class... - (Simon_Jester)

Before such superhuman attainments of sustained triviality one stands in something like awe.
138 ms