Re: [Triplea-develop] New games using TripleA engine

[Sean B. <sbr...@ya...>]

For grid and hex based games, it should be able to use
some sort of generator concept, where you say
something like

<map>
  <grid rows='10' columns='10' prefix='tile'>
</map>

And then later refer to "tile_4_2".  This would
require making the dtd a little more flexible
(currently you can't refer to a territory in the
xmlfile that hasn't been defined), but it shouldn't be
that hard.

Behind the scense, the grid element would create the
territories.  This then leads to the problem of how
does one define connections.  Some games would want to
wrap around, while others like stratego would want
certain connections to be removed.


What to put into the base classes has always been an
issue.  When I was making the base classes I was
trying to make them general, but I was always keeping
a&a in the back of my mind, so the classes are
somewhat flexible, but not suited to all game types.

The original (not terribly good) idea was to allow
attachments.  You could put what you want into an
attachment, and then attach it to a territory, player,
resource or UnitType (unfortunatley not units).

Allowing the xml file to specify factories for the
base types, allowing different games to add properties
to the base units would have been a good idea. 


The way game state is represented in TripleA is quite
lacking.  Allowing game state to reside in the
delegates, rather than forcing all state to the
GameData was a mistake.  It would be nice to push
things like movement left this turn, what a transport
is carrying, and others into the unit.  This would
make using this information much easier on the client,
and would make a lot of the game logic easier.

For this some sort of factory system would also be
needed, and a good way of serializing this state to
the client.

Sean


Sean

--- Lane Schwartz <dow...@gm...> wrote:

> I've been looking at the existing TripleA code some
> more, with an eye toward
> adapting my TicTacToe code to the TripleA
> environent.
> 
> A few things jumped out at me fairly quickly.
> 
> There is pervasive use of PlayerID and GameData.
> Looking through PlayerID
> and GameData, the concepts of map-based territories,
> units, resources, and
> territory-centric production are all widely used.
> 
> However, for many games (starting with TicTacToe and
> Connect4), a lot of
> those concepts don't map well to the game.
> 
> The big question then becomes, how should the basic
> game engine be changed
> (if at all) to allow for different types of games?
> 
> Some games could be coerced into the existing engine
> design and
> expectations. TicTacToe, for example - you could
> treat each square as a
> territory, and each X or O as a unit. But, in
> grid-based games, it's much
> nicer to have a 2D array of game square data that
> you have access to, as
> opposed to treating the grid as a territory-based
> map with every connection
> explicitly written out in an xml file.
> 
> One approach I thought of would be to make PlayerID
> and GameData much
> simpler, parent classes. Then you could have
> TripleAPlayerID and
> GridGamePlayerID. Perhaps TripleAPlayerID would
> implement new interfaces
> called ResourceHolder and ProductionFrontierHolder,
> while GridGamePlayerID
> wouldn't. Likewise, TripleAGameData would have more
> in it than
> TicTacToeGameData.
> 
> The other approach that I thought of would be to
> maintain a PlayerID and
> GameData as they are now, but to add additional code
> to them to handle new
> types of games. In this approach, GameData might
> have an additional member
> variable that is a 2D array of game board squares
> (along with corresponding
> get and set methods). I'm not sure yet what, if
> anything, would need to be
> added to PlayerID.
> 
> An advantage to the second approach is that there
> wouldn't be a split in the
> classes. TripleA would simply ignore those new parts
> of GameData which
> aren't relevant to it. Likewise, TicTacToe would
> ignore much of the existing
> parts of GameData and PlayerID. Each new game that's
> added could use those
> parts of the existing structure that fit that game,
> and, if needed, new
> functionality could be added to GameData, PlayerID,
> and other classes that I
> probably have missed.
> 
> On the other hand, the second approach would clutter
> existing classes.
> 
> 
> Let me know what you think.
> 
> Thanks,
> Lane
> 
> 
> On 4/25/07, Sean Bridges <sbr...@ya...>
> wrote:
> >
> > Hey,
> >
> > Making an engine for other games was one of the
> > original goals, but as it stands the code would
> need
> > some cleaning up, and much better documentation
> before
> > it is really ready.
> >
> > It is possible to use, but it will be challenging.
> > Depending on your needs, it may be easier to use
> the
> > TripleA engine component as a base rather than
> > starting from scratch.
> >
> > The ui was never really part of the engine, and it
> was
> > expected that each game would write the entire ui
> > portion.  If you want to start with something
> simple,
> > you can steal the code from my Connect4 game I
> made a
> > long time ago,
> >
> > http://geocities.com/sbridges.geo/C4/C4Conv.html
> >
> > To hook up the game you will need to write
> >
> > - A delegate to handle moving/validation of moves
> > - An IGamePlayer to handle making moves.  1
> > IGamePlayer exists for each game player (red and
> > black)
> > - An IDispaly to handle displaying a game. 1
> IDisplay
> > exists for each ui.  A ui may have 0..n
> IGamePlayers
> > playing
> > - An IGameLoader to create the GamePlayers and
> > IDisplays
> > - A game.xml file.  This file will have the map,
> the
> > territories, one Delegate, 2 Steps (black move,
> red
> > move), and the GameLoader.
> >
> > The IDisplay will connect thee ui and the game.
> >
> > At the end of all of this you will get networking,
> > saving/loading games, the lobby server, observers
> who
> > can leave and join the game, PBEM, secure dice
> (not
> > relevant in connect 4) for free.
> >
> > Post here if you have any questions.
> >
> > Sean
> >
> >
> > --- Lane Schwartz <dow...@gm...> wrote:
> >
> > > Hi guys,
> > >
> > > A while back, I emailed with some of you, and I
> > > mentioned that I had made
> > > some initial steps toward using the TripleA
> engine
> > > to develop an Advanced
> > > Civilization-like game. Time constraints got in
> my
> > > way, and that fell by the
> > > wayside.
> > >
> > > I am still interested in eventually taking the
> Civ
> > > idea forward. More than
> > > that, I think the TripleA engine could serve as
> a
> > > good base for lots of
> > > other board games (including crayon rails
> games).
> > > But, before I try get in
> > > over my head again, I thought it would be best
> to
> > > get a good understanding
> > > of the code base.
> > >
> > > To do that, I thought I would start very simple
> -
> > > with Tic Tac Toe. I think
> > > I have a decent understanding of what's going on
> in
> > > terms of writing new
> > > delegate classes for the various parts of a new
> > > game.
> > >
> > > For new map-centric games (like Risk) the
> existing
> > > UI code should work
> > > great, with little modification required. But,
> there
> > > are lots of games that
> > > I suspect would work better with different UI
> code -
> > > square grids for games
> > > like Tic Tac Toe, checkers, chess; points &
> lines or
> > > hex grids for rail
> > > games; the capacity for dealing with cards for
> lots
> > > of games.
> > >
> > > And when it comes to writing new UI code that
> > > integrates well, I'm more than
> > > a bit shaky. My immediate goal is writing a
> simple
> > > square-grid UI for Tic
> 
=== message truncated ===>
-------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2
> express and take
> control of your XML. No limits. Just data. Click to
> get it now.
> http://sourceforge.net/powerbar/db2/>
_______________________________________________
> Triplea-developers mailing list
> Tri...@li...
>
https://lists.sourceforge.net/lists/listinfo/triplea-developers
> 



       
____________________________________________________________________________________Give spam the boot. Take control with tough spam protection in the all-new Yahoo! Mail Beta.
http://advision.webevents.yahoo.com/mailbeta/newmail_html.html