It is currently Thu Dec 14, 2017 5:48 pm

All times are UTC + 9:30 hours




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Support Plugin of game data
PostPosted: Sun Dec 21, 2008 7:16 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Quote:
The direction our project is taking is that we are building a generic offering that other will be able to customize.

So that means that we need to separate data from the game logic
This is not related to a gameEngine, as they will load images but not game data.
But how this can be achieved is not yet clear(I haven't found it yet).
This is not hard:
#1 All game data should be outside of classes
#2 define needed data
#3 put static data into a file bin/xml/txt whatever in the res folder

So for each current data class(co,officers,terrains, units) we need to find the static fields=(fields that never change) and list them up here.
I'll start with Terrains because they seem to be the easiest to load from a file, and I just want to give a fast example. :D

Code:
  <Terrain Name="Grass" Id="0">
    <Defence>2</Defence>
    <Height>0</Height>
    <Description>Grass is easily traveled but offers little defense.</Description>
  </Terrain>

We then can use 1 Terrain class and create a Terrain object for each Terrain with the given data.
In the game we still need to identify each terrain hence the Id.

We can arrange the images in an array and put the grass image in the first slot. So when rendering the map we can loop over each tile
grab the terrainID and get the image from the array.
When an item should be 0 null or "" then just don't provide the data. For example a terrain with 0 defense and no description would look like:
Code:
  <Terrain Name="Grass" Id="0">
    <Height>0</Height>
  </Terrain>


It's important that inside the classes we don't referrer to the grass name always use the Id.

What if we wanted to get a bridge can't hardcode the id of a bridge in the game:
Add another field like a boolean spansOverWater then loop over all terrains and grab terrains that have spansOverWater set to true.

another example for units
Code:
  <Unit Name="Infantry" Id="0">
    <Price>1000</Price>
    <Movement>3</Movement>
    <Vision>2</Vision>
    <CanCapture>True</CanCapture>
    <MaxHp>10</MaxHp>
    <MaxSupplies>10</MaxSupplies>
    <SuppliesPerTurn>2</SuppliesPerTurn>
    <MaxExperience>10</MaxExperience>
    <ArmyBranch>Ground</ArmyBranch>
    <MovementType>INF</MovementType>
    <Primary_Weapon Id="0">
      <Ammo>99</Ammo>
    </Primary_Weapon>
    <Description>Infantry units that are equipped to take out Tanks,\n They have a bazooka and a machin gun as secondary
      weapon.
    </Description>
  </Unit>


Properties
Code:
  <Property Name="City" Id="0" Type="City">
    <Funds>1000</Funds>
    <Heals>Ground</Heals>
    <HealRate>5</HealRate>
    <MaxCaptureAmount>20</MaxCaptureAmount>
    <Vision>1</Vision>
    <Description>They give you money and heal units inside them.</Description>
  </Property>
  <Property Name="Factory" Id="1" Type="Factory">
    <Funds>1000</Funds>
    <Heals>Ground</Heals>
    <HealRate>5</HealRate>
    <Builds>Ground</Builds>
    <MaxCaptureAmount>20</MaxCaptureAmount>
    <Vision>1</Vision>
    <Description>Factories heal, provide supplies and can create new ground units.</Description>
  </Property>
  <Property Name="Airport" Id="2" Type="Factory">
    <Funds>1000</Funds>
    <Heals>Air</Heals>
    <HealRate>5</HealRate>
    <Builds>Air</Builds>
    <MaxCaptureAmount>20</MaxCaptureAmount>
    <Vision>1</Vision>
    <Description>empty</Description>
  </Property>
  <Property Name="Port" Id="3" Type="Factory">
    <Funds>1000</Funds>
    <Heals>Naval</Heals>
    <HealRate>5</HealRate>
    <Builds>Naval</Builds>
    <MaxCaptureAmount>20</MaxCaptureAmount>
    <Vision>1</Vision>
    <Description>empty</Description>
  </Property>
  <Property Name="HQ" Id="4" Type="City">
    <Funds>1000</Funds>
    <Heals>Ground</Heals>
    <HealRate>5</HealRate>
    <MaxCaptureAmount>20</MaxCaptureAmount>
    <Vision>1</Vision>
    <Description>If you capture this Property you destroy that player. It has a good defence.
    </Description>
    <isHQ>True</isHQ>
  </Property>
  <Property Name="Missle silo" Id="5" Type="Property">
    <Funds>500</Funds>
    <MaxCaptureAmount>20</MaxCaptureAmount>
    <Vision>1</Vision>
    <Description>Empty</Description>
  </Property>


Top
 Profile  
 
 Post subject: Re: Support Plugin of game data
PostPosted: Sun Dec 21, 2008 8:37 pm 
Offline
User avatar

Joined: Tue Oct 28, 2008 8:51 am
Posts: 121
Yes, I agree we must externalize all of the resources used for the game content.
In defining them we can consider working from the minimum upwards for the main engine.
For example in the base game a unit would be bare:

  • HEALTH - HP will always be deduced
  • AMMO - ammo will always be deduced after firing
  • DESCRIPTION
  • ALLEGIANCE - I'm not sure what is the best workd for it but I don't like "army branch" as its too particular.
  • WEAPON - All vehicles must have at least one weapon
  • MOVEMENT - All vehicles can move to some extent, this would have a subelement called "RANGE"

If per say there were an advance wars plugin it would additionally provide the following fields in its DTD:

  • PRICE - Units can be bought during game rounds
  • SUPPLIES - Supplies are used with subelements of "MAX" and "PERTURN"
  • CAPTURABLE - can capture units
  • VISION - Fog of war obscures movement areas
  • EXPERIENCE - Experience is gained. A sub element would be "MAX".
  • TYPE - different actions occur depending on vehicle type, this would be an additional subelement under "MOVEMENT".

On an unrelated note, as xml is case insensitive and just by convention it is in uppercase I'd like to keep it like that ala: http://www.developer.com/tech/article.php/797861

This resource based external plugin content is part f the extendability of which we must speak of but also we have to consider providing interfaces to which can be extended by the plugin developers. Consider the unit interface, by making plugin implementers provide the methods for a unit's get/set the fields I described at the top, they can then extend above and beyond these original concepts to provide the functionality of vision and supplies.


Top
 Profile  
 
 Post subject: Re: Support Plugin of game data
PostPosted: Mon Dec 22, 2008 10:25 pm 
Offline
User avatar

Joined: Fri Jun 23, 2006 2:34 am
Posts: 4700
Location: London
Have you also thought about Lua for the external data?


Top
 Profile  
 
 Post subject: Re: Support Plugin of game data
PostPosted: Mon Dec 22, 2008 10:44 pm 
Offline
User avatar

Joined: Tue Oct 28, 2008 8:51 am
Posts: 121
Lua has been mentioned quite a lot, but I'm still waiting to hear why Lua is needed. I'm not against it's use in any way but I am unfamiliar why it is more suitable for whattever task that is being thought of than the native language of custom wars (Java). In order to clarify why Lua would be suitable, could someone with experience in Lua, Java and custom wars please explain to me:

  • The functionality which would benefit from Lua
  • The advantages of using Lua compared to java for these actions
  • The disadvantages of using Lua compared to java for these actions (as there is always a trade off).

Then I could help consider it, at the moment as someone with no Lua experience I cannot comment on the appropriateness of using the language for any features of the project.


Top
 Profile  
 
 Post subject: Re: Support Plugin of game data
PostPosted: Tue Dec 23, 2008 1:03 am 
Offline
User avatar

Joined: Tue Oct 28, 2008 8:51 am
Posts: 121
How I see the end goal just now is akin to the architecture of the halflife engine.
With the halflife engine you can develop individual maps and put them in the C:\SIERRA\half-life\valve\maps folder. You can then access that map through the maps selection menu(much like we currently have). On top of the base maps you can also make a full mod based on their SDK. If you make a mod then the mod goes in the C:\SIERRA\Half-Life\modname folder. You then have a convention of sub-directories underneath that, this would look something like:

  • C:\SIERRA\Half-Life\modname\models\player
  • C:\SIERRA\Half-Life\modname\maps\
  • C:\SIERRA\Half-Life\modname\dlls\

So hypothetically we would have:
  • customwars\adhocWars\units
  • customwars\adHocWars\maps
  • customwars\adHocWars\story
  • customwars\adHocWars\officers
  • customwars\adHocWars\res


This is how popular games such as counterstrike, action half life and team fortress have been developed and the chances are you have them on your machine so you can try it out for yourself!
As lua was just mentioned and it is a scripting language then some might be intereted in the fact that a scripting language is also integrated into the the halflife engine which I presume is for all the console based admin stuff that can be evoked during the game. The main SDK is written in SDK C++.

The advantages of this style of architecture are thus:
  • The vanilla offering is quickly extendable through maps, skins and scripting
  • For the more ambitious they can compile their classes which extend the functionality of the original in C++
  • If plugin makers wish to develop their own stand alone gmae off the back of the architecture then they can just include the platform and configure it to start their plugin instead of the original game.


Top
 Profile  
 
 Post subject: Re: Support Plugin of game data
PostPosted: Tue Dec 23, 2008 2:34 am 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
chom_chom wrote:
Lua has been mentioned quite a lot, but I'm still waiting to hear why Lua is needed. I'm not against it's use in any way but I am unfamiliar why it is more suitable for whattever task that is being thought of than the native language of custom wars (Java). In order to clarify why Lua would be suitable, could someone with experience in Lua, Java and custom wars please explain to me:

  • The functionality which would benefit from Lua
  • The advantages of using Lua compared to java for these actions
  • The disadvantages of using Lua compared to java for these actions (as there is always a trade off).

Then I could help consider it, at the moment as someone with no Lua experience I cannot comment on the appropriateness of using the language for any features of the project.


I can speak for beanshell, but really they all do the same thing, It would allow to load a script file and pass functions(or events) through it, the behavior can be changed at runtime.
The script would have live objects like Map. The drawback is that it's just text, so it won't complain over a syntax error until runtime...

It's great for testing you can call functions on any live object, like:
  • Reading all resources again
  • Ai: Pro: Watch an ai perform an action, change a param in the script, undo redo action watch new effect.
  • Console: Pro: Query game state, control units as if the user click/performs actions
  • CO: same as ai

Scripting:
Pro: Its loosely typed, can use interfaces as if it was the object, closer related to the English language?
Con: doesn't show your errors
I'm not sure if it is easier for users with no programming exp

I've been playing with beanshell, it uses java syntax + loosely typed syntax x= 5 and int x = 5 are both valid.
I don't think a script is made for data storage only, that's not what a script is for, so what I think veggie is really saying is combine data and behavior into scripts.

Pro: No need to load xml files as scripts can access data directly
Con: This will make the scripts large even if they are split on every model object(unit, property).
there are +- 17x4 terrains each has a name, defense... that's alot of data, not to mention units.
I prefer a java framework that can be extended through java and modded in the xml and img resources over scripting because it's easier to dev.

So what will be scripted:
Console and reading resources again when you changed 1 line of text. ie
res.reload()
print(game.getTile(0,0)) etc.


Last edited by stef569 on Sat Feb 07, 2009 1:01 am, edited 2 times in total.

Top
 Profile  
 
 Post subject: Re: Support Plugin of game data
PostPosted: Wed Feb 04, 2009 11:52 pm 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Quote:
So hypothetically we would have:
  • customwars\adhocWars\units
  • customwars\adHocWars\maps
  • customwars\adHocWars\story
  • customwars\adHocWars\officers
  • customwars\adHocWars\res


I would propose
customwars\adhocWars\res\images\ -> Image only
customwars\adhocWars\res\data\ -> Readable Data only
customwars\adhocWars\res\data\story\
customwars\adhocWars\res\data\officers\
customwars\adHocWars\maps

We could use XStream to transform the xml doc to a java object(no coding needed, it uses reflection to set the fields which is awesome.)


Last edited by stef569 on Sat Mar 28, 2009 10:56 pm, edited 2 times in total.

Top
 Profile  
 
 Post subject: Re: Support Plugin of game data
PostPosted: Sat Mar 28, 2009 10:54 pm 
Offline
Main Coder

Joined: Fri Apr 04, 2008 10:50 pm
Posts: 169
Would there be some shared data between plugins?
Each plugin is probably going to use the select sound, copying that file in each plugin is a waste...
I can think of a way, when the game want to play a select sound it asks for a 'SelectUnit' it doesn't know until runtime what that file might be.

There is a list of default resources:
SelectUnit -> res/sound/select.ogg
and if a plugin doesn't specify the SelectUnit location then the default is used.

Actually forget about the above Each plugin loads It's own resources....


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

All times are UTC + 9:30 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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

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