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()

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.

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?

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();
}

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.

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().

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.

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

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.

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.

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.

Uh... lets not downplay optimizing just yet. Half my projects only started coming together when I read an article on optimization lol

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

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...

Blockman has more than 150 script files. Most of them are small though.