Jaycephus's Recent Forum Activity

  • I meant to add that there is more than one way to accomplish the same thing, and a 'class object' approach, where there is something like a 'struct' plug-in, and we would just create as many instances as we need is fine as long as the above functionality is included. With instances, as opposed to an array, you can create and destroy however many you need in a given time-frame, optimizing memory usage. But this plugin would need to create instances of other definitions in order to duplicate the structure within a structure hierarchy.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • Did a search, and this appears to be the most recent post on the subject.

    I am missing this kind of functionality.

    Specifically, I would like to see a 'user-defined data type' or what is called a structure or 'struct' in C:

    psuedo code of no particular language:

    structure coord{

       x : number;

       y : number;

    };

    structure Enemy{

       ID : number;

       coord : coord; // <-- uses the struct defined above.

       onscreen : boolean;

       damaged : boolean;

       name : text;

       attack : number = 1;

       defense : number = 1;

       weaponModules : array[0..10] of hardpoints; //<-- an array of a struct.

    };   

    Enemies : array[1..100] of Enemy; //<-- an array of the Enemy structure.

    With this kind of structure, the code is a little better at self-documenting, as opposed to using plain arrays. For example:

    Accessing Enemies.weaponModules[j].hitpoints is far more readable than something like aEnemyWeaponModules[i,j,4], where you have to leave yourself a note that Z-index 4 is 'hitpoints'. And you have to know how you are associating separate arrays that contain all the Enemy parameters, or else the documentation load gets worse and the code gets more cryptic if you are cramming everything into one array called aEnemies(x,y,z)

    For all intents and purposes, it is a record with fields, as in a data base, with fields consisting of one or any of the base types of the language, which for C2 is essentially a 'number', boolean, or string (text). But it also can contain another struct as one of it's defined fields, and it can define an array of any of the three C2 base types or any previously defined structures. So you could have a hierarchy of structures, where potentially, only the lowest levels of the hierarchy actually contain base types.

    For now, if I just want an instance of this kind of record, or want several instances to act as a table of records, then creating instance variables within an Array will be the closest I can come, I believe, with the exception that it can't create an array of instance variables (i.e., sub-arrays), nor can it create an instance variable, or 'field' of a type other than number, Boolean, or text. That, and the instances can't quite be referenced like an array, though C2 does provide good ways to pick specific instances or process all or a subset of instances, so maybe that is not an issue really.

    Then to realize the full benefit, I would want to be able to write a function that takes as an input parameter (or input/output parameter, or typically called a by-ref parameter in some languages) one of these structures.

    Of course, the structure concept and XML mesh well together, so you could have the XML plugin write a structure out to XML, or read an XML file into a structure, facilitating saving and loading save-games or game-options, or other persistent data.

  • Kyatric, still 'digesting' the capx. It looks like I'm going to get a lot of learning out of it. Thank you.

    I see that you are a supporter of Spriter. Do you think spriter would benefit a simple RTS? Obviously, some kind of cut-scene animation might make good use of it, as I understand it. But what about an RTS-style game that 'just' has animated buildings and units?

  • Thanks. I'll check this out later today.

    Yes, that was one thing I was wondering about, if families should be used. No manual update on families yet.

  • I have a beginning project built for an RTS. It is a scrollable, zoomable background with main and GUI layers, and includes a clickable mini-map.

    So just consider that this project will be a simple form of tower defense. The scroll and zoom aren't really required at this point.

    Consider player objects are fixed. These would initially just be a tower-type of object. (A GUI for placing those, and additional variety can come later and is not really in the scope of this example, at least not yet.) For now, let's just do whatever is easiest, such as pre-create those programmatically. Need to spawn enemies as well, which move toward target (center of map). Assume that enemies are 'fliers', so they move without need for complex path-finding for now. Player base is at center of map. A consideration is that enemies would be created in waves, but I'm not sure that is really a big factor in the structure of tracking and handling them, only in the initial spawning of them. So that might be out of the scope of this example too.

    I would like to be able to easily increase and extend the types of player and enemy objects as development continues.

    I figure this is a fairly simple learning project, but useful for the style of game I am trying to create.

    (I'd also like to put the whole experience of this learning project into a tutorial series, since I would like to encourage others to come up with some good RTS games.)

    Thanks

  • Certainly. :)

    It's not so much the counts involved, but the structure you would use to handle more than a handful of objects.

    Thank you

  • Is there a good example of a game that has a lot of onscreen enemies, and other objects such as bullets and/or missiles fired from these enemies, player objects, and checking or tracking of missiles to targets, bullet-collision, etc?

    I want to see how to structure such a game within C2.

    Thanks

  • Thanks very much for the reply. Appreciate it!

  • Right now, I'm using a plain sprite rectangle to indicate the viewport on the minimap, resizing depending on zoom level.

    But I'm also curious about whether 'drawing' a lot of enemies, bullets, missiles, etc, is better than using pixel sprites instead.

  • In C2, what is the best way to display a resizable rectangle? With this plugin?

    Or just make a square sprite and change its dimensions?

    Or is it about the same in terms of memory/speed for a 1-50 instances?

    One thing I want to do is make a view-port rectangle in a minimap.

    (A one-pixel un-filled rectangle would work. Or I could draw a rectangular sprite, resized on the fly, to represent the same thing.)

    Thanks

  • There are actually two issues described above:

    Yes, when Unbounded Scrolling is set to YES, the event handling on my side I JUST now discovered, is at fault. (rookie Construct mistake, I know: missing the Else-ness in my logic.)

    However, the behavior when Unbounded Scrolling is set to NO is seemingly completely messed up when zoomed in at about scaling less than .5 in my app. (Try the newly edited capx with Unbounded Scrolling set to YES, then set it to NO and scroll 'down'/zoom in to observe this.) So even though the current code never sets ScrollX & ScrollY out-of-bounds while dragging due to the above bounds checking, the auto-bounds setting seems to be erroneously forcing the viewport well out-of-bounds when zoomed all the way in (scaling of 0.1).

    http://dl.dropbox.com/u/67882392/MyRTS%20zoom-pan.capx

  • I'm pretty sure the exact same behavior was present in r81, especially the auto-bounds when zoomed in problem. But testing today was on r82. I tried this on Vista 64 and Win7 64, both times in a Chrome browser, both with r82. I believe that the Win7 system has the latest 32-bit Java for running Processing.js in Chrome.

Jaycephus's avatar

Jaycephus

Member since 14 Mar, 2012

None one is following Jaycephus yet!

Trophy Case

  • 12-Year Club
  • Email Verified

Progress

13/44
How to earn trophies