Assignments
Jay Carr
like to help, but I'm just a novice, so I need to be told what to
do :-).
Also, I was wondering if the admins might rate the assignments as they
are created. Maybe use tags to say if they are hard or easy (or what
have you), just so us n00bs know what we are getting into.
Jay Douglas Carr
Cory Kilger
difficulty of an issue to be used when creating issues. They we can
simply label them as we do the type and priority.
So what happened at NSCoder Night? I saw that Dave committed a new
factory class. Is there a reason for me not to add methods for AIs?
Dave?
Cory
Dave DeLong
1. Defining labels to rate difficulty is a fantastic idea. Let's do
that.
2. NSCoder Night was mostly showing Robert and Jay how objective-c
classes work, from the context of Vici. We generated a whole bunch of
Core Data classes for the model and talked about them.
I just checked in a rather large commit (yes, it compiles!). Here's
what it is and my reasoning behind it.
First off, I generated the class files for the entities in our Core
Data model. This will allow us to add custom logic to, say, the Army
class. We'll also be able to deal with Army objects directly instead
of nebulous "NSManagedObjects". I think it will help for cleanliness
and readability.
Second, I've grouped these entity classes into a new target called
"ViciCore". This is a framework target that will contain almost all
of the Model layer of Vici. I did this because plugins will have to
know about the model layer (Countries, Continents, etc), but we don't
want each plugin having its own copy of the County object, because
that would create conflicts when we load plugins (ie, trying to load a
class with the same name as an existing class). Therefore, plugins
will just link the ViciCore framework, which Vici will have
internally. Then when we load plugins, the plugin will just
automatically link up to the existing ViciCore framework.
Third, I've created two abstract classes: ViciGamePlugin and
ViciMapPlugin. These will be used as the "principal class" of the
plugins and will help us know if the plugin is a Map plugin or a Game
plugin. To see how plugin loading works, check out the findPlugins
method of ViciGameFactory ( http://code.google.com/p/byuch-project1/source/browse/trunk/Model/ViciGameFactory.m
).
Finally, I've added another target called ViciRisk. This will be a
ViciGamePlugin where we create regular Risk as a way of building a
simple plugin as we go.
As for AI, here's how I think it should work: Any AI we want to
create should be a subclass of the Player entity. We can use a
regular player to represent a human player, and then add subclasses
for a NetworkPlayer and any kind of AI we want. To the rest of the
Model level, the *kind* of player (Human, Network, AI) should be
totally transparent. We'll accomplish this through this sort
hierarchy. So Cory, if you'd like to begin making an AI, we'll
probably need another plugin type (ViciPlayerPlugin) where the
principal class is a subclass of the Player class. Then any AI stuff
you want to do would be part of your own plugin.
Dave
Dave DeLong
Dave
On Oct 13, 2009, at 11:13 PM, Dave DeLong wrote:
> ...we'll probably need another plugin type (ViciPlayerPlugin) where
> the principal class is a subclass of the Player class....
Cory Kilger
When in the meaning system of our game we choose to create a new
game. We have a few pop-up menus or something where we choose the
player types, map and game type all from the loaded plugins. We would
then pass these chosen options to the GameFactory which would use the
plugins to create an NSManagedObjectContext which will represent the
game. That would then be passed to the Game object's init method and
the Game object will manage all the functionality: dice rolls, player
turn, etc.
I was also thinking about how the map plugin would be structured. I
imagine it would have 3 parts: 1) an image (or images) to provide a
backdrop, 2) an HTML image map like structure (http://www.w3schools.com/TAGS/tag_map.asp
) to indicate what countries are located where on the image(s), and 3)
a Core Data persistent store containing the map data.
I suppose the game plugin would be a bunch of triggers, conditions and
actions. How would these be programmed? Would a plugin use mostly
custom code, or would we have stuff built-in to the core that the
plugins can easily build off of? How does Core Data handle storing
subclasses of the model's entities?
It seems like the player plugin would just be a subclass of
ViviPlayerPlugin conforming to a player protocol. Anything else to
worry about here?
Cory