Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Mar 2011
Offline Last Active Private

Posts I've Made

In Topic: How to...

13 June 2013 - 11:21 AM

I have a few questions :)


on which line does it crash? you can use the angelScript debugger to step through code and figure out exactly where it's crashing.


As for the sizeof() operator, I'm not (entirely) sure, but why not overload a function in the C++ side like so? 

template <typename T>
unsigned int SizeOf(T *x){
  return sizeof(T);

//register the function for different types. I haven't used AS in a while, so I'm 
//not really sure about the parameters :)
ASengine->RegisterGlobalFunction("unsigned int sizeof(int @T)", asFUNCTION(SizeOf<int>), asCALL_CDECL);

ASengine->RegisterGlobalFunction("unsigned int sizeof(float @T)", asFUNCTION(SizeOf<float>), asCALL_CDECL);

//and so on for all other types

In Topic: Best way to provide access to services for my entities?

05 June 2013 - 10:54 AM

so, you have "components" that provide access to data, and "Services" to use those components and bring out behaviour, is that correct?


As far as I'm aware, something like this is implemented in the way you talked about, have an entityManager class, that has one list of all entities in the game, and another list of all Services.


On each frame tick, the entityManager asks the Service classes to "operate" on the entities.

So, (pseudocode)

 ...other members...

 void Update(float dt){

  for(int i = 0; i < whatever_end_index; i++){
    //loop over all services
    Service *service = this->services[i];
    service->processObjects(this->objectsList, dt);


 where Service is an abstract base class. Service receives the list of all Entities in the game (this can be optimized, of course, so that Service holds a reference to the list).

the Service then checks if the Entity has _ALL_ the Components that it needs. If the Entity does have all the components needed, it goes ahead and processes the Entity.

if not, it goes to the next one, and so on...


for a more concrete example, check out the Artemis Entity Framework, or my own engine (albeit rough around the edges).


It's a problem I've grappled with quite a few times. I've used multiple approaches (make the Component class have both logic and data, use "mixins", and all other wacky ideas.), but this is the most extensible one I've found. At some point, you'll find yourself blurring the line between data and logic. Unless you want to create the Observer Patternfor each class (which is not really feasible due to both size and memory constraints), such pure separation is pretty much impossible IMHO. But, we can try to keep the divide as strict as possible :)


Hope this helps!

In Topic: Skill/Animation Loading Across Units(XML)

24 May 2013 - 04:37 AM

I'm kind of confused - you seem to be asking both about loading data from XML as well as how to implement a generalized casting system. 


Anyway, as for the implementation details, if I remember correctly. warcraft 3 used to have standardised names for different things. Spell animations  were given names such as Spell1, Spell2, etc. Attack animations had names such as Attack1, AttackCrit and AttackSpin. The game engine would pick an animation out of a "list" of animations that you allowed. So for example, an attack might have two animations enabled by it - Attack1 and Attack2. Whereas a specialized spell might only have one animation attached, such as SpellSummon. you only needed to supply the animation names. The animations were build into the models (the animations could be baked into the models using 3dSMax. I'm not sure about how it was done, as I've never ventured into the modelling side of things, but I'm pretty sure there was a plugin provided by blizzard for animation.)


As for particle effects and particle systems, the were known as "buffs". Buffs had no gameplay impact at all. They were used to attached particles and trails to "attachment points" on the model. these attachment points were also baked into the model. common attachment points included (hand,left), (hand,right), and chest. There were also other, more specialzed attachment points that only worked on a few models such as (mount). Anyway, these buffs could have a duration associated with them, and the particles expired after the duration.


When the particles were created, they played their "created" animation. and then they looped an intermediate animation. on being destroyed, they played their "destroyed"  animation. Like I said, particles were controlled indirectly through buffs. 


As for storage, blizzard has it's own format (.MPQ I think), with it's custom method for storing objects. I don't remember the details, but the wikipedia page has some decent information.


Hope this helps :)

In Topic: Expanding a game idea

08 April 2011 - 12:30 AM

bump :). Hoping for more ideas and inputs :D

In Topic: Expanding a game idea

06 April 2011 - 08:05 AM

thanks for the replies guys! I'll surely implement all of these :)