It is currently Sun Dec 17, 2017 1:41 pm

All times are UTC + 9:30 hours




Post new topic Reply to topic  [ 23 posts ] 
Author Message
 Post subject: Feature list of customwars base engine
PostPosted: Sun Dec 21, 2008 8:51 pm 
Offline
User avatar

Joined: Tue Oct 28, 2008 8:51 am
Posts: 121
Okay I'll start with what I expect the base engine to provide in functional terms:

Army: Unit
  • can fire, destroy and be destroyed
  • image
  • name
  • health of which is deducted upon being fired on by other units
  • has movement restricted by a certain number of tiles
  • has a value of damage by which it can affect other units

Location: Terrain
  • image
  • has a movement value that is deduced from the players total distance they are able to travel within one turn

Location: Building
  • image
  • name
  • provides a modifier of cover on top of a user's base health

Player: Officer
  • image
  • name
  • description


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Tue Dec 23, 2008 5:04 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Image


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Tue Dec 23, 2008 5:19 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Army: Unit
  • has a value of damage by which it can affect other units
I think attack/defense values should not be part of units, instead they can be in a Fight class which is given all kind of intel(terrain defense, terrain height, co) from the outside and then calcs a result.


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Tue Dec 23, 2008 5:56 am 
Offline
User avatar

Joined: Tue Oct 28, 2008 8:51 am
Posts: 121
Thats a bit of a mean class diagram. I'll post up my ideas soon but I think this is a bit linear and is going to need a lot of going over :).


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Tue Dec 23, 2008 11:32 pm 
Offline
User avatar

Joined: Tue Oct 28, 2008 8:51 am
Posts: 121
I quickly sketched some ideas as a mind map last night. I'm not ready to decide on classes yet but I'm sure this will indicate some. For the ui stuff there would be MVC stuff in there as well.


Attachments:
mindMap.jpg
mindMap.jpg [ 141.52 KiB | Viewed 7110 times ]
Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Tue Dec 23, 2008 11:51 pm 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Not familiar with mind maps so i'll try to interpret it.

Let's stick to the model first, gui is complicated stuff and should be discussed in it's own post. We could even use just a console to test stuff out.
I'll focus on the model only I disagree with your drawing on these points:
A Tile is a Location because it has a col row agreed
a plain is a Location because it has a col row? really a plain is a terrain
dessert, mountain, forest, sea are all terrains they can be located on a Location.

building is a Location because it has a col,row ?
This would mean that the map needs a reference to all units/property/terrains as separate data arrays
adding another type is hard because you need to add another array change the map...

I would propose to put units/properties/terrain on a tile. and the map then keeps a reference to each tile on each col,row in an array as on the uml scheme and current cw code base.

Like map.getTile(0,0).getTerrain()
map.getTile(0,9).getPropery()
map.getTile(0,8).getUnit()
This would releave the map from the tile details, it has enough work handling tiles(Fog, looping through tiles,...)

Some more events
startTurn, EndTurn, Select

could you say what you disagree with in the uml in the post above?


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Wed Dec 24, 2008 1:38 am 
Offline
User avatar

Joined: Tue Oct 28, 2008 8:51 am
Posts: 121
A mind map is just to encourage thought into related entities and their implied connections. A line does not necessarily mean extends or implements, it merely implies some sort of loose relationship.

I don't disagree per say with the class diagram but I want to discourage deep development of uml before any code is developed because I'd rather you spent your time on developing unit tests and growing the code organically.

But just to pick holes I'll quickly mention:
  • Pathfinder - We can't be sure of how this will be managed as I would suspect it will be supplied by the framework and how we manage that dependency will be dictated by the framework choice.
  • Turns - A 'turn' is in itself part of a set(or unset) number of rotations, containing a number of players.
  • Tiles - tile map may contain many tiles but it would have a very loose relation to the unit that occupied its space upon the tile map. Like you say it would be a grid where you would specify grid.get(0,1) which would return you an object which implemented a class called something like tileOccupier{}.


Starting off as simple as possible with a model would be nice but alas it is unavoidable that we'll have to quickly slap a GUI on there. The most important thing for us to do is to first get an end to end deployment working. The reason for this is that all design choices will then consider the beginning, middle and end. Otherwise what you tend to find some disparate part of the GUI does not take into account a quick decision made on the model. Team members will then be free to work on different parts, regularly ( like every day) joining their efforts in the middle, so we always have a working solution. Otherwise people start to develop small seemingly unimportant changes in isolation which inevitable ripple down to big problems come integration time. So something quick and working end to end will be our first goal. A good end to end goal would be a blank screen with a menu that comes up when you click on any area.

I think we'll just end up agreeing on the same things but through long drawn out random paths unless we can get together in a screen sharing session with a whiteboard and talk openly about how we think it should evolve. But before we even do that, could you help in picking a framework by looking at the options. I know you like slick2D, I do too but it's only fair that we give them all a fighting chance and then we'll get something up and going, sure in the knowledge of the platform we are basing it on.


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Wed Dec 24, 2008 7:20 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
chom_chom wrote:
I don't disagree per say with the class diagram but I want to discourage deep development of uml before any code is developed because I'd rather you spent your time on developing unit tests and growing the code organically.
understood, but I like uml as it shows problems and leaves no room for writing wrong implementations.
But just to pick holes I'll quickly mention:
  • Pathfinder - We can't be sure of how this will be managed as I would suspect it will be supplied by the framework and how we manage that dependency will be dictated by the framework choice.
    mmm, I will try very hard to make the model independent of anything.
  • Turns - A 'turn' is in itself part of a set(or unset) number of rotations, containing a number of players.
    I disagree, for me a Turn is
    A current turn number
    A Turn limit number
    A function that converts a turn to a day(by doing turn/num player)
    A function to increase the turn by 1, throws exception when exceeding turn limit.
    it shouldn't know about players as in the object but it does need to know the amount of players in the game for the convertToDay function...


Last edited by stef569 on Sat Dec 27, 2008 8:41 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Fri Dec 26, 2008 10:00 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Default impl:
We'll want to create a DefaultTileOccupierImpl that would just implement the interface methods so that we can actually write test cases(without a link to a plugin) Defaultclassname would contain the default behaviour of such an interface.

can the DefaultTileOccupierImpl be extended in a plugin? so you get a lot of behaviour for free? Similar to the Swing AbstractAction.
simple data files can be created that shows that the model can be loaded from files.

Triggers:
Will we support triggers ie unit moves to tile, play a sound?
This is needed when we need to support custom scenarios

A Trigger is a if condition that is checked in each loop
It can be summarized by
Detect, broadcast, respond or
if condition(s), send to all, do action based on input

An example Trigger would be WithinTileSquareTrigger
if a tile is within the defined square then trigger is fired.

A TriggerManager would keep the conditions for a given action Source
This is still very vague, need to make it more concrete.

Possible Unit Interfaces:
Supplyable, Supplier
Attacker, Defender
Healer, Damageable
Nameable?, Ownable
Purchasable, TurnHandler
Capturer
source

Possible Tile Interfaces:
TileOccupier or Locatable, Location
TileMover, TileLocation
source

Others:
Fight
source
Aw impl

enum States(as in objectState)
I can think of these enum states that a Unit can be in, maybe they are applicable to other objects as well.
For example Property is always Idle
IDLE, // created
ACTIVE, // can be controlled
DYING, // after dying(a while) the state is set to destroyed
DESTROYED // can be removed from the game
Idle units might get drawn differently in the ui then active units

I would prefer the above over 4 booleans, because:
they really indicate the state a object is in
type safety, Use enum cst name instead of true,false
enum toString retuns the enum name which helps debugging.
less code setState, getState compared to 4 setters and 4 getters

does that cover a default aw game? what needs yet to be abstracted

Can a co be abstracted, does it have common methods?
co
activatePower, deactivatePower, activateSuperPower, deactivateSuperPower, style, ... euhm complicated!


Last edited by stef569 on Sun Dec 28, 2008 10:33 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Sun Dec 28, 2008 11:24 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Just found out that in cw a Property extends a Terrain. This seems a better approach, I updated the uml.

aw games only support following 'Army branches': I can't find a better name for them.
GROUND, AIR, NAVAL so I guess this can be hardcoded, this means that cities can only heal units that have 1 of these army branches and factories can only build units with 1 of these army branches.

but what about unit states, a unit has several states it can be in: Capturing, Submerged, Moving maybe, what else?
Capturing: unit is capturing property(can last over multiple turns)
Submerged: sub has gone under water(can last over multiple turns)
Moving: The unit is moving toward an end tile, Could be used to prevent the user to click on the unit or do other stuff while it's going to the destination. so this state is active when doing a move.(only within 1 turn)
Idle: none of the above, just standing there(can last over multiple turns)

Would it be possible that somebody comes up with non standard aw stuff like Sentry unit that would provide bonus on open land after 2 turns or something? that seems a reasonable mod... then there is a problem :p he(the modder) will assume unit.getUnitState() will return null/Idle when it's not in a state(ok), Capturing when it's capturing(ok) but when he does his sentry action the unitstate will be null/Idle again. :/

So I guess the actions a unit can perform should be stored externally. this allows to set the unitState ie
Code:
sentry action code....
final SENTRY = 3;
unit.setState(SENTRY)

in the gui, unit painting he adds another if statement

Code:
int unitState = unit.getUnitState()
if(unitState == SENTRY)
do sentry painting, maybe a special icon whateva.


I continue to post ideas, and try to solve 'problems' before we encounter them, if you see something and think wtf is that/ I know a better way, please say so(by explaining why/what how to make it better)

For example the above seems reasonably to me, but instead an event could be sent to the gui telling it should now paint sentry units instead of the if/else. Problem with that approach is that I like to change the model and expect the gui to change automagically. things can get out of sync when you sent sentry events to the gui but forget to update the unit, it's now not really in the sentry state

So the unit is painted as sentry, but the logic works with an idle unit oh dear!


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Sun Dec 28, 2008 8:09 pm 
Offline
User avatar

Joined: Tue May 08, 2007 6:19 am
Posts: 1363
stef569 wrote:
aw games only support following 'Army branches': I can't find a better name for them.
GROUND, AIR, NAVAL so I guess this can be hardcoded, this means that cities can only heal units that have 1 of these army branches and factories can only build units with 1 of these army branches.

This would make the engine incompatible with the old Custom Wars, which has hovercraft units that can be built both from bases and ports... and I could easily see someone wanting to extend the amount of different factory types, for example, to separate the production of infantry and vehicles, or even adding completely new branches such as "space forces" built from space ports that can cross special "space" tiles or whatever. You might want to allow some flexibility here.

I would suggest that each property has a list that describes which units they can produce, this is how it's basically done in CW, only hardcoded and not that easy to customise. Or at least have the branch represented by an integer so that there can be a virtually unlimited amount of different production facilities if need be.

stef569 wrote:
but what about unit states, a unit has several states it can be in: Capturing, Submerged, Moving maybe, what else?

DoR has a unit called rig that can build certain properties on certain tiles, which takes two turns with maximum HP and longer if the rig is damaged. I believe this uses part of the capturing code for infantry. Both seem to be actions that take one type of terrain tile and change it into something else (neutral property -> owned property for inf / empty terrain -> owned property for rig) and take up a certain amount of turns depending on the strength of the unit performing the action. Perhaps this could be genericised? We could have terraforming units that deploy mountains, engineers that set up trenches and fortifications etc. etc.


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Sun Dec 28, 2008 9:39 pm 
Offline
User avatar

Joined: Tue Oct 03, 2006 6:00 am
Posts: 320
Location: Scotland
Narts wrote:
stef569 wrote:
We could have terraforming units that deploy mountains


*insert obligatory Kanbei reference*[/spam]

I can't think of anything else, except what was mentioned above, although why the need for a DYING variable AND a DESTROYED variable?


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Sun Dec 28, 2008 10:06 pm 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Quote:
why the need for a DYING variable AND a DESTROYED variable?

Well it has todo with the gui, a unit would have a unit sprite in the gui, dying takes x ms...

for each tile
if has unit
if unit is dying add elapsed time to time
if unit is dying and explosion finished: set state to destroyed, reset time
if unit is destroyed remove unit sprite
get unit sprite for unit
unitSprite paint

paint
if unit is dying paint explosion
if unit is active paint active
if unit is idle paint darker unit

is explosion finished
time >= explosionTime

The unit is still in the model but the sprite has been removed from the list of sprites to paint.
when the current player ends his turn we will query each unit to see if it is destroyed and then: removing it from the player, stop capturing a property if it was doing that...
removing all references to it, so it can be gc.

Why not just let the gui change the model, because it's not allowed to do that :P only actions can change the model the gui just queries and paints=>CMV

Hmm if the unit would stay on the tile other units will still bump on it...
A controller could query the unit state and when it is changed to destroyed remove all references to it.


Last edited by stef569 on Fri Feb 06, 2009 4:39 am, edited 2 times in total.

Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Mon Dec 29, 2008 5:26 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Quote:
DoR has a unit called rig that can build certain properties on certain tiles, which takes two turns with maximum HP and longer if the rig is damaged. I believe this uses part of the capturing code for infantry. Both seem to be actions that take one type of terrain tile and change it into something else
neutral property -> owned property for inf
empty terrain -> owned property for rig

and take up a certain amount of turns depending on the strength of the unit performing the action. Perhaps this could be generalized? We could have terraforming units that deploy mountains, engineers that set up trenches and fortifications etc. etc.

ok i'm going to write that in pseudo code:

Engineer Unit -> can build some Properties on some terrains, the engenieer needs to capture the Property before it is placed on the tile
Engineer build AirPort on plain action
Code:
unit build airport property
can this airport be build on plains?
create Airport in memory (not on a Tile)
start capping the AirPort each turn
if Airport is captured place it on the unit tile

You are right, it does uses the capturing code for units but you can't capture a Terrain, only a Property.

I think this is an extension of a unit and should be in a plugin, not all extensions want the buildProperty behavior, it's not essential, where capturing Properties is, I have to write down the essential stuff...
subclassing unit and provide a buildProperty(Property prop) method like so maybe:
Code:
class pluginNameUnit extends Unit {
Units by default can't handle Properties, Engineer can...
Map<Integer, List<Terrain>> properties
private Property constructingProperty;

buildProperty(Property prop, Terrain terrain) {
  if(constructingProperty == null) {
   if(properties.get(prop.getID())).getValue().contains(terrain)) {
     constructingProperty = prop;
   }
  }
}

startTurn(Player p) {
  super.startTurn(p);
  constructingProperty.capture(this);

  if(constructingProperty.isCaptured() {
    location.setTerrain(constructingProperty);
  }
}
}


Quote:
I would suggest that each property has a list that describes which units they can produce, this is how it's basically done in CW, only hardcoded and not that easy to customise.

I want to go even further there should be a list of armybranch IDs that can
be healed, be created, capture the property

Quote:
Or at least have the branch represented by an integer so that there can be a virtually unlimited amount of different production facilities if need be.
yea good point, that seems to be the most flexible way. I proposed to hardcode those Branches because I interpreted 'aw like games' as in different aw versions, spaceShips are not aw like and are completely new. but ok if this is what is needed then we'll do it that way :)

units can be build by a UnitFactory (builds 0==GroundTroops Branch)
vehicles can be build by a VehicleFactory (builds 1== Vehicles Branch)
spaceShips can be build by a SpacePort (builds 2==SpaceForces Branch)
all of the above in a SuperFactory (builds=0,1,2)
all ground troops can be build by a Factory(builds = 0,1)


Last edited by stef569 on Wed Dec 31, 2008 10:47 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Tue Dec 30, 2008 2:58 am 
Offline
User avatar

Joined: Tue May 08, 2007 6:19 am
Posts: 1363
stef569 wrote:
Code:
unit build airport property
can this airport be build on plains?
create Airport in memory (not on a Tile)
start capping the AirPort each turn
if Airport is captured place it on the unit tile

You are right, it does uses the capturing code for units but you can't capture a Terrain, only a Property.


I think something like this would be closer to how AW works:
Code:
if unit is on terrain1 show action
if action is selected decrease capture points
have capture points reached 0? no-> end move
yes-> replace terrain1 with terrain2


You don't need to check if terrain2 can be built on terrain1 because (at least in the AW games) the same terrain is always assumed to be transformed into a certain terrain depending on the type and owner of the unit performing the transformation. Blue infantry always turns neutral and red cities to blue cities, rig always turns plains to temp airports and shoals to temp ports and so on. Of course if you want more flexibility you can do it your way but such complexity is not absolutely necessary. However this way would be simpler because you wouldn't need an extra gui check to see what the player wants to build since it's determined by the context.

Do we need to make a distinction between properties and non-properties here? Since capture points are always reset when the capturing unit moves it seems to me they could just as well belong to the unit class rather than the terrain. Or we could just give them to every type of terrain if you think that's more logical. It would be good if this code could be used for units which build non-property tiles, such as roads, bridges,forests and what-not.


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Tue Dec 30, 2008 4:23 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Quote:
Blue infantry always turns neutral and red cities to blue cities

yes, this is normal behavior if each Unit and each Property has a Player that owns it then we can say:
property.setOwner(unit.getOwner()) each player has a color and the gui will draw the new color.

Quote:
rig always turns plains to temp airports and shoals to temp ports and so on.

this is not normal behavior additional data is needed, a plugin needs to provide this behavior
what unit can build what property on what terrain, no need to look that up in the gui a List of terrains that can be transformed can be put in the Unit plugin.

Quote:
An extra gui check to see what the player wants to build since it's determined by the context.

The model that we talk about doesn't depend/knows about gui/network...
it can be changed by user actions, as in a click on a capture btn.
Maybe I misunderstood what you said.

Quote:
Do we need to make a distinction between properties and non-properties here? ... capture points could just as well belong to the unit class rather than the terrain. Or we could just give them to every type of terrain if you think that's more logical.

Well data and behavior on that data should be in the same object. if an object can be capped then the max and the current capcount value should be in that object. if terrains can be capped what would plains.capture do? terrains can't be owned, they are Immutable, they have movementData, defense. if units would have a capCount then the object that performs the capture action needs to retrieve that value and it won't be used anywhere else further unit doesn't use it. So capCount is not a good member of unit.

Quote:
It would be good if this code capture() could be used for units which build non-property tiles, such as roads, bridges,forests and what-not.

I don't know what you mean, units that build terrains?

Conclusion:
Property is a Terrain that can be captured.
Transforming Terrain(replacing it really) will not be supported by cw2 engine(cw1== old cw, cw2 == new cw see glossary)


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Tue Dec 30, 2008 4:51 am 
Offline
User avatar

Joined: Tue May 08, 2007 6:19 am
Posts: 1363
What I meant is that to support the AW games you only need one command to represent all the possible combinations of "unit modifies a tile", because each unit / tile combination can only result in one type of end result.

Infantry moves on a neutral property -> Context menu reads "Capture" as the command and choosing this results in the action that changes the neutral prop into an owned prop.
Rig moves onto a shoal -> Context menu reads "Temp. Port" -> Builds temporary port
Rig moves onto a plain -> Context menu reads "Temp. Airport" -> Builds temporary airport

It's that simple in DoR. Of course, if you want to make it more complex you're welcome.

stef569 wrote:
Quote:
It would be good if this code capture() could be used for units which build non-property tiles, such as roads, bridges,forests and what-not.

I don't know what you mean, units that build terrains?

Yes, I could easily see someone wanting this.

Like dunno, if someone wants to remake Dune 2 as a TBS they might want a Spice Harvester that turns a Spice terrain into Desert while returning funds. :D

Or, buildable rails for a SFW style train gun...

There are endless possibilities!

stef569 wrote:
Quote:
Blue infantry always turns neutral and red cities to blue cities

Well data and behavior on that data should be in the same object. if an object can be capped then the max and the current capcount value should be in that object. if terrains can be capped what would plains.capture do? terrains can't be owned, they are Immutable, they have movementData, defense.

You are thinking inside of a box here. The idea here is that capture points don't represent capture only but the time required for any transformation of a terrain as performed by a unit. Plains already are mutable in AW thanks to rigs and temp. airports.


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Tue Dec 30, 2008 8:26 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
I understand what you mean but I don't know a solution to merge transforming and capturing.

Property should be captured by a unit
each turn unit hp is added to capCount when max it's captured
property.setOwner(unit.getOwner))

terrains should be transformed to another terrain by a unit
each turn unit hp is added to transformCount when max it should transform
tile.setTerrain(newTerrain)

transforming is really just replacing one terrain for another. Terrains are immutable so you can't change them you have to replace them. String is immutable to.

Common behavior true.
For example the code to detect if a unit can capture a Property in Property could look like this:
Code:
 a List of terrainID that the unit can capture

  /**
   * Cannot capture cities that are already owned by the Unit and
   * the unit ArmyBranch should be supported
   */
  public boolean canBeCapturedBy(Unit capturer) {
    return owner != capturer.getOwner() && canBeCapturedBy(capturer.getArmyBranch());
  }

  private boolean canBeCapturedBy(int branch) {
    return captures.contains(branch);
  }


canTransform as I see it as a separate method in Terrain could look like this
Code:
a list of terraindID that the terrain can tranform

public boolean canTransformTo(Terrain newTerrain) {
  return transformTerrains.contains(newTerrain);
}


and in Unit
Code:
public boolean isTransformer() {
 return tranformer;
}


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Wed Dec 31, 2008 2:23 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Quote:
What I meant is that to support the AW games you only need one command to represent all the possible combinations of "unit modifies a tile", because each unit / tile combination can only result in one type of end result.


Aha! You are totally right

There is transform behavior and capture behavior that only fires on a special set of conditions. Seems the command pattern to me.

We add command(s) to a unit that allows it to perform(execute) a command when the conditions are met.
Number of Commands a unit can has is unlimited.
The logic for a command to execute is in one place.

But the gui needs a list of commands it can execute from a unit
Code:
unit.getExecutableCommands

Each command should have a description shown in the gui.
Wait command should be in each unit


Last edited by stef569 on Wed Dec 31, 2008 9:50 am, edited 4 times in total.

Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Wed Dec 31, 2008 2:44 am 
Offline
User avatar

Joined: Tue May 08, 2007 6:19 am
Posts: 1363
Yeah that's right. I don't care how you actually implement it, but I'll be happy if the functionality is there. If you can do it, grand, but it shouldn't be a top priority or anything.


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Wed Dec 31, 2008 9:17 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
ok, we need to find special behaviors

Properties are well defined:
heals The ArmyBranches this City can heal
captureBy The ArmyBranches this City can be captured by
builds The ArmyBranch this City can build
They are fogged until a unit enemy unit is directly adjacent to it.

But units are special:
Stealth can hide itself (not visible until a enemy unit is directly adjacent)
Hover craft has special move abilities -> HoverMovementBehavior
subs can dive -> Unit command(unit.setDived(true), "Dive")
we can create a class for each movement ability like this:
unit.setMovementType(new NormalMovementBehavior())
or
unit.setMovementType(new HoverMovementBehavior())

I think a Rules class is needed it validates changes in the model
canAttack, canDive, canFogTile, etc


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Fri Feb 06, 2009 4:42 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Entity is the model
EntitySprite is the view
EntityController is the controller
Image


Top
 Profile  
 
 Post subject: Re: Feature list of customwars base engine
PostPosted: Fri Feb 06, 2009 10:27 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Gui classes, comments are welcome
Image


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ] 

All times are UTC + 9:30 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Blue Moon by Trent © 2007
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group