Hello:
Thanks for the info. IT doesn't really model the data I wanted. The
contents was easy enough, I'm just going to set up a 1:n relationship on
the Entity to the actual player. But for components, it's a bit different.
Each component inherits the actual Component class, and has a number of
attributes on it. I can't just put it in it's own. So I was going to set
up a table per component and then just store an id and another id for
what holds it. But my problem is modeling it. I also need the inherited
data from Component. Would there be a way to do this? I could have:
id, name, component_id
and then SA could use the name as the table's name, and the id as the id
of the component in the other table.
How would I set this up with SA? Is it a good idea to go this route?
On 8/25/2012 5:53 PM, Dennis Lee Bieber wrote:
On Sat, 25 Aug 2012 14:47:35 -0600, "Littlefield, Tyler"
declaimed the following in
gmane.comp.python.general:
Hello all:
I had a quick question.
In my game, I have an is-a setup, where all objects contain data like an
id for sqlalchemy, a name, a description and a list of contents.
Well, a "list of contents" comes down to a table of items with a
foreign key to the item "containing" them...
create table objects
(
ID integer auto-increment primary key,
namevarchar(?),
description varchar(?)
)
1, Wulfraed, something or other
2, Bag of Holding, whatever
3, Sword, some cutting comments
4, Treasure Chest, everyone wants one
create table holdings
(
ID integer auto-increment primary key,
holder integer foreign key objects(ID),
holding integer foreign key objects(ID)
)
1, 1, 2
2, 1, 3
3, 2, 4
In order to add functionality to an object, you add components. So for
example, a player would have the Player and Living component associated
create table attribute_types
(
ID integer auto-increment primary key,
namevarchar(?),
typechar(?),#or an enumeration if supported by the RDBM
#and SQLAlchemy
)
1, Player, Boolean
2, Living, Boolean
3, EdgeWeapon, Boolean
4, Damage, DieRoll
5, ContainerSize, Integer
6, Class, Text
create table attributes
(
ID integer auto-increment primary key,
describes integer foreign key objects(ID),
attribute integer foreign key attribute_types(ID),
value BLOB(?)
)
1, 1, 1, blob(True)
2, 1, 2, blob(True)
3, 3, 3, blob(True)
4, 3, 4, blob("1D8 + 4")
5, 2, 5, blob(-1) #-1 being unlimited, bag of holding
6, 4, 5, blob(6)#treasure chest holds 6 units of objects
7, 1, 6, blob("Ranger")
Now, you could add another layer of indirection -- a table of
pre-defined object /types/ (different types of containers, swords, other
weapons), and have each instance (the ones shown in "objects") refer to
the object type table, and the object type table is what the object
attributes refers to.
--
Take care,
Ty
http://tds-solutions.net
The aspen project: a barebones light-weight mud engine:
http://code.google.com/p/aspenmud
He that will not reason is a bigot; he that cannot reason is a fool; he that
dares not reason is a slave.
--
http://mail.python.org/mailman/listinfo/python-list
