Jump to content
XCOMUFO & Xenocide

Project: Fishbowl


dteviot

Recommended Posts

A thought occurs to me.

Because the AI on the battlescape is likely to be one of the biggest challenges in the Battlescape, I wonder if it would be worthwhile creating a simple testbed for trying out AI.

The idea is we have a stripped down environment that has the major features of the battlescape.

That is, a cubical grid say 128 x 128 x 16. Each cube has a left, back and bottom face that may or may not be passable.

We also have ramp, stair and elevator cubes that allow going up and down levels. And "impassible" cubes.

We then have a set of reasonably simple bots. They move, have health, sight and a gun.

Which we assemble into teams, and we run different teams against each other to test out AI.

Link to comment
Share on other sites

A thought occurs to me.

Because the AI on the battlescape is likely to be one of the biggest challenges in the Battlescape, I wonder if it would be worthwhile creating a simple testbed for trying out AI.

The idea is we have a stripped down environment that has the major features of the battlescape.

That is, a cubical grid say 128 x 128 x 16. Each cube has a left, back and bottom face that may or may not be passable.

We also have ramp, stair and elevator cubes that allow going up and down levels. And "impassible" cubes.

We then have a set of reasonably simple bots. They move, have health, sight and a gun.

Which we assemble into teams, and we run different teams against each other to test out AI.

 

 

I am way into this. It would be great if we could create the AI as a plugin module. That way we could easily swap in new AI code and anyone who knows .Net could create a dll.

 

-Dustin

Link to comment
Share on other sites

Well, I think the first thing to do is document the environment.

What sort of "cubes" do we have, and what are their properties.

Some of the things we see in X-Com are:

  • Gravity lifts
  • Stairs
  • Water patches. (airborne units can cross, walking units can't)
  • Ramps. (are ramps the same thing as stairs?)
  • Windows in walls
  • Doors
  • Obstacles in cube, that prevent crossing. Of differing height. (for visibility/cover)

What have I missed?

I also found these:

http://www.ufopaedia.org/index.php?title=MCD

http://www.xcomufo.com/forums/index.php?showtopic=242024650

 

[Edit by Zombie: Fixed list].

Edited by Zombie
Link to comment
Share on other sites

Additional.

 

I've said this before, but I'll say it again.

It might be worthwhile seeing if we could use the UFO2000 maps to generate the terrain.

This would give us 3 main advantanges.

1. There are already pre-built maps for our use.

2. Map builder tools already exist.

3. Environmental rules have already been specified.

 

However, there are a few questions to ask.

1. How much effort would it be to to build a parser for their map files?

2. Are their maps even suitable to put in a 3D engine? How do we handle the case that walls only have one side in UFO2000

3. Based on the UFO2000 team's experience, could they recommend a better design/architecture for the terrain? (Hmm. I'll PM Serge on this.)

 

 

Also, what sort of tactics would the alien forces emply?

e.g.

1. Scouts and Snipers

2. 2 x 2 advance.

3. Mine chokepoints

4. The always popular "mind control soldiers, get them to arm and drop any large explosives."

Link to comment
Share on other sites

A few tactics off the top of my head:

 

Use of smoke grenades to cover advance (I know Aliens don't start with smoke grenades, but perhaps they do research of their own)

 

Death from above- just flying up really high and lobbing grenades/shooting/mind controlling.

 

Shoot though walls when in a hurry. For whatever reason, an enemy unit might be in a rush (to sight or attack an X-Com unit, or to run away). It'd be neat if they shoot through walls if its faster and stealth is not an issue. Don't know how hard this is to implement, though.

 

Oh, and duck at end of turn or before firing to take advantage of the accuracy bonus. :P

Link to comment
Share on other sites

I have been thinking about how I would program a battlescape like this for years. I am crap with graphics, so that's not the part I have considered carefully.

 

However, there are a few questions to ask.

1. How much effort would it be to to build a parser for their map files?

Probably not hard at all. Where are some samples and thier docs describing them?

 

2. Are their maps even suitable to put in a 3D engine? How do we handle the case that walls only have one side in UFO2000

Billboards? Seriously, I think we can adapt them to 3d, just by giving them a width.

 

Also, what sort of tactics would the alien forces emply?

e.g.

1. Scouts and Snipers

2. 2 x 2 advance.

3. Mine chokepoints

4. The always popular "mind control soldiers, get them to arm and drop any large explosives."

 

I REALLY think we shouldn't bother much with the tactics at this point. We should just get a basically functional fishbowl and the aliens should wander around and shoot anything that moves. We should design the tactics engine to be completely seperate with very loose coupling.

 

That way we can develop the AI very seperately from the rest of the battlescape. In my vision we have 4 main layers.

  1. The battlescape engine. This keeps track of all the objects and makes sure they all follow the rules.
  2. The graphics engine which interprets the current state of the battlescape as a 3D environment for human enjoyment.
  3. The tactics engine. On a player/alien turn the tactics engine is invoked by the battlescape engine to "ask" what that untis will do. The tactics engine will have access to all the "senses" of that particular mobile. (what it's carrying, who it can see, where it is on the map, X-Corps that can be seen by any alien, etc.) It will then be able to use the Action Points of the team until it runs out, or gives up control. We may want to to be able to handle reaction fire as well. That way the player could say "only reaction fire with non-missile weapons" or maybe even have limited control of the soldier during reaction fire.
  4. The UI which is invoked whenever the human player is in control. It works just like the tactics engine as far as the battlescape is concerned. In fact it could be derived from the same base class and in early alphas the computer should run both teams and/or the player can run them both.

This allows us to make a lot of progress on the fishbowl without having any AI at all. Ideally I would like to have the tactics engines be external DLLs that the battlescape engine can load dynamically. This gives us the ability to plug in different AI modules for various reasons. One for testing, one for Different difficutly levels, UI based engines and maybe even a tactics engine for each alien race.

 

Whatever we do, I really am passionate about keeping the AI part of the code as distinct from the rest of the code as possible. It's going to be a hard bit of code do deal with already, and I want to be able to have a lot of parrallel efforts going into it that won't gate on the battlescape issues. In a scrum model, the battlescape and graphics engine would be sprints 1 and 2. And AI would be a later sprint.

 

In order to make that work we need to define the interfaces that the battlescape and tactics engines must adhere too in decent detail before we start.

 

-D

Link to comment
Share on other sites

Sounds right approach to me... 0 or less than decent (even 3D floorplant with invisible walls only graphics if required) could give more than necesary to experiment on the battlescape module architecture.

 

A couple of questions:

 

Are we going to keep with the squares or prefer freecell roaming?

 

-Squares-

Pro: Far easier to debug and code.

Cons: Limit the type of surfaces, landscapes and models that will be put in there.

 

-Free-roaming-

Pro: Your map isnt discretized in big chunks but in way smaller (thing of it as a Squares world with 1024x1024 or more cells than 60x60 as XCOM).

Pro: You can put whatever geometry in models that you want.

Pro: You are not restricted to levels.

Cons: More complex because of a player is not aligned with a world cell

 

XCOM had a random walk, and shoot what you find in there... and even it worked great at the time... Maybe "right" AI is better after we have a grasp of what is going on?

 

Maybe create a battlescape with planes where you can move and the aliens too? Instead of going fancy first, you just create a simple world. What do you think?

 

Greetings

Red Knight

Link to comment
Share on other sites

I have been thinking about how I would program a battlescape like this for years. I am crap with graphics, so that's not the part I have considered carefully.

 

However, there are a few questions to ask.

1. How much effort would it be to to build a parser for their map files?

Probably not hard at all. Where are some samples and thier docs describing them?

Not sure. I know I came across detailed docs on their wiki.

The second link I posted has some information, and I think it leads to more.

 

2. Are their maps even suitable to put in a 3D engine? How do we handle the case that walls only have one side in UFO2000

Billboards? Seriously, I think we can adapt them to 3d, just by giving them a width.

Actually, I'm referring to the fact that in UFO2000, the walls only show one side. There's no texture for the hidden side of the wall.

Of course, initially in the fishbowl, all walls (and floors and ceilings) can have the same texture.

 

Also, what sort of tactics would the alien forces emply?

e.g.

1. Scouts and Snipers

2. 2 x 2 advance.

3. Mine chokepoints

4. The always popular "mind control soldiers, get them to arm and drop any large explosives."

 

I REALLY think we shouldn't bother much with the tactics at this point. We should just get a basically functional fishbowl and the aliens should wander around and shoot anything that moves. We should design the tactics engine to be completely seperate with very loose coupling.

 

That way we can develop the AI very seperately from the rest of the battlescape. In my vision we have 4 main layers.

  1. The battlescape engine. This keeps track of all the objects and makes sure they all follow the rules.
  2. The graphics engine which interprets the current state of the battlescape as a 3D environment for human enjoyment.
  3. The tactics engine. On a player/alien turn the tactics engine is invoked by the battlescape engine to "ask" what that untis will do. The tactics engine will have access to all the "senses" of that particular mobile. (what it's carrying, who it can see, where it is on the map, X-Corps that can be seen by any alien, etc.) It will then be able to use the Action Points of the team until it runs out, or gives up control. We may want to to be able to handle reaction fire as well. That way the player could say "only reaction fire with non-missile weapons" or maybe even have limited control of the soldier during reaction fire.
  4. The UI which is invoked whenever the human player is in control. It works just like the tactics engine as far as the battlescape is concerned. In fact it could be derived from the same base class and in early alphas the computer should run both teams and/or the player can run them both.

This allows us to make a lot of progress on the fishbowl without having any AI at all. Ideally I would like to have the tactics engines be external DLLs that the battlescape engine can load dynamically. This gives us the ability to plug in different AI modules for various reasons. One for testing, one for Different difficutly levels, UI based engines and maybe even a tactics engine for each alien race.

 

Whatever we do, I really am passionate about keeping the AI part of the code as distinct from the rest of the code as possible. It's going to be a hard bit of code do deal with already, and I want to be able to have a lot of parrallel efforts going into it that won't gate on the battlescape issues. In a scrum model, the battlescape and graphics engine would be sprints 1 and 2. And AI would be a later sprint.

 

In order to make that work we need to define the interfaces that the battlescape and tactics engines must adhere too in decent detail before we start.

 

-D

Actually, the whole fishbowl is jumping the gun (sort of), as I'm not starting Battlescape construction until after the Geoscape. But it's never to early to start thinking about things and collecting information. And, of course, there's nothing to stop other people working on the Battlescape.

Link to comment
Share on other sites

My opinion is use squares. Far easier to debug and code.

Then upgrade to freecell roaming, if we find the need.

 

Sounds right approach to me... 0 or less than decent (even 3D floorplant with invisible walls only graphics if required) could give more than necesary to experiment on the battlescape module architecture.

 

A couple of questions:

 

Are we going to keep with the squares or prefer freecell roaming?

 

-Squares-

Pro: Far easier to debug and code.

Cons: Limit the type of surfaces, landscapes and models that will be put in there.

 

-Free-roaming-

Pro: Your map isnt discretized in big chunks but in way smaller (thing of it as a Squares world with 1024x1024 or more cells than 60x60 as XCOM).

Pro: You can put whatever geometry in models that you want.

Pro: You are not restricted to levels.

Cons: More complex because of a player is not aligned with a world cell

 

XCOM had a random walk, and shoot what you find in there... and even it worked great at the time... Maybe "right" AI is better after we have a grasp of what is going on?

 

Maybe create a battlescape with planes where you can move and the aliens too? Instead of going fancy first, you just create a simple world. What do you think?

 

Greetings

Red Knight

Link to comment
Share on other sites

Anything concerning map and map generation should probably be directed to Hobbes. He knows more about this than anyone I know. I do have some minor experience in this area, but my forte is spawn points (starting locations of aliens/civilians). :P

 

It may be easy to parse the UFO2000 maps over to 3-D for Xenocide, but is this the right path? Certainly I think we can come up with some original maps ourselves. Besides, I think the color palette is limited for those map files whereas we will have no such limitations. For fishbowl testing, ok, it may suffice. But we shouldn't rely on it to carry us through. :wink1:

 

- Zombie

Edited by Zombie
Link to comment
Share on other sites

Anything concerning map and map generation should probably be directed to Hobbes. He knows more about this than anyone I know. I do have some minor experience in this area, but my forte is spawn points (starting locations of aliens/civilians). :P

OK, I've PM'ed Hobbes

Link to comment
Share on other sites

Hobbes' response:

Hi,

I can't reply on that forum so here it goes: my knowledge of coding is very, very limited (I had to look up for half the expressions on this thread since they sounded chinese to me). My skills regarding map design come from using X-Com and UFO2000's editors, reading whatever available documentation there is and by trial and error. Thus, this mean I also don't know anything about 3D game engines, free cell roaming, etc.

I take it that by "squares" you mean the X-COM method of building a Battlescape from different map blocks, either square or rectangular, and that the question is if it is advisable to convert existing X-COM/UFO2000 to start working on your future Battlescape, in order to have an environment to start developing the AI. I don't know the internal functioning of a 3D game engine, but for an isometric view I'd say that one of the more hard parts will be to design the graphics and that should weight a lot on the decision. Zombie is half correct in saying that the palette is limited: for the original games it is, but in UFO2000 there are no such limitations on colors: the main limitation on on the detail, since each map cell has only 40x40x12 pixels.

Hmm, I don't know what else to say....it's better if you ask me a particular question rather than making generalizations which might be wrong.

Link to comment
Share on other sites

1. Where is documentation on structure of map?

2. What are main issues with structure of terrain. What are good and bad points, and how would you do it better?

 

1. You have pretty much listed the documentation available, namely the Custom Maps for UFO2000 page, and I would recommend the Terrain page of the UFOPaedia. You can also find a lot of information regarding the terrain files used by X-COM there.

 

2. Here it goes:

* The first thing I'd definitely recommend with terrains is designing a good editor available for creating maps, with copy/paste/delete/fill functions and an easy GUI that uses game images to show right away how the maps look like.

* The more textures available the better the game looks, but designing textures and objects takes a lot of time (for me, at least). On X-COM:UFO the limit for game tiles (ground, walls, objects) is 253 due to file restrictions, on UFO2000 this limit has just been removed but I seriously doubt that there will be terrains featuring 1000+ or 500+ tiles because the payoff for the work involved wouldn't be worth it.

* The simpler the maps, the better. To me this is a rule of thumb, learned after creating a lot of very complex maps. A very large map usually takes too long to play and 2 hour games can be fun, but after a while they take forever.

* Terrain should interact with the player's actions (punching holes in walls, exploding features, etc.)

* One thing that might be interesting to develop would be for the battlescape generator to add particular items to a map feature. For instance, imagine that a battlescape is made of houses. Each house would be constructed according to the model present on the data files, but the code would be programmed for variations on the walls, etc. A wall could have a stain on it, or there could be a portrait there. This way the houses would have the same general aspect but they'd be unique.

 

Well this is what I remembered on a short notice. Is it what you wanted?

Link to comment
Share on other sites

  • 2 weeks later...
  • 1 month later...

OK, to build the battlescape there are 6 (at least) related tasks.

  • Simulate the environment (or "terrain"
  • Simulate combatants.
  • Simulate equipment
  • Control soldiers
  • AI
  • Render battlescape to 3D

       
      And first step is going to be to start nailing down requirements for each of these tasks.
       
      As a small example, each "cell" that makes up the environment may have properties like
      • flammability. (Ease of ignition, duration of burn? intensity?
      • destructibility. Armor, heath?
      • cost to travel across.
      • transparency. (Blocking view? height?)
      • ability to go up in height (stairs, elevators)
      • other?

      I'm hoping we can steal as much as possible of this from UFO 2000.

Link to comment
Share on other sites

OK, to build the battlescape there are 6 (at least) related tasks.
  • Simulate the environment (or "terrain"
  • Simulate combatants.
  • Simulate equipment
  • Control soldiers
  • AI
  • Render battlescape to 3D

       
      And first step is going to be to start nailing down requirements for each of these tasks.
       
      As a small example, each "cell" that makes up the environment may have properties like
      • flammability. (Ease of ignition, duration of burn? intensity?
      • destructibility. Armor, heath?
      • cost to travel across.
      • transparency. (Blocking view? height?)
      • ability to go up in height (stairs, elevators)
      • other?

      I'm hoping we can steal as much as possible of this from UFO 2000.

Work in progress attached.

 

This project is pretty interesting to me. I actually started some code from scratch.

 

My idea is to have a 3 tier system.

 

1. The graphics engine. (I am crap at this, so I am leaving it for someone else)

2. A parser that looks into the battlescape object and creates the 3d objects to hand to the engine in a way it understands.

3. a battlescape object model. (~50% complete)

  • Provides a "one object interface" for both the graphics engine and they AI/UI. (I.E. the UI wouldn't handle "weapon" or "unit" objects directly).
  • Handles all the game "rules"
  • Contains all the interfaces for the AI and UI to command the units.
  • Contains interfaces that model the battlescape that provide at least two "views" of the game. One that's a square by square map of what physical objects are contained in order to render the scene and one veiw that is unit centric to allow controlling the combatants.
  • Completely abstracts the game part from the graphics part to allow change in one not to realy directly on changes in the other.
  • Doesn't directly reference graphics resources, just maps everything to internal enums to keep code self documenting and ensure if it builds it will run.
  • Will need to load things like weapons and maps though.
  • Uses a callback system to allow things like reaction fire (internally) and animations (external).

I have probably duplicated a lot of code from the geoscape you meant to re-use.

 

The graphics engine I "borrowed" from a tutorial and it's not related to the battlescape at this time. My hope was to make it barely functional for testing, but I am putting that part off.

I am happy with my interface design. I am not completly happy with some of the details, but I wanted to get something working then figure out where it could be better. I am sort of cloning XCOM1's model to a certain extent. It would be nice to be able to model structures and objects more than one map cell at a time, but that's the system I sort of started with. I planned on adding some code to the "battlescape" interface to handle creating that stuff as a unit and maybe do things like detect walls that should collapse and so on.

 

I have probably taken this in a different direction that you might have planned. I am not sure I am done enough for it to be ready for other people to mess with, but I am also not sure I will get it done enough in the near future to be "on time" for what you need.

 

One disadvantage to my approach is that you can't use the grahics engine for things like line of site and hit detection. You also have to rebuild the scene everytime something changes. It could be more performant, but I really don't think that's going to be a big deal in a turn based game. The clean interface design more than makes up for some possible bottlenecks IMHO.

 

In my mind the code I have here would end up in a "battlescape.dll" and the front end would go in the bin.

 

I can probably have it fleshed out enough to run very basic battles in about a week, if you want to go this route.

 

 

-D

ProjectFishBowl.zip

Edited by SaintD
Link to comment
Share on other sites

I've had a look at your fishbowl project. And it has potential.

I'd make a few comments.

  • I think some more up front design is required.
  • Consider reducing the number of classes e.g. Instead of having Mobile, Tank and Biped, start with Mobile. Likewise (and this is something I'm planning on doing to the existing item structure) instead of Grenade, Equipment, Weapon and WeaponMagazine have just an Equipment class, where each Equipment can have a set of actions.

Link to comment
Share on other sites

I have been working recently on a framework for a client where I found that an specific concept borrowed from C# 3.0 (that comes in .Net 3.5) named Lambda expressions that can be implemented with delegates in C# 2.0 could be pretty useful for the AI and Commands. Basically it involves using the lexical closure to enclose an execution context (like a command with the extra feature that you have access to the local members) and that gets defered until you really need to execute that code.

 

More information can be found here: http://diditwith.net/PermaLink,guid,a1a764...f4e300ea0f.aspx and in a lot of places about it in that blog.

 

class Program
{
   private MyDelegate<int, int> Delegate1;
   private MyDelegate<int, int> Delegate2;
           
   public Program()
   {
       int a = 0;

       Delegate1 = delegate(int arg)
       {
           a++;
           return a;
       };

       a = 3;
       Delegate2 = delegate(int arg)
       {
           return a + arg;
       };
   }

   public void Test()
   {
       Console.WriteLine(Delegate1(1));
       Console.WriteLine(Delegate2(1));
   }

   static void Main(string[] args)
   {
       Program p = new Program();
       p.Test();
   }
}

 

That example is a little misleading cause I did it as a recruitment question for technical evaluation, but it shows the concept in its barebones. Take a look cause that enables you to defer the execution. Another potential place where that is pretty useful is in UI Libraries. Probably we would need to split this into another topic.

 

Greetings

Red Knight

Link to comment
Share on other sites

I've had a look at your fishbowl project. And it has potential.

I'd make a few comments.

  • I think some more up front design is required.
  • Consider reducing the number of classes e.g. Instead of having Mobile, Tank and Biped, start with Mobile. Likewise (and this is something I'm planning on doing to the existing item structure) instead of Grenade, Equipment, Weapon and WeaponMagazine have just an Equipment class, where each Equipment can have a set of actions.

 

Thanks for the construtive criticism. I am going to defer the deeper structure issues for now and focus and getting the interfaces more or less done. Particularly the part that the graphics engine will be talking too and UI. My hope is to get someone else who is good with the graphics part to work on that part and then I can go back into the guts and work on refactoring.

 

My process is very bottoms up, so I often end up with unwieldy prototypes. It is the classic computer science problem. In order to solve a problem you have to understand it. In order to understand a problem you have to solve it.

 

The defered execution callbacks are cool. I think for now I will stick with the regular observer pattern and we can let the observer defer them if needed.

 

And yes Red Knight, I am tottally keen to try genetic algorithms to build the AI. I have some experience with that in the past. Not that it worked super good, but it was a great learning experience.

-D

Link to comment
Share on other sites

I have made a lot of progress. This is just a code update. I need a simple graphics frontend so I can visualize what's going on inside. Once I have a working prototype of that, hopefull the graphics geniuses here can work on that end and make it nice.

 

-D

 

What exactly are you looking for? you mean a scene and some buttons etc?

Link to comment
Share on other sites

I have made a lot of progress. This is just a code update. I need a simple graphics frontend so I can visualize what's going on inside. Once I have a working prototype of that, hopefull the graphics geniuses here can work on that end and make it nice.

 

-D

 

What exactly are you looking for? you mean a scene and some buttons etc?

 

No, I can do that. What I really need is something a little more special purpose. I need a scene that is logically broken up into boxes (think like a rubics cube). Then I need to be able to draw the "walls" of the boxes where I want. The mildly tricky part is that I want to then be able to turn on and off every wall at will. Also, if a wall is drawn, it needs to be visible from any angle. (so in reality the walls are just really thin models.) I also need to be able to place models in the boxes. Seems pretty simple really.

 

Problem 1. I can't make my models programatically. (I made some progress with the VertexBuffer, but the learning curve is steep and I kinda don't care how models are made.)

 

Problem 2. All the example code I have looked at is very poorly designed. I tried to refactor some of it to be more object oriented, but everything is so glued to the graphicsdevice I can't seem to make it work for me.

 

Problem 3. I don't have any model building software, and I really don't want to spend time learning any.

 

Problem 4. All the examples are interested in the low level stuff like the pixel shaders and using height maps. All I want is to be able to place models in 3d space.

 

Problem 5. I am about 10 times more productive working on code that isn't the graphics engine. So while I am interested in learning new things, I feel like I am wasting my valuable programming time going so S.L.O.W. (for example, I would much rather be working on AI).

 

possible Solutions:

1. I need to start making models or find some that will work.

2. Scrap me making the 3d interface and just create an output channel in something easy. Like ASCII :). Just so I can visualize the problems and make sure the object model is working.

3. One of your graphics geniuses whips up an XNA project that works for me. It needs to have a 3d box class. The boxes have a texture, Vector3 position (center) and a Vector3 size(x,y,z).

 

public Class 3DBox

{

public Vector3 Location;

public Vectro3 Size;

public Texture Texture;

public Update();

Public Draw();

}

 

I should be able to create these objects, and they should show up on the screen at box.Position. Ideally I could change the textures.

Link to comment
Share on other sites

I have made a lot of progress. This is just a code update. I need a simple graphics frontend so I can visualize what's going on inside. Once I have a working prototype of that, hopefull the graphics geniuses here can work on that end and make it nice.

 

-D

 

What exactly are you looking for? you mean a scene and some buttons etc?

 

No, I can do that. What I really need is something a little more special purpose. I need a scene that is logically broken up into boxes (think like a rubics cube). Then I need to be able to draw the "walls" of the boxes where I want. The mildly tricky part is that I want to then be able to turn on and off every wall at will. Also, if a wall is drawn, it needs to be visible from any angle. (so in reality the walls are just really thin models.) I also need to be able to place models in the boxes. Seems pretty simple really.

 

Problem 1. I can't make my models programatically. (I made some progress with the VertexBuffer, but the learning curve is steep and I kinda don't care how models are made.)

 

Problem 2. All the example code I have looked at is very poorly designed. I tried to refactor some of it to be more object oriented, but everything is so glued to the graphicsdevice I can't seem to make it work for me.

 

Problem 3. I don't have any model building software, and I really don't want to spend time learning any.

 

Problem 4. All the examples are interested in the low level stuff like the pixel shaders and using height maps. All I want is to be able to place models in 3d space.

 

Problem 5. I am about 10 times more productive working on code that isn't the graphics engine. So while I am interested in learning new things, I feel like I am wasting my valuable programming time going so S.L.O.W. (for example, I would much rather be working on AI).

 

possible Solutions:

1. I need to start making models or find some that will work.

2. Scrap me making the 3d interface and just create an output channel in something easy. Like ASCII :). Just so I can visualize the problems and make sure the object model is working.

3. One of your graphics geniuses whips up an XNA project that works for me. It needs to have a 3d box class. The boxes have a texture, Vector3 position (center) and a Vector3 size(x,y,z).

 

public Class 3DBox

{

public Vector3 Location;

public Vectro3 Size;

public Texture Texture;

public Update();

Public Draw();

}

 

I should be able to create these objects, and they should show up on the screen at box.Position. Ideally I could change the textures.

I'll try and do something on that this weekend. (Probably very crude.)

Link to comment
Share on other sites

I have made a lot of progress. This is just a code update. I need a simple graphics frontend so I can visualize what's going on inside. Once I have a working prototype of that, hopefull the graphics geniuses here can work on that end and make it nice.

 

-D

 

What exactly are you looking for? you mean a scene and some buttons etc?

 

No, I can do that. What I really need is something a little more special purpose. I need a scene that is logically broken up into boxes (think like a rubics cube). Then I need to be able to draw the "walls" of the boxes where I want. The mildly tricky part is that I want to then be able to turn on and off every wall at will. Also, if a wall is drawn, it needs to be visible from any angle. (so in reality the walls are just really thin models.) I also need to be able to place models in the boxes. Seems pretty simple really.

 

Problem 1. I can't make my models programatically. (I made some progress with the VertexBuffer, but the learning curve is steep and I kinda don't care how models are made.)

 

Problem 2. All the example code I have looked at is very poorly designed. I tried to refactor some of it to be more object oriented, but everything is so glued to the graphicsdevice I can't seem to make it work for me.

 

Problem 3. I don't have any model building software, and I really don't want to spend time learning any.

 

Problem 4. All the examples are interested in the low level stuff like the pixel shaders and using height maps. All I want is to be able to place models in 3d space.

 

Problem 5. I am about 10 times more productive working on code that isn't the graphics engine. So while I am interested in learning new things, I feel like I am wasting my valuable programming time going so S.L.O.W. (for example, I would much rather be working on AI).

 

possible Solutions:

1. I need to start making models or find some that will work.

2. Scrap me making the 3d interface and just create an output channel in something easy. Like ASCII :). Just so I can visualize the problems and make sure the object model is working.

3. One of your graphics geniuses whips up an XNA project that works for me. It needs to have a 3d box class. The boxes have a texture, Vector3 position (center) and a Vector3 size(x,y,z).

 

public Class 3DBox

{

public Vector3 Location;

public Vectro3 Size;

public Texture Texture;

public Update();

Public Draw();

}

 

I should be able to create these objects, and they should show up on the screen at box.Position. Ideally I could change the textures.

I'll try and do something on that this weekend. (Probably very crude.)

 

I will check Darkhomb's link friday and see if it works. Otherwise "very crude" sounds like about what I was aiming for.

 

-D

Link to comment
Share on other sites

No, I can do that. What I really need is something a little more special purpose. I need a scene that is logically broken up into boxes (think like a rubics cube). Then I need to be able to draw the "walls" of the boxes where I want. The mildly tricky part is that I want to then be able to turn on and off every wall at will. Also, if a wall is drawn, it needs to be visible from any angle. (so in reality the walls are just really thin models.) I also need to be able to place models in the boxes. Seems pretty simple really.

This isn't quite what SaintD asked for, but I think will show him how to do what he requires.

Screenshot attached.

Points to note.

  • You move the camera north/south/west/east with the up/down/left/right arrow keys
  • You move the camera up/down with the PageUp/PageDown keys.
  • The layout of the terrain is specified in the terrain's constructor. Have a look at InitializeTerrain() in Game1.cs for example of how to do it.
  • The two main classes of interest are Terrain, which provides does the 3D walls and Grid which draws a 2D grid on the "ground".
  • Terrain should also be used to provide environmental information to the combatants in the fishbowl. Functions to do this are left to SaintD.
  • Terrain contains code transplants from the Geoscape's Skybox, and Grid is from the Base Layout. Game1.cs was lifted from "How to: Draw Points, Lines, and Other 3D Primitives" in the help that comes with XNA. So please forgive me if there are misleading comments in the code.
  • Theoretically, Terrain will handle a 3D array of cells, however I haven't tested that. I'd suggest we stick to a 2D playing field initially.

Bowl001.01.JPG

Bowl001.zip

Link to comment
Share on other sites

No, I can do that. What I really need is something a little more special purpose. I need a scene that is logically broken up into boxes (think like a rubics cube). Then I need to be able to draw the "walls" of the boxes where I want. The mildly tricky part is that I want to then be able to turn on and off every wall at will. Also, if a wall is drawn, it needs to be visible from any angle. (so in reality the walls are just really thin models.) I also need to be able to place models in the boxes. Seems pretty simple really.

This isn't quite what SaintD asked for, but I think will show him how to do what he requires.

Screenshot attached.

Points to note.

  • You move the camera north/south/west/east with the up/down/left/right arrow keys
  • You move the camera up/down with the PageUp/PageDown keys.
  • The layout of the terrain is specified in the terrain's constructor. Have a look at InitializeTerrain() in Game1.cs for example of how to do it.
  • The two main classes of interest are Terrain, which provides does the 3D walls and Grid which draws a 2D grid on the "ground".
  • Terrain should also be used to provide environmental information to the combatants in the fishbowl. Functions to do this are left to SaintD.
  • Terrain contains code transplants from the Geoscape's Skybox, and Grid is from the Base Layout. Game1.cs was lifted from "How to: Draw Points, Lines, and Other 3D Primitives" in the help that comes with XNA. So please forgive me if there are misleading comments in the code.
  • Theoretically, Terrain will handle a 3D array of cells, however I haven't tested that. I'd suggest we stick to a 2D playing field initially.

Bowl001.01.JPG

Bowl001.zip

 

Really nice. Thanks. This should help quite a lot.

Link to comment
Share on other sites

No, I can do that. What I really need is something a little more special purpose. I need a scene that is logically broken up into boxes (think like a rubics cube). Then I need to be able to draw the "walls" of the boxes where I want. The mildly tricky part is that I want to then be able to turn on and off every wall at will. Also, if a wall is drawn, it needs to be visible from any angle. (so in reality the walls are just really thin models.) I also need to be able to place models in the boxes. Seems pretty simple really.

This isn't quite what SaintD asked for, but I think will show him how to do what he requires.

Screenshot attached.

Points to note.

  • You move the camera north/south/west/east with the up/down/left/right arrow keys
  • You move the camera up/down with the PageUp/PageDown keys.
  • The layout of the terrain is specified in the terrain's constructor. Have a look at InitializeTerrain() in Game1.cs for example of how to do it.
  • The two main classes of interest are Terrain, which provides does the 3D walls and Grid which draws a 2D grid on the "ground".
  • Terrain should also be used to provide environmental information to the combatants in the fishbowl. Functions to do this are left to SaintD.
  • Terrain contains code transplants from the Geoscape's Skybox, and Grid is from the Base Layout. Game1.cs was lifted from "How to: Draw Points, Lines, and Other 3D Primitives" in the help that comes with XNA. So please forgive me if there are misleading comments in the code.
  • Theoretically, Terrain will handle a 3D array of cells, however I haven't tested that. I'd suggest we stick to a 2D playing field initially.

Bowl001.01.JPG

Bowl001.zip

 

Really nice. Thanks. This should help quite a lot.

 

I've attached an updated Bowl001.zip that includes an A* search for pathfinding. The changes I've made are:

1) Cell and Terrain moved into separate project and built into Terrain.dll

2) Cell and Terrain now use a struct Coordinate for their location, this structure stores an ordered triplet of integers

3) Added a PathFinder project that builds into PathFinder.dll. This project includes a generic A* search, and the definition of an interface IAStarHelper.

IAStarHelper is an adapter class that provides utility functions for a particular search space to allow the A* search to work on a variety of search spaces.

4) Added a TerrainSearch project that builds into TerrainSearch.dll. This project includes an implementation of IAStarHelper that is used to allow the A* search to search through the Terrain class.

5) Updated initialization of Game1.grid so that it is automatically the same size as the terrain.

6) Added two new functions to Game1

- if the 'p' key is pressed, a shortest path from the upper-left to lower-right corner is displayed. If there is no path because of walls, no path is displayed

- if the 'c' key is pressed, any displayed shortest path is cleared

 

Notes: TerrainAdapter accepts a boolean argument that determines whether or not diagonal movement is allowed.

If diagonal movement is allowed, cutting across the outside of a corner is currently allowed - this can be turned off if desired

This is definitely beta quality code - it needs more comments, and currently does not support any but the simplest vertical movement. It can, however

be easily updated to support vertical movement via ramps/elevators/lifts/etc fairly easily through the TerrainAdapter class.

There is a bug remaining that I did not yet fix - if there are no walls, an exception is thrown when trying to create meshes for the walls. I think I know

where to fix it, but haven't gotten around to it yet.

 

Travis

Bowl001.zip

Link to comment
Share on other sites

I've had some ideas on what will be required to move from the current fishbowl project to something usable for battlescape. Does anyone object to me writing up some requirements/ideas? I know that saintd has been working on this, and I don't want to step on any toes, but at the same time, I'm eager to get some aliens kicking humans around the map :D .

 

Travis

Link to comment
Share on other sites

I've had some ideas on what will be required to move from the current fishbowl project to something usable for battlescape. Does anyone object to me writing up some requirements/ideas? I know that saintd has been working on this, and I don't want to step on any toes, but at the same time, I'm eager to get some aliens kicking humans around the map :D .

 

Travis

Fishbowl is an experiment/playground for people to try out their ideas.

So,

1. Please, go ahead and start writing up your requirements.

2. It doesn't matter if you step on toes, I want people to have different ideas on how to do things.

Link to comment
Share on other sites

I've attached an updated Bowl001.zip that includes an A* search for pathfinding. The changes I've made are:

1) Cell and Terrain moved into separate project and built into Terrain.dll

2) Cell and Terrain now use a struct Coordinate for their location, this structure stores an ordered triplet of integers

3) Added a PathFinder project that builds into PathFinder.dll. This project includes a generic A* search, and the definition of an interface IAStarHelper.

IAStarHelper is an adapter class that provides utility functions for a particular search space to allow the A* search to work on a variety of search spaces.

4) Added a TerrainSearch project that builds into TerrainSearch.dll. This project includes an implementation of IAStarHelper that is used to allow the A* search to search through the Terrain class.

5) Updated initialization of Game1.grid so that it is automatically the same size as the terrain.

6) Added two new functions to Game1

- if the 'p' key is pressed, a shortest path from the upper-left to lower-right corner is displayed. If there is no path because of walls, no path is displayed

- if the 'c' key is pressed, any displayed shortest path is cleared

 

Notes: TerrainAdapter accepts a boolean argument that determines whether or not diagonal movement is allowed.

If diagonal movement is allowed, cutting across the outside of a corner is currently allowed - this can be turned off if desired

This is definitely beta quality code - it needs more comments, and currently does not support any but the simplest vertical movement. It can, however

be easily updated to support vertical movement via ramps/elevators/lifts/etc fairly easily through the TerrainAdapter class.

Stupid questions time, why split it into multiple DLLs? What's the gain?

 

There is a bug remaining that I did not yet fix - if there are no walls, an exception is thrown when trying to create meshes for the walls. I think I know

where to fix it, but haven't gotten around to it yet.

Travis

It's probably Draw(), you can't draw an empty list.

Link to comment
Share on other sites

I've attached an updated Bowl001.zip that includes an A* search for pathfinding. The changes I've made are:

1) Cell and Terrain moved into separate project and built into Terrain.dll

2) Cell and Terrain now use a struct Coordinate for their location, this structure stores an ordered triplet of integers

3) Added a PathFinder project that builds into PathFinder.dll. This project includes a generic A* search, and the definition of an interface IAStarHelper.

IAStarHelper is an adapter class that provides utility functions for a particular search space to allow the A* search to work on a variety of search spaces.

4) Added a TerrainSearch project that builds into TerrainSearch.dll. This project includes an implementation of IAStarHelper that is used to allow the A* search to search through the Terrain class.

5) Updated initialization of Game1.grid so that it is automatically the same size as the terrain.

6) Added two new functions to Game1

- if the 'p' key is pressed, a shortest path from the upper-left to lower-right corner is displayed. If there is no path because of walls, no path is displayed

- if the 'c' key is pressed, any displayed shortest path is cleared

 

Notes: TerrainAdapter accepts a boolean argument that determines whether or not diagonal movement is allowed.

If diagonal movement is allowed, cutting across the outside of a corner is currently allowed - this can be turned off if desired

This is definitely beta quality code - it needs more comments, and currently does not support any but the simplest vertical movement. It can, however

be easily updated to support vertical movement via ramps/elevators/lifts/etc fairly easily through the TerrainAdapter class.

Stupid questions time, why split it into multiple DLLs? What's the gain?

 

 

Actually, not a stupid question. I had to split them into separate projects, as the TerrainAdapter needs to reference the Cell and Terrain classes (in one project), and the A* search (in a separate project), and I would like to keep the search algorithm in a separate assembly as it might be used elsewhere. I'm sure that as time goes on, this will all get rearranged more than once.

Link to comment
Share on other sites

 

I've read through and digested the Terrain/MCD docs dteviot referenced, and there's a big decision about the battlescape to be made right up front. I have a recommendation, but I want to try to present the options as clearly as possible first:

 

1) True 3D

2) Pseudo-3D ala X-Com

 

True 3D

Cons:

  • Longer Development Time
  • More difficult testing
  • Inability to *directly* reuse UFO2000 materials

Pros:

  • Better Expandability
  • "Prettier" Battlescape
  • Removes Fixed POV Restriction

Pseudo-3D

Cons:

  • Fixed Isometric POV
  • Difficult - or Impossible - to Make More Advanced Terrain (Caves, etc)

Pros:

  • Direct Use of UFO2000 Resources
  • Easier Development
  • Easier Testing
  • Less Effort to Recreate Original as closely as possible

That list of pros and cons made a few assumptions:

  • Pseudo-3D would use the same fixed isometric POV as the original
  • Either True or Pseudo 3D would still use the "cube" system for movement

My recommendation is to use "True 3D" ... BUT, do it in such a way that we can use the UFO2000 data and editor to get us started. To this end, I propose a program to import UFO2000 terrain and map files, and convert them into actual 3D meshes ... it wouldn't have to be pretty to begin with, just something that shows us that it can work. Once things have been imported, hand-tuning could be done if necessary for visual quality. To do that, we would need to define a map/terrain format that works with a true 3D rendering engine, but can handle all the capabilities of the XCom/UFO2000 .mcd, .pck, .tab files.

 

I think using the "cube" system is still necessary, as going to a "continuous" positioning system would require much more effort:

  • Pathfinding search uses either exponentially more memory and processor time, OR
  • Tiling scheme would have to be used, which is *very* non-trivial, and can lead to very bad pathing if not done correctly
  • With a cube system, it is easier to replicate the battlescape of the original
  • Continuous positioning doesn't work well with turn-based - if moving a troop one "unit" at a time in a continuous system, many many clicks would be required
  • TU calculations for a continuous system would be difficult
  • Explosion calculations for a continuous system would be difficult

So ... questions, comments, snide remarks, exclamations of joy and/or pain? If people like this idea, I'm ready to run with it.

 

First thing (as dteviot said earlier) would be to define the functionality/capabilities of the terrain model. This could start as a concise listing of the capabilities of the XCom/UFO2000 model, with additions for features that will either be required by going to a 3D system, or will support desired future functionality. I'm putting together a summary of XCom terrain functionality and capabilities, along with an approach to convert said functionality into a 3D battlescape.

 

After that, we can define the data structure and interfaces for terrain/map data, and put together a UFO2000 importer. For initial use, the UFO2000 editor will allow us to do everything necessary to replicate the original game, and give us some relief from having to write our own editor. At some point, writing our own editor would allow us to edit our data directly, instead of importing from UFO2000, but it wouldn't be required right away.

 

Travis

Link to comment
Share on other sites

True 3D and Pseudo3D is something that with the way the APIs handle it there is no difference (The difference is the orientation of the camera). The question that arrise is why, because in Pseudo3D you are using sprites so in the end is not 3D. The discretization of the world is what it is important. In fact it is a matter of how small are the voxels that you are using. With floating point you have a lot of accuracy but the discretization would be unwildly for "storing" purposes so you have to use continues methods for collision, movement, positioning, etc like ray casting. With voxelization ? la XCom you have BIG voxels that make AI easier but movement far more limited.

 

Luckily there is a third way ;) that is an hybrid between the two, you have a discreet world but with smaller voxels to the point that the movement can be calculated using DDA (Discrete Differential Analyzers) algorithms but in the end when you look at it from the user point of view it gives the sense of being continues. The trick is in finding the smaller voxel size that is big enough to define a discretized space usable for the AI (computational bound) and movement but at the same time small enough to give the sense of free roaming (user experience bound). Algorithms are the same as the BIG voxels, movements by the user are "sensed" as if it was Apocalypse in RealTime. Basically you are decoupling your AI to use voxel style world while your environment in fully 3D. You only need to have both in sync. ;)

 

About reusing UFO2000 assets the pallete they use is highly incompatible with the actual rendering work that needs to be done. The maps can be read in such a way that only the underlaying "House here", "Rock there" structure is used but that involve importing that information. For proof of concept, is just easier to create a random map with the features you need by code, for production probably we can create an importer but you need to have all the graphics assets in place for that. It is a cool feature to be able to import those maps because there is already a lot of map creation and testing done but Xenocide will have to create the random maps anyway for Single Player.

 

Greetings

Red Knight

Link to comment
Share on other sites

We must strongly consider a loosely coupled architecture for the graphics engine and game logic. We don't have compelling performance reasons to tightly couple them. The overall architecture I am advocating looks like this. There are a lot of benifits too a loosely coupled design. Testability, Maintainability, and parrallelization of programming efforts are big ones.

 

I might be wrong, but Red Knight seems to be advocating making the battlescape a lot like a high performance 3D shooter, where the graphics code and "business logic" of the game are very tightly coupled. I am very much against this approach. Although I am in awe of his deep knowledge of 3D graphics.

 

 

Here is my "vision" in short. Ideally we would design all the interfaces up front. But I think we can learn a lot of lessons by prototyping first. (so consider my work a prototype).

  • A thin graphics engine/UI that calls an API on the games rules engine to get a "map" of what the playing field looks like.
  • The thin engine signs up for a few events (anything that would trigger an animation or a sound).
  • User input is supplied to the game rules engine via a programming API (basically the public methods).
  • The game rules keep track of units, health, ammo and have a "cube based" map of what's where in the game world.
  • The game rules don't care about graphics anything. Including models, textures and so on.
  • The graphics engine calls an API (just an enum in this case) to get a list of models the game thinks are in each cube.
  • Math in the game engine is very simple (compared to regular 3D graphics anyway).
  • The "alien" AI can be another module completely that calls the game engine API on it's turn.

I have successfully welded the UI in this thread to the battlescape object I already wrote. Right now it can't do anyting but draw walls but it's a start. :)

 

I have a few sticking minor points.

  • When I did the coordinate system for the battlescape, I put the X and Y axis on the "ground" and made the Z axis the levels. However, the graphics engine has the X and Y axis vertical to the ground and the Z axis comes "out" from the screen. I realize the second way is probably the standard. We can easily translate the systems. Or we can refactor one or the other system to "think" the other way. For now, I am going to go with "translation".
     
  • We need some a list of models we want to use on the battlescape. Here are a few I thought of.
    Aliens, Humans, Tanks, Terror Units.
    Various walls, hedges, doors and windows.
    couch_left, couch_right, stove, chair, counter, gas_pump, table_1, table_2, table_3, table_4, tv, lowstairs, highstairs, haybale, dirtblock, dirtramp
     
  • Could someone add a tilt control to the graphics engine?

I think it's time to move this into the prototype node in source control. Can you set that up Red Knight?

ProjectFishBowl.zip

Edited by SaintD
Link to comment
Share on other sites

True 3D and Pseudo3D is something that with the way the APIs handle it there is no difference (The difference is the orientation of the camera). The question that arrise is why, because in Pseudo3D you are using sprites so in the end is not 3D. The discretization of the world is what it is important. In fact it is a matter of how small are the voxels that you are using. With floating point you have a lot of accuracy but the discretization would be unwildly for "storing" purposes so you have to use continues methods for collision, movement, positioning, etc like ray casting. With voxelization ? la XCom you have BIG voxels that make AI easier but movement far more limited.

 

The difference I referred to between the XCom "pseudo-3d" and true 3D is that the structure and content of the XCom/UFO2000 data is such that rendering from a different camera orientation isn't even possible. The data is not actually rendered, it's just a set of images that get laid down in order from furthest to nearest.

 

For purposes of determining the best voxel size, I can work up some simulations ... maybe start with a 60x60x5 standard XCom map, and then go to 120x120x10, keep increasing the number of voxels in the map, and look at CPU Utilization. For planning purposes, the pathfinding search might have to look at routes that cross most of the map, but for individual unit movement, the search space would be much smaller, as it would be limited by available TUs, so it is conceivable that fairly small voxels could be used.

 

Luckily there is a third way ;) that is an hybrid between the two, you have a discreet world but with smaller voxels to the point that the movement can be calculated using DDA (Discrete Differential Analyzers) algorithms but in the end when you look at it from the user point of view it gives the sense of being continues. The trick is in finding the smaller voxel size that is big enough to define a discretized space usable for the AI (computational bound) and movement but at the same time small enough to give the sense of free roaming (user experience bound). Algorithms are the same as the BIG voxels, movements by the user are "sensed" as if it was Apocalypse in RealTime. Basically you are decoupling your AI to use voxel style world while your environment in fully 3D. You only need to have both in sync. ;)

 

I think, as far as a hybrid goes, we are saying the same thing, albeit in different ways. I was thinking of having movement limited to cubes as in the original, but the terrain itself could be designed down to the single-pixel (or even subpixel, if you go with floats) level if desired. Basically, I was envisioning terrain being continuous meshes, with the object and movement grid overlaid over the top of it, with cubes being the same as in the original. Now that you mention it, though, I don't have any problem with finer granularity for movement or AI. Fidelity to the original becomes interesting (do you have to be in the exact same voxel as a dropped item to pick it up, or within a certain range; what about size and spacing in doorways - if voxel size and troop size are mismatched, some things from the original - such as a single unit blocking a door - might not work out exactly the same way; I'm sure we can come up with others.) That being said, I don't think it's an insurmountable issue to achieve pretty close fidelity to the original even using very small voxels ... it just will require some careful design and testing.

 

I think that it will be important (from a development and testing effort point of view) to keep the movement and ai voxel the same size - otherwise tesselization becomes ugly - at one extreme leading to inaccurate pathfinding, and at the other eating all your compute resources.

 

About reusing UFO2000 assets the pallete they use is highly incompatible with the actual rendering work that needs to be done. The maps can be read in such a way that only the underlaying "House here", "Rock there" structure is used but that involve importing that information. For proof of concept, is just easier to create a random map with the features you need by code, for production probably we can create an importer but you need to have all the graphics assets in place for that. It is a cool feature to be able to import those maps because there is already a lot of map creation and testing done but Xenocide will have to create the random maps anyway for Single Player.

 

Like I said, the UFO2000 assets would be ugly when auto-imported, but could be cleaned up later. For importing XCom/UFO2000 resources, I was actually talking about the .mcd, .pak, .tab files more than any specific map. The .mcd files define the behavior of tiles (Walls, Objects, flammability, lifts, explosiveness, what happens when it's destroyed, etc, etc), and the loftemps file defines the heightfields that are used for line-of-fire calculations. I was thinking that an importer could take each tile from the .mcd, import it's functional characteristics, use the loftemps file to generate a rough 3D mesh, and then use the image from the .pak file to texture the mesh. In the import process, the pallette could be taken care of. It wouldn't be a trivial effort, but I think that it would give us more to work with, earlier, than doing stuff by hand. Then again, for movement and AI purposes, textures (and even exact meshes) aren't all that important.

 

Perhaps the best approach would be to define a data model for terrain and objects that allows all the functionality from XCom/UFO2000 (but that supports smaller voxels), so that later an importer could be developed, but then get a simple terrain generator done for testing.

 

When going through the UFO2000 Terrain/mcd information, I started working out a data model that would work for the battlescape. I propose splitting out battlescape data into the following categories:

  • Actors: all things that can take actions, or react (aliens, troops, tanks, primed grenades, etc)
  • Objects: all things that can't take actions themselves, but can be used or manipulated (equipment, corpses, etc)
  • Terrain: the landscape
  • Decorations: items that are present, but not usable (lamps, lightposts, bushes, trees, etc)
  • Buildings: umm ... buildings

There is nothing restricting something from being in more than one category - for example, grenades can be both objects and actors. My approach would be that each category is defined by an interface - things in the game can implement more than one interface. Some interfaces, like actor and object, would be fairly complex, while terrain would be fairly simple.

 

An event system would be used to allow for reaction fire, prox grenade detonation, stopping a movement sequence on sighting an alien, etc. Given the categories above, only Actors would subscribe to the event system - all other categories could be acted on directly (for example, terrain being affected by an explosion) - but would not require asynchronous event notification. This would reduce the number of items receiving battlescape events, and allow for common code to be lumped together (probably in an actor base class).

 

For ease of development, I think integrating scripting (Lua?) into the battlescape would make AI development *MUCH* easier. Each element of the battlescape could export a defined interface to the scripting system, and the scripts could handle behavior. Computation intensive tasks could be programmed into the battlescape in C#, and called from scripts. I would prefer scripting for AI and object behavior, over .NET DLLs because it would expand the pool of potential developers, and reduce some of the risks/vulnerabilities associated with using plugin .DLLs. That being said, I'm not 100% against plugin .DLLs, as personally I could probably develop something faster in C# than in Lua, but I think on the whole, using a script language would be a better choice.

 

Ok .. I'm going to cut this post off here, as I've diverged wildly from the starting point. Anwyay ... thanks for the great discussion, I think that we can hammer out something that will work very well.

 

Travis

 

PS - I've also looked at the "Battlescape Planning Matrix" on the wiki, and realized that it had no associated planning document with it. I'll start working up a draft of the planning document, based on discussions here and items in the matrix, and then we can synchronize the matrix with the document.

 

Travis

Link to comment
Share on other sites

I might be wrong, but Red Knight seems to be advocating making the battlescape a lot like a high performance 3D shooter, where the graphics code and "business logic" of the game are very tightly coupled. I am very much against this approach. Although I am in awe of his deep knowledge of 3D graphics.

 

Here is my "vision" in short. Ideally we would design all the interfaces up front. But I think we can learn a lot of lessons by prototyping first. (so consider my work a prototype).

  • A thin graphics engine/UI that calls an API on the games rules engine to get a "map" of what the playing field looks like.
  • The thin engine signs up for a few events (anything that would trigger an animation or a sound).
  • User input is supplied to the game rules engine via a programming API (basically the public methods).
  • The game rules keep track of units, health, ammo and have a "cube based" map of what's where in the game world.
  • The game rules don't care about graphics anything. Including models, textures and so on.
  • The graphics engine calls an API (just an enum in this case) to get a list of models the game thinks are in each cube.
  • Math in the game engine is very simple (compared to regular 3D graphics anyway).
  • The "alien" AI can be another module completely that calls the game engine API on it's turn.

I have successfully welded the UI in this thread to the battlescape object I already wrote. Right now it can't do anyting but draw walls but it's a start. :)

I think it's time to move this into the prototype node in source control. Can you set that up Red Knight?

Mind you, I know nothing about 3d programming so I could be just blowing hot air, but have you considered calculations for shooting/attacks? In particular, how would you calculate the path of the shot, and not only where would it hit on the target, but in the event of a miss, where would it go? Given that we will have models that have half height, and possibly models with gaps (Windows, trees, heck, even between the legs of a soldier!) that can be shot through, will it be possible to calculate the path divorced from the models?

Link to comment
Share on other sites

We must strongly consider a loosely coupled architecture for the graphics engine and game logic. We don't have compelling performance reasons to tightly couple them. The overall architecture I am advocating looks like this. There are a lot of benifits too a loosely coupled design. Testability, Maintainability, and parrallelization of programming efforts are big ones.

 

I might be wrong, but Red Knight seems to be advocating making the battlescape a lot like a high performance 3D shooter, where the graphics code and "business logic" of the game are very tightly coupled. I am very much against this approach. Although I am in awe of his deep knowledge of 3D graphics.

 

 

Here is my "vision" in short. Ideally we would design all the interfaces up front. But I think we can learn a lot of lessons by prototyping first. (so consider my work a prototype).

  • A thin graphics engine/UI that calls an API on the games rules engine to get a "map" of what the playing field looks like.
  • The thin engine signs up for a few events (anything that would trigger an animation or a sound).
  • User input is supplied to the game rules engine via a programming API (basically the public methods).
  • The game rules keep track of units, health, ammo and have a "cube based" map of what's where in the game world.
  • The game rules don't care about graphics anything. Including models, textures and so on.
  • The graphics engine calls an API (just an enum in this case) to get a list of models the game thinks are in each cube.
  • Math in the game engine is very simple (compared to regular 3D graphics anyway).
  • The "alien" AI can be another module completely that calls the game engine API on it's turn.

I have successfully welded the UI in this thread to the battlescape object I already wrote. Right now it can't do anyting but draw walls but it's a start. :)

 

I have a few sticking minor points.

  • When I did the coordinate system for the battlescape, I put the X and Y axis on the "ground" and made the Z axis the levels. However, the graphics engine has the X and Y axis vertical to the ground and the Z axis comes "out" from the screen. I realize the second way is probably the standard. We can easily translate the systems. Or we can refactor one or the other system to "think" the other way. For now, I am going to go with "translation".
     
  • We need some a list of models we want to use on the battlescape. Here are a few I thought of.
    Aliens, Humans, Tanks, Terror Units.
    Various walls, hedges, doors and windows.
    couch_left, couch_right, stove, chair, counter, gas_pump, table_1, table_2, table_3, table_4, tv, lowstairs, highstairs, haybale, dirtblock, dirtramp
     
  • Could someone add a tilt control to the graphics engine?

I think it's time to move this into the prototype node in source control. Can you set that up Red Knight?

 

 

I agree with separating the data and control from the rendering engine (maybe not exactly MVC, but something akin to it). However, we need to be careful about implementing too much before we do a little design. I know this is a prototype, but if it's to be used for AI testing, we need to make sure the interface to the AI changes as little as possible between prototype and release. Any type of AI, especially computational intelligence methods, is sensitive to slight changes, and if the interface isn't nailed down prior to prototype, AI that worked perfectly in prototype could fail miserably in production. Since the original point of the fishbowl was to test AI methods, that would be undesirable at best.

 

Some Issues So Far

From the discussion with red knight, it looks like we're moving away from having the cube size be the same as unit size, but that can be handled relatively easily.

Many things are stored in enums inside battlescape.cs that should probably be extracted from data. For example, we don't want to have to add another element to the DamageType enum if someone wants to add a "sonic" damage type. The list of types should be extracted from the data, rather than being hardcoded.

 

I think the battlescape you have is a decent start, but we should discuss requirements for both production and prototype before we do too much development. Where it's at right now, it's flexible, and easy to modify/extend, but we don't want to keep adding to it until we've defined where we're going. Some of the interfaces you've put up fall right in line with what I was talking about in my previous post with separating terrain/objects/actors/etc.

 

Travis

Link to comment
Share on other sites

Ok - here's a listing of the terrain information that is in the original .mcd, .tab, .pck, and loftemps and scang .dat files. Most of it is in the .mcd, but I've included the others to get a complete picture of what must be supported for fidelity to the original. I've noted what categories these items should apply to (see above for definition of terrain/actor/object/building/decoration categories - note that ships would probably be both buildings and actors). I've also added comments in places where it seems that there's a simple way to abstract the functionality and make it more flexible. My goal is to get some input on this, and turn it into the initial interface spec for some of the battlescape data structures. Note that this is intended to be all-inclusive, and DOES NOT currently separate rendering from data model from game rules. After we agree on a list of functionality, then the functional partitioning can begin.

  • Texture and Animation - Terrain, Decoration, and Buildings. Actors and Objects will have their own models (presumably the same as the XNet models)
  • Line of Fire Template (loftemps) - Unnecessary - should be handled by the graphics engine (perhaps raycasting?)
  • Reference to scang.dat - Terrain, Decoration, Buildings, Actors, Objects (this is used for rendering the top-down map - anything that will be shown in the top-down will need to specify how it is rendered there.
  • (Boolean) Is Sliding Door? - Buildings
  • (Boolean) Blocks Line of Sight? Terrain, Decoration, and Objects (although this could possibly be completely deferred to the rendering engine for all battlescape elements)
  • (Boolean) Can Be Stood On? Terrain, Building, Object, Decoration, (Actor?) - Represents if non-flying units can stand on it or fall through it
  • (Boolean) Is wall? Building - This may not even be necessary - by separating terrain from buildings, this may be able to be determined without being explicitly set.
  • (Boolean) Is Grav Lift? Building. In original, Up/Down of lift was determined by presence of grav lift tiles above and below. If we go to a terrain model that uses much smaller voxels (see Red Knight's discussion), we may have to change to explicitly specifying top and bottom of lift travel
  • (Boolean) Is Hinged Door? Building.
  • (Boolean) Blocks Fire? Terrain, Building, Object, Decoration
  • (Boolean) Blocks Smoke? Terrain, Building, Object, Decoration
  • TUs to cross tile. Terrain, Building. In original, specified for walking, flying, and sliding (snakemen and silacoids use this, and possibly tanks). We could expand this to be generally include TUs for any movement type desired.
  • Armor of Tile. Terrain, Building, Decoration. Used to determine if tile is destroyed. Tiles do not have health - they are destroyed if a single hit does more damage than their armor value, and not otherwise. Actors and objects will also have armor, but this will be in their stats, rather than part of the terrain. Note that if we want to provide the ability for future expansion, it would be simple to include both armor and health values, simply leaving health values at 1 for things representative of the original.
  • Amount that tile blocks HE damage
  • What tile becomes when destroyed. Terrain, Building, Decoration, Object.
  • Resistance to setting on fire. Terrain, Building, Decoration. (Actor and Object flammability will be handled separately)
  • If tile is a door, the tile to show when door is open. Building.
  • Terrain Height. Terrain, Building. Note that terrain will be handled differently from buildings, but both will need a height.
  • y-offset of tile image. Unnecessary, handled by 3D rendering.
  • Amount of light blocked by tile. Can probably be handled through transparency in textures for any item that is textured.
  • Footstep sound effect. Terrain/Building (Object/Decoration ? - For stepping on dropped items ?)
  • Tile Type (Floor, North Wall, West Wall, Object) - Unnecessary, or at least needs changed. We should allow arbitrary placement of walls. A flag for floor/ceiling might be necessary, though. Objects will be handled separately.
  • Explosive Type (HE or Smoke) - Only works if explosive strength is > 0. Building/Terrain/Object/Decoration
  • Explosive Strength - Building/Terrain/Object/Decoration
  • Smoke Blockage. Unused in original.
  • Duration of Burn if tile catches fire. Building/Terrain/Decoration. We should also add in the ability to handle the intensity of the burn (i.e. how much damage it does), and if the burn can spread to adjacent tiles.
  • Brightness of Tile (light production, only used for a few tiles in original). Building/Terrain/Object/Decoration.
  • Special Properties of Tile - Covers the starting point for mission, and what is salvaged at the end of mission if the tile isn't destroyed. Terrain/Building/Decoration. Should likely be split up into at least 2 fields, if not more - one for deployment zones, one for salvage at end of mission.
  • Victory Points lost if tile is destroyed (on XCom building tiles, for base defense missions). Building.

That covers everything in the original, and touches on a few points for extension. I'll follow up later with a list of things that should, could, or might be added.

 

Note - the list was taken from: UfoPaedia Terrain Article

 

Travis

Edited by twhickey
Link to comment
Share on other sites

I might be wrong, but Red Knight seems to be advocating making the battlescape a lot like a high performance 3D shooter, where the graphics code and "business logic" of the game are very tightly coupled. I am very much against this approach. Although I am in awe of his deep knowledge of 3D graphics.

 

Here is my "vision" in short. Ideally we would design all the interfaces up front. But I think we can learn a lot of lessons by prototyping first. (so consider my work a prototype).

  • A thin graphics engine/UI that calls an API on the games rules engine to get a "map" of what the playing field looks like.
  • The thin engine signs up for a few events (anything that would trigger an animation or a sound).
  • User input is supplied to the game rules engine via a programming API (basically the public methods).
  • The game rules keep track of units, health, ammo and have a "cube based" map of what's where in the game world.
  • The game rules don't care about graphics anything. Including models, textures and so on.
  • The graphics engine calls an API (just an enum in this case) to get a list of models the game thinks are in each cube.
  • Math in the game engine is very simple (compared to regular 3D graphics anyway).
  • The "alien" AI can be another module completely that calls the game engine API on it's turn.

I have successfully welded the UI in this thread to the battlescape object I already wrote. Right now it can't do anyting but draw walls but it's a start. :)

I think it's time to move this into the prototype node in source control. Can you set that up Red Knight?

Mind you, I know nothing about 3d programming so I could be just blowing hot air, but have you considered calculations for shooting/attacks? In particular, how would you calculate the path of the shot, and not only where would it hit on the target, but in the event of a miss, where would it go? Given that we will have models that have half height, and possibly models with gaps (Windows, trees, heck, even between the legs of a soldier!) that can be shot through, will it be possible to calculate the path divorced from the models?

 

 

Nicely called out. You have hit my main concern right on the head. I think these problems have reasonable simple solutions without an entire 3d Model to figure it out.

Link to comment
Share on other sites

Ok - here's a listing of the terrain information that is in the original .mcd, .tab, .pck, and loftemps and scang .dat files. Most of it is in the .mcd, but I've included the others to get a complete picture of what must be supported for fidelity to the original. I've noted what categories these items should apply to (see above for definition of terrain/actor/object/building/decoration categories - note that ships would probably be both buildings and actors). I've also added comments in places where it seems that there's a simple way to abstract the functionality and make it more flexible. My goal is to get some input on this, and turn it into the initial interface spec for some of the battlescape data structures. Note that this is intended to be all-inclusive, and DOES NOT currently separate rendering from data model from game rules. After we agree on a list of functionality, then the functional partitioning can begin.
  • Texture and Animation - Terrain, Decoration, and Buildings. Actors and Objects will have their own models (presumably the same as the XNet models)
  • Line of Fire Template (loftemps) - Unnecessary - should be handled by the graphics engine (perhaps raycasting?)
  • Reference to scang.dat - Terrain, Decoration, Buildings, Actors, Objects (this is used for rendering the top-down map - anything that will be shown in the top-down will need to specify how it is rendered there.
  • (Boolean) Is Sliding Door? - Buildings
  • (Boolean) Blocks Line of Sight? Terrain, Decoration, and Objects (although this could possibly be completely deferred to the rendering engine for all battlescape elements)
  • (Boolean) Can Be Stood On? Terrain, Building, Object, Decoration, (Actor?) - Represents if non-flying units can stand on it or fall through it
  • (Boolean) Is wall? Building - This may not even be necessary - by separating terrain from buildings, this may be able to be determined without being explicitly set.
  • (Boolean) Is Grav Lift? Building. In original, Up/Down of lift was determined by presence of grav lift tiles above and below. If we go to a terrain model that uses much smaller voxels (see Red Knight's discussion), we may have to change to explicitly specifying top and bottom of lift travel
  • (Boolean) Is Hinged Door? Building.
  • (Boolean) Blocks Fire? Terrain, Building, Object, Decoration
  • (Boolean) Blocks Smoke? Terrain, Building, Object, Decoration
  • TUs to cross tile. Terrain, Building. In original, specified for walking, flying, and sliding (snakemen and silacoids use this, and possibly tanks). We could expand this to be generally include TUs for any movement type desired.
  • Armor of Tile. Terrain, Building, Decoration. Used to determine if tile is destroyed. Tiles do not have health - they are destroyed if a single hit does more damage than their armor value, and not otherwise. Actors and objects will also have armor, but this will be in their stats, rather than part of the terrain. Note that if we want to provide the ability for future expansion, it would be simple to include both armor and health values, simply leaving health values at 1 for things representative of the original.
  • Amount that tile blocks HE damage
  • What tile becomes when destroyed. Terrain, Building, Decoration, Object.
  • Resistance to setting on fire. Terrain, Building, Decoration. (Actor and Object flammability will be handled separately)
  • If tile is a door, the tile to show when door is open. Building.
  • Terrain Height. Terrain, Building. Note that terrain will be handled differently from buildings, but both will need a height.
  • y-offset of tile image. Unnecessary, handled by 3D rendering.
  • Amount of light blocked by tile. Can probably be handled through transparency in textures for any item that is textured.
  • Footstep sound effect. Terrain/Building (Object/Decoration ? - For stepping on dropped items ?)
  • Tile Type (Floor, North Wall, West Wall, Object) - Unnecessary, or at least needs changed. We should allow arbitrary placement of walls. A flag for floor/ceiling might be necessary, though. Objects will be handled separately.
  • Explosive Type (HE or Smoke) - Only works if explosive strength is > 0. Building/Terrain/Object/Decoration
  • Explosive Strength - Building/Terrain/Object/Decoration
  • Smoke Blockage. Unused in original.
  • Duration of Burn if tile catches fire. Building/Terrain/Decoration. We should also add in the ability to handle the intensity of the burn (i.e. how much damage it does), and if the burn can spread to adjacent tiles.
  • Brightness of Tile (light production, only used for a few tiles in original). Building/Terrain/Object/Decoration.
  • Special Properties of Tile - Covers the starting point for mission, and what is salvaged at the end of mission if the tile isn't destroyed. Terrain/Building/Decoration. Should likely be split up into at least 2 fields, if not more - one for deployment zones, one for salvage at end of mission.
  • Victory Points lost if tile is destroyed (on XCom building tiles, for base defense missions). Building.

That covers everything in the original, and touches on a few points for extension. I'll follow up later with a list of things that should, could, or might be added.

 

Note - the list was taken from: UfoPaedia Terrain Article

 

Travis

 

 

The object model I have built accounts for about 90% of this. I think we could get started on converting most of this to an XML format right away. It seems pretty likely we are going to want to use an XML format for this just like the Geodata.

Link to comment
Share on other sites

This isn't quite what SaintD asked for, but I think will show him how to do what he requires.

Bowl001.zip

 

This has been perfect. I can now see what's going on and have been able to verify a lot of functionality already. I have gotten the "6 walls" of the cells all working! So now I can draw building and houses and whatnot. :D Saddly, I didn't integrate my version with the pathfinding version. However, I am very pleased to have see a one level pathfinding system working.

 

Requests for the graphics guys

  • How can I change the texture of an abitrary wall? (Setting it at creation time is fine)
  • How can I draw a model in one of the squares? (and do we have some model assets ready? even spheres and cubes would be fine for now.)
  • Can we add a some more movement controls? It would be really nice to be able to tilt the scene to see it from the sides. (I cheated and changed the cameraView a little and that's ok for now)
  • Can we add a mouse cursor and detect which cell a user is clicking on?

Edit: 6 walls, not just 4. :)

Edited by SaintD
Link to comment
Share on other sites

Requests for the graphics guys

    How can I change the texture of an abitrary wall? (Setting it at creation time is fine)

http://www.gamasutra.com/features/20060126/ivanov_pfv.htm

Basic idea, build a texture that has the sub textures you want. Then, when you specify the texture UV co-ordinates to use with a mesh poly, you use the co-ordinates of the desired sub texture.

 

How can I draw a model in one of the squares? (and do we have some model assets ready? even spheres and cubes would be fine for now.)

Here's the basics for loading and drawing a model.

http://msdn2.microsoft.com/en-us/library/bb197293.aspx

To put the model where you want it, you scale it to the desired size, then apply rotation and translations to the object's world matrix to position it. XNet provides an example of this, where models are loaded, scaled to uniform size, rotated to standard orientation, then moved to center of scene.

 

Can we add a some more movement controls? It would be really nice to be able to tilt the scene to see it from the sides. (I cheated and changed the cameraView a little and that's ok for now)

http://msdn2.microsoft.com/en-us/library/bb197901.aspx

 

Can we add a mouse cursor and detect which cell a user is clicking on?

http://msdn2.microsoft.com/en-us/library/bb203905.aspx

Link to comment
Share on other sites

I might be wrong, but Red Knight seems to be advocating making the battlescape a lot like a high performance 3D shooter, where the graphics code and "business logic" of the game are very tightly coupled. I am very much against this approach. Although I am in awe of his deep knowledge of 3D graphics.
Graphics are one thing that YOU have to take care of anyways :) but they are divorced of how you approach your world. As long as you have a 2 way mapping between your "World" and your "Visual World" you are done. But always remember you have to fill the gap between those. If you have 1 World for both, you write World code and Rendering. If you have 2 Worlds you write the World code, the Rendering + Visual World code and the gap (sync) between both of them. The smaller the gap the less code you have to write; this is true too in other areas like GUI anyone knows why we still use buttons instead of gestures in all software ;) ?. HINT: How do we interact in real life?

 

Other thing is that we coders go overboard with flexibility (saw several projects already in that path) and in the end you create somethings that is very flexible but so complex that you cannot do anything with it. My piece of advice is: "Flexibility and 'Data based' is overrated" but we are doing a prototype so this is the time to go overboard anyway ;)...

 

About the representation, current graphics pipeline do use discretization of space as do 3D Shooters too :) it is just a matter of which discretization is the more useful for the task at hand. ;) BTW I had been reading how the smoke is handled on the upcoming DirectX10 game "Hellgate: London" on GPU Gems 3 (all the series more than recommendable) and you would be surprised how not different is what we are talking about ;)

 

I think it's time to move this into the prototype node in source control. Can you set that up Red Knight?

 

Sure, I dont go home today but I will ask mindstormmaster to setup everything for you in the prototype branch.

 

Greetings

Red Knight

Link to comment
Share on other sites

When I did the coordinate system for the battlescape, I put the X and Y axis on the "ground" and made the Z axis the levels. However, the graphics engine has the X and Y axis vertical to the ground and the Z axis comes "out" from the screen. I realize the second way is probably the standard. We can easily translate the systems. Or we can refactor one or the other system to "think" the other way. For now, I am going to go with "translation".

I'm going to say that I think this is a bad idea. By having 2 co-ordinate frames, it gives us two problems.

1. We always have to stop and think, "Which frame am I using in this case?"

2 I can guarantee we're going to get it wrong in some cases, and then weird things happen (which can be difficult to track down.) e.g. when nothing is rendered to the screen, figuring out what's wrong can be very difficult.

 

As we are using XNA, we're obliged to use it's co-ordinates. SO I'm going to say "use that frame exclusively."

 

We need some a list of models we want to use on the battlescape. Here are a few I thought of.

Aliens, Humans, Tanks, Terror Units.

Various walls, hedges, doors and windows.

couch_left, couch_right, stove, chair, counter, gas_pump, table_1, table_2, table_3, table_4, tv, lowstairs, highstairs, haybale, dirtblock, dirtramp

For the fishbowl, think simple:

We don't need "Aliens, Humans, Tanks, Terror Units." We need a "combatant". Initially they will be the same, but when we design them, we do need to keep in mind that we will want to make them unique later on.

 

Likewise the fishbowl doesn't need "walls, hedges, doors and windows.

couch_left, couch_right, stove, chair, counter, gas_pump, table_1, table_2, table_3, table_4, tv, lowstairs, highstairs, haybale, dirtblock, dirtramp"

 

Think: we need a "terrain". The properties of the terrain are:

  • (Minimal) Depending on where a combatant is, it will allow or block (or in the case of falling, force) movement in a specific direction. (e.g. Walls block the ability to cross the boundary between cells. Objects in a cell may prevent the combatant entering cell at all. Hight difference in cells may prevent combatants from crossing the boundary. Or lack of hight difference will allow transit between levels. e.g. Ramp) Finally, grav lift allows units to move vetically that normally couldn't.
  • We need to represent the terrain in a format that allows the software to enforce the rules, and reason about. it.
  • We need to be able to render the terrain in a format that a User can easily understand it.

Additional terrain features (which we may implement in stages):

  • Terrain may restrict a combatants' fields of view.
  • Terrain may be "deformable or modifyable". E.g Blow it up. (Note, X-COM1's problem with "floating" 2nd floors when bottom is destroyed.)
  • Terrain may inflict damage on combatants. (set it on fire.)
  • Lighting

similar lists for combatants, and UI are left as exercises to the reader.

 

twhichey, thanks for your lists of terrain properties, that's a helpful start.

I'd also suggest that A* may not be that useful to us.

  • Because we're dealing with small unit combat, most of the time movements will be over short distances, and be weighted by lots of other considerations "Movement of other team members, observed opponents, cover, current tactical objectives, Not moving in predictable paths, etc.
  • Second, most of the maps are fairly simple, and optimal path following isn't needed. What's really needed is being able analyze the map into regions and identify the "choke points" between the regions.

Of course, this is just my opinion. But it's something I hope the fishbowl can allow us to test.

Link to comment
Share on other sites

I second David comments, "Simplicity is the key to understanding" and somehow we need the machine to "understand" where it is. A* exists, it is implemented and very important to be done efficiently, but that it is only pathfinding. If I remember from AI classes the trick of the AI is to define the world in such a way that you can reason over it ;)... and reasoning is the most difficult part :)

 

Greetings

Red Knight

Link to comment
Share on other sites

×
×
  • Create New...