Author Topic: All sprites predefined  (Read 3532 times)

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
All sprites predefined
« on: 2007-03-29, 11:59:38 AM »
I must admit, I am still a little confused about the necessity to have all sprites predefined, even those that are short-lived, and may have many on the map at the same time, such as bullets, or explosions, or a moving particle-like effect created with many different sprites being "emitted" from one point.

In cases such as this, where one doesn't really need to reference individual sprites by name, but rather by sprite base type or by sprite groups, it doesn't seem like it should be necessary to individually place each sprite on each map beforehand (imagine if you had a machine gun that you could use on each of 10 levels!).  Do you think there could be a function to spawn new sprites rather than activate existing ones, placing them into the correct sprite groups when doing so?
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: All sprites predefined
« Reply #1 on: 2007-03-29, 06:06:05 PM »
I suppose it would be worth a try to support this.  It may be possible to do something like this by customizing the code in a project, but it's useful enough that it should probably also be a standard feature.  I think the idea was that I didn't want to start making rules that started relying on these dynamic sprites.  I wanted to make sure that you always had the option of referring to sprites by name, and doing anything possible with any rule to them.  If I hadn't made that rule, the "ActivateSpriteAtTile" rule (or whatever its called) might have been implemented in a way that couldn't handle named sprites.  But now that I've worked that out, maybe I can go back and review this so that named sprites can still do anything, but then you can create temporary/dynamic sprites too for certain cases where you don't care about tracking them too specifically.

What would you think about dynamic sprites having to be in a different kind of category.  Would it be a problem if named sprites and dynamic sprites couldn't be in the same category (collection)?  I'm not sure if that'll be necessary, but in case that makes it easier in the implementation, I'm wondering if you see any problem with that.

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: All sprites predefined
« Reply #2 on: 2007-03-29, 10:01:24 PM »
The way TileActivateSprite works, as I understand, doesn't actually use sprite names, but rather sprite categories, and activates the next one in the list (looking at code confirms this).

I don't see any particular problem (right now) with dynamic sprites being in a different category, except if you want to affect both static and dynamic sprites in a similar way, you'd have to do it in two steps.  The upside of this is that you could simply define a specific dynamic sprite definition and have it automatically create a dynamic sprite collection of the same name, so you could have a sure-fire way of accessing all and only those sprites, without having to go through the work of creating an extra sprite collection in the project, and the naming would be simple.

Speaking of naming, why is it that rule names have to be unique?  Couldn't the Unique ID be the order?  Also, I noticed when looking at the .SGDK2 file that the rules aren't sorted by order.  I did some copy/pasting to quickly make copies of similar rules directly, which works for the most part, except they weren't in order, so I had to put them in order before copying.  I'm not suggesting that you need to sort them in the .SGDK2 file (though it would make sense to do so), but maybe you should have an easy way to duplicate rules, and get rid of the necessity of having all rules be uniquely named.  Mostly, I can come up with a different name for each rule, but it becomes tedious to have to do so for a bunch of different but similar rules.

This post seems to have gone off on a tangent.  Oh well.
Edward Dassmesser

bluemonkmn

  • SGDK Author
  • Administrator
  • Fanatic
  • *****
  • Posts: 2761
    • ICQ Messenger - 2678251
    • MSN Messenger - BlueMonkMN@gmail.com
    • View Profile
    • http://sgdk2.sf.net/
    • Email
Re: All sprites predefined
« Reply #3 on: 2007-04-02, 02:14:51 PM »
Mostly the original reason rule names work the way they do is because it seems like the easiest way to ensure correct operation/linkage when tracking a rule in the treeview, the project and the rule fields.  None of them provide very good/easy access to the sequence index of the rule, but they all know about the name.  I have realized, however, that the uniqueness constraint can be a bit of a pain at times.  But I think it's also a handy feature for communicating among team members or via documentation about a particular rule; when you know the names have to be unique within a context, you can just refer to the rule by name and know that the reader will find the right rule.  Maybe I'm trying to re-use the same property (name) for too many purposes (the name also becomes the comment above the rule in the generated code), but any alternative seems like unnecessary overhead.  One way to get uniqueness would be to simply prepend a number to each rule name, but of course I wouldn't want to enforce that.  So it's up to the user how they want to uniquely identify their rules and all the program requires is that they be unique.  If I were to use another perhaps weak excuse, it would come from this example:  Assume you're editing a rule named "Jump" and you have two jump rules in the rule tree on the left -- one for when the player has a high-jump ability and when for when they don't.  If you happen to forget which one you were working on (maybe you went and had dinner in the middle of updating your rule) then it might be hard to tell which instance of the rule you're working on without re-loading the rule.  I wonder if your UI design class will say anything about this, like "Always show some visible unique keys because the user needs to be able to distinguish objects just as much as the computer does." :)

durnurd

  • Lead Lemming
  • Expert
  • Fanatic
  • *****
  • Posts: 1234
  • Games completed so far: 0
    • MSN Messenger - durnurd@hotmail.com
    • View Profile
    • Find My Ed
Re: All sprites predefined
« Reply #4 on: 2007-04-02, 04:02:51 PM »
I think in that case, I would use different names, or it would be obvious to me which rule I was editing, based on previous statements ("If player has high jump: Else:").  For other things, however, where you may be executing the exact same rule, for example, it may not make a difference at all.  Perhaps the tree view could show the number before the name, or the number could be shown somewhere when the rule is selected, like in a status bar or in the rule editing frame, so that it is distinguishable for different users communicating about it.

Speaking of the tree view, I still find the indentation somewhat confusing.  It would seem to me to be a good idea to follow indentation styles similar to the code itself.  That is, else statements are outdented, so code in the IF and code in the ELSE are both at the same level of indentation.  Also, rules of type AND or OR would be at the same level as the IF statement, or indented to the next level, then all of the DO statements are indented an additional level after the entirety of the IF statement (including ANDs and ORs).  Then the ELSE statement would be outdented two levels from the end of the last DO statement (or END).  This would be much more understandable from my point of view, and easier to see the flow of code without having to expand every tree node to see where all the ELSE code is and what it does.
Edward Dassmesser