Spherical forums

Sphere Development => Sphere Support => Script Support => Topic started by: ninjasword on June 01, 2013, 04:17:16 pm

Title: Maintaining a battle combatants array separately
Post by: ninjasword on June 01, 2013, 04:17:16 pm

I feel the exact same way sometimes. It's okay to overcomplicate things (as long as you mean it in a good way). If nothing slows the game down then don't worry. You can always go back and change things if they don't work.


its calming to know my OCD wont slow me down, but here is where i have a srs face question... if i copy a reference from one array onto another

Code: [Select]

var CombatantsList = []
CombatantsList.push( MapEntityList[1] )


and then i remove the reference from the second list

Code: [Select]

CombatantsList.splice( 0, 1 )


should i throw an error when i try to reference it from the first list?

Code: [Select]

MapEntityList[1].update()
Title: Re: Maintaining a battle combatants array separately
Post by: N E O on June 01, 2013, 04:50:39 pm
The MapEntity and MapEntityList arrays are unaffected when you splice from CombatantsList. You'll need to touch them as well if you actually intend for them to be removed when spliced from CombatantsList.
Title: Re: Maintaining a battle combatants array separately
Post by: ninjasword on June 02, 2013, 11:07:45 am

The MapEntity and MapEntityList arrays are unaffected when you splice from CombatantsList. You'll need to touch them as well if you actually intend for them to be removed when spliced from CombatantsList.


see thats wat i thot, i was just getting rid of the reference, but the object still there, and we both right the object still on the MapEntityList, my problem is actually a really old one, its one i had over a year ago when i started doing this whole turn based thing, ill try to be as succinct as i can.

Code: [Select]

function NewUpdateScript() {
  for ( i in MapEntityList ) {
    MapEntityList[i].update()
  }
  if ( Combat == true ) {
    Combat.process()
  }
  for ( i in MapEntityList ) {
    if ( MapEntityList[i].erase == true ) {
      DestroyPerson(MapEntityList[i].personsname)
      MapEntityList.splice(i, 1)
    }
  }
}


altho this is an oversimplification, this is the basic layout of the problematic area. what happens is i get a MapEntityList @ index has no properties bug. so i switched to a regular for loop

Code: [Select]

for ( var i = 0; i >= MapEntityList.length; ++i ) {
  //if, DestroyPerson and .splice here
}


and then the for loop never runs

EDIT: ok i changed it up a bit... its the .splice of an array inside a loop looking at that array right?

Code: [Select]

function NewUpdateScript() {
  for ( i in MapEntityList ) {
    MapEntityList[i].update()
  }
  if ( Combat == true ) {
    Combat.process()
  }
  var cleaning = false
  var cleanindex = 0
  var mapclean = false
  while ( mapclean == false ) {
    for ( i in MapEntityList  ) {
      if ( MapEntityList[i].erase == true ) {
        cleaning = true
        cleanindex = i
        break
      }
    }
    if ( cleaning == true ) {
      DestroyPerson(MapEntityList[cleanindex].p)
      MapEntityList.splice(cleanindex, 1)
      cleaning = false
    } else {
      mapclean = true
    }
}


it seems like way over complicating it, but any other way wont work right?
Title: Re: Maintaining a battle combatants array separately
Post by: Radnen on June 02, 2013, 03:08:54 pm
It's not that complicated to erase an entity from a list, you just need to account for a simple back-track that's all.

Code: (javascript) [Select]

function NewUpdateScript() {
  for (var i = 0; i < MapEntityList.length; i++) {
    MapEntityList[i].update();
    if (MapEntityList[i].erase) {
      DestroyPerson(MapEntityList[i].personsname);
      MapEntityList.splice(i, 1);
      i--; // this is the key!
    }
  }

  if ( Combat ) Combat.process();
}
Title: Re: Maintaining a battle combatants array separately
Post by: ninjasword on June 14, 2013, 08:39:02 pm
ok so weird question time... i have some globals to hold all the pieces of my game: team_array, map_objects_array, ui_objects_array, battle_object and i have this thing this state object (its basically just a wrapper for IsMapEngineRunning()), and this state object sets the focus's of my keyboard/mouse/camera and holds all the cross talk logic...

i was wondering.... can the global arrays and such be put inside the state object? i know in a runtime way they can, but in an organizational way.... which is more so? i said ahead of time it was a weird question so if no one has a 'real' answer i understand.
Title: Re: Maintaining a battle combatants array separately
Post by: Radnen on June 14, 2013, 08:55:05 pm
JavaScript is how you make it.

That said, you don't want to put too much stuff in the global scope. In larger Sphere games I've commonly seen data structures such as Global, Engine, Data, or Game. And then you just tack on all the stuff you want to persist.

Code: (javascript) [Select]

function CreateGlobalData() {
    return {
        map_array: [],
        people_array: [],
        //... etc.
    };
}

var Data = CreateGlobalData();

Abort(Data.map_array);


And then to reset the data just recall CreateGlobalData().
Title: Re: Maintaining a battle combatants array separately
Post by: Flying Jester on June 14, 2013, 09:41:49 pm
While we are talking about global objects and all that...

It's a very good idea to put as many colors as you can into a global object and use CreateColor at startup. Same with images and surfaces, sounds, etc. (although it's more tempting, for me anyway, to put CreateColor calls inline than the others). Your game will run smoother, give the garbage collector an easier time, and use less memory.

You can go even further, too. Make global objects that hold key constants and such, which will help with changing keys for actions and such (especially compared to hardcoding).

It's not that weird of a question, and it's one that anyone who wants to make a game in a freeform engine like Sphere has to face.
Title: Re: Maintaining a battle combatants array separately
Post by: ninjasword on June 14, 2013, 10:16:24 pm

It's a very good idea to put as many colors as you can into a global object and use CreateColor at startup. Same with images and surfaces, sounds, etc.... You can go even further, too. Make global objects that hold key constants and such, which will help with changing keys for actions and such (especially compared to hardcoding).


the first script that my script that RequireScript()s all my scripts requires is colors.js, and i ended up putting a function named after everykey (that my keyboard translates and calls, etc) on any object that i want my keyboard to control, i just set it as the keyboard focus and bam, i have control of a person, which is cool cause i wanted 8 directional movement but 4 directional sprites which the sphere input wasnt letting me do easily, but this other system i found works out great

edit: ps: this::


In larger Sphere games I've commonly seen data structures such as Global, Engine, Data, or Game. And then you just tack on all the stuff you want to persist.


was exactly the key to helping me get more organized ty again
Title: Re: Maintaining a battle combatants array separately
Post by: DaVince on June 15, 2013, 07:52:06 am

While we are talking about global objects and all that...

It's a very good idea to put as many colors as you can into a global object and use CreateColor at startup. Same with images and surfaces, sounds, etc. (although it's more tempting, for me anyway, to put CreateColor calls inline than the others). Your game will run smoother, give the garbage collector an easier time, and use less memory.

Be careful with loading all kinds of music on your game startup. I did that with Pokémon GS/SS (an old, crappy project), and it actually took a *really* long time to start up.

In my opinion, the best thing to have is some kind of resource loading system that you tell to fetch some resource for you. If the resource hasn't been loaded before, it'll load it from file. If it HAS been loaded before, it'll just refer you to the already loaded data.

Colours should be fine on startup, though. :)
Title: Re: Maintaining a battle combatants array separately
Post by: Flying Jester on June 15, 2013, 08:49:22 pm
Good point. Mainly, I'm discouraging loading or creating things inline as much as possible.

I really push for this on colors especially because all those calls can add up pretty quick, and it seems so innocent at the time.

With sounds at least you can ask for it to be streamed, though. Of course, no guarantees about playback latency or (possibly) if the format can be streamed.
Title: Re: Maintaining a battle combatants array separately
Post by: Fat Cerberus on June 16, 2013, 12:33:59 am
I create colors inline in my render methods all the time, haven't seen a performance hit due to that yet, and that includes a bunch of testing with the AMD equivalent of a Celeron.  Most of the performance issues I've had have been related to other things, such as my BattleUnit.getInfo() method, which returns a bunch of data about the battler's current state (remaining HP, realtime stat values, etc.) in an object and I was calling that several times per frame to get info for the turn preview, etc. (since fixed to only rebuild the data object once per CTB cycle).

Anyway, back on topic: caching things like colors can easily bite you in the ass, especially in a case like Specs where I'm constantly tweening stuff, including colors.  Barring primitives, there are no value types in JS, objects are always passed by reference.  Which means if you do something like this:

Code: (javascript) [Select]
lifebar = new LifeBar(boss.maxHP, ColorCache.Green);

// then later on:
// manipulates properties of lifebar.color, which is set to your cached Green color object by the constructor!
lifebar.tweenToColor(ColorCache.Red);

// ...and then somewhere else:
Rectangle(0, 0, 100, 100, ColorCache.Green);


Hey, guess what, now your "green" rectangle inexplicably shows up red instead and you get to try to figure out why!  This kind of thing is the reason why the first rule of optimization is "don't do it".  It's very tempting to be proactive and try to head off performance issues at the pass, but optimization is one case where, to my mind, a reactive strategy is better.  It's often more work, but at least by that point you'll be much more familiar with how the system you're optimizing works so you can avoid causing regressions in the process.
Title: Re: Maintaining a battle combatants array separately
Post by: Harry Bo21 on June 16, 2013, 11:45:47 am
Uh... lets not downplay optimizing just yet. Half my projects only started coming together when I read an article on optimization :) lol
Title: Re: Maintaining a battle combatants array separately
Post by: ninjasword on June 16, 2013, 11:59:34 am
wat article?

i only ask cause last week i was foolish and my game was like 8 scripts, now i realize how much i have to learn and my game is like, 50 scripts of objects
Title: Re: Maintaining a battle combatants array separately
Post by: Harry Bo21 on June 17, 2013, 06:52:03 pm
50?

Whole scripts of objects?

That doesnt sound right...

If found the article through google. "javascript optimisation" or something like that. I had a look when some folk were talking about it. Unfortunatly the old forums are gone...
Title: Re: Maintaining a battle combatants array separately
Post by: Radnen on June 17, 2013, 10:17:42 pm
Blockman has more than 150 script files. Most of them are small though.
Title: Re: Maintaining a battle combatants array separately
Post by: Harry Bo21 on June 18, 2013, 02:48:59 am
still for a beginner to have 50 scripts? How big is the project?
Title: Re: Maintaining a battle combatants array separately
Post by: ninjasword on June 18, 2013, 04:59:18 am
i dont know how big big is. sorry, 50 was an exaggeration. i could prolly have 50 objects but i have like 30 something right now is all. still havent designed half the objects that i will need for content of the first episode tho

edit: clarity

reedit2: is there any limits to inheritance chains in sphere or javascript? or maybe im just chaining too long... a 7th gen object has lost properties that it got at gen 4. strangly tho it keeps them from 5 and 6?

edit to my edit while i was editing: no it was cause i assume the components i put in the prototypes of the early gens dont carry over to the later gens, cause they in the prototypes of the early gens, and not in the later ones!

edit: nvm, u can add components into a prototype, and they will be there, i had hacked a component at gen 4, and thats why it wasnt getting added correctly, i fixed that up and now the Combatant Objects are properly adding the Vector Object's Vector_Component.Movable = {}. science is cool.
Title: Re: Maintaining a battle combatants array separately
Post by: Flying Jester on June 18, 2013, 09:58:21 pm
The answer to how long (at least the spec minimum) an inheritance chain can be for Sphere's javascript probably lies in the EcmaScript 3rd Edition Specification (http://www.ecma-international.org/publications/files/ECMA-ST-ARCH/ECMA-262,%203rd%20edition,%20December%201999.pdf), if it can be found anywhere. I'm not sure there properly is a limit, though, I think you'd have OOM errors before such things happened. You could always test it.
Title: Re: Maintaining a battle combatants array separately
Post by: Radnen on June 19, 2013, 04:51:05 am
8 levels of inheritance is considered an industry maximum. If you go beyond that, you have classified things deeper than an anthropologist having a field day with a time machine.
Title: Re: Maintaining a battle combatants array separately
Post by: ninjasword on June 19, 2013, 08:41:13 am

8 levels of inheritance is considered an industry maximum.


i could shrink it down a little, the 7th gen object is a combatant object so its pretty much at the end of the chain there, not to mention (and i prolly shouldnt do this) the first thing in the chain is just an object that has an extend method built in (for learning the components).

right now tho i am trying to figure out the map layers (i want to render a special hud/ui layer UNDER the map persons. the ui of sphere isnt exactly the most descriptive... im confused as to where the ground layer is, and if its possible to have panoramic/scrolling backgrounds, or if i should drop those layers from my design
Title: Re: Maintaining a battle combatants array separately
Post by: Radnen on June 19, 2013, 02:36:38 pm
To render stuff underneath entities you can use the SetLayerRenderer function.

Code: (javascript) [Select]

function GroundRender()
{
  // ... draw stuff that should go on the ground layer.
}

// set up a ground renderer on layer 0:
SetLayerRenderer(0, "GroundRender();");


It works exactly like a SetRenderScript, expect you can choose a particular layer to draw on.

As for scrolling/parallax layers you can go into the old editor and right click a layer in the layer panel and choose "properties". There you will see an option for scrolling and parallax. My newer editor doesn't have that yet.
Title: Re: Maintaining a battle combatants array separately
Post by: N E O on June 19, 2013, 05:20:37 pm
Yea, I use SetLayerRenderer pretty liberally in my NShoot demo 'Artyxx' ; works pretty well for the scrolling BG.

(edit - clouds overlay! I knew I was forgetting something!)