Candescence's Forum Posts

  • This might seem a tad complicated, and I'm not sure if there's actually a way to do this already, but let's see:

    Considering families are akin to classes in traditional programming, when working with classes, not only can you create singular objects, you can also create arrays of them, or lists. Each object in an array/list has its own named methods/functions and variables, and the array/list can then be modified and sorted, and interact with other objects/lists of the same class.

    However, to my knowledge, C2 lacks similar functionality. To get a better idea of what I'm asking for, let's look at an example, from, say, an RPG with any number of possible party members, such as Pokemon:

    • Say you have a 'List' object that has to be associated with a Family. The Family, and by extension, the List, describes Party Members, with all their relevant variables, such as their name, stats like HP, attack power, etc, stuff like equipment, EXP, level, and so on.
    • During play, each object's variables can be accessed by name, rather than the designer having to remember which index number is associated with a variable like they would an array. As well, objects can be deleted from a List, the List can be sorted by a specific variable with limited hassle, and an object can be transferred to another List, like, say, you want to put a party member in 'storage' and swap them for someone else.
    • In-game, each object in a list can be associated with a visible object in-game via events that graphically represents the party members.

    This would also do wonders for stuff like inventories, for example. I imagine there's some things I'm missing from this that would make List objects even better, but I think I've gotten my overall point across. Arrays and Dictionaries are neat, but they do have their limitations.

  • Awesome, nice to know you're gonna address that issue. And... Holy cow, those animations are amazing.

    Also, lucid, there's another suggestion I'd like to make, mainly for Spriter in general - a 'prototype' animation art pack. Nothing complicated, just an animation set with a detail-less manikin or crash test dummy, for 'prototype' animations for game testing, basically. Just something usable, it doesn't even really have to be good looking as long as people can use it :p

  • Hey, Lucid, when it comes to Spriter objects 'attached' to another object, I've noticed that the Spriter object still experiences some nasty 'drift' when the object it's attached to is moving, such as with a platform movement. This is actually kind of an issue, and while it's mainly a visual issue, it's still an issue that I'd really like to see fixed.

    Example .capx

  • — Yeah, as I mentioned, I'm heavily considering splitting the character-specific events into two sections each - the 'general' events that don't need to be in the For Each loop, and the control-based events that require the loop in order to distinguish between players.

  • — I'm mainly talking about stuff like animation triggers for the platform behaviour (On Stopped, On Landed, etc.), though in hindsight, most of that stuff might be able to work in a separate group outside of the "For Each" loop(s), as they generally don't come into contact with the control-related events that need to be in the loop.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • This is something I've had to tear down to its most basic elements in order to strip out all the fat from my experimental stuff, and I want some help on making this work.

    What I'm trying to make is basically:

    • Multi-purpose platform engine that can support any number of gameplay styles
    • Can support both custom controls and AI control
    • Supports multiplayer

    How I have it set up so far:

    • Two families, "PlayerAI_Platformer" and "Platformer_Skins", to handle both the actual player objects and 'skins' representing actual characters. The former contains general variables that usually apply to most characters.
    • Four objects for each player:

    -- The "Plat_Stats_General" object, which is the 'base' Player object, storing variables that are more 'universal', such as health, money, etc. This always persists for any given player.

    -- The "InputPlayer" object, which is contained in the object above, which handles the input for that specific player with a large set of variables. Is persistent.

    -- The "platforming" object, which handles all the platforming for a given character. Contains the relevant character 'skin', and character-specific variables. Can be destroyed to be swapped out for another character.

    -- The character 'skin'.

    Now, the main problem I'm having right now is that the only way I can get the separate players to respond only to their respective controls is to use 'For Each' loops. Problem is, the loops prevent me from using triggers as sub-events, and believe me, there's a lot of triggers involved in creating a fully-functioning character. But using picking conditions doesn't seem to be nearly enough, unless I'm somehow doing it wrong. Is there a better way I should be going about all this?

    *Cap link removed for the time being*

  • This looks great, but I'd like to see these features:

    * Shadows that aren't completely black

    * Coloured lights

    * 'Textured' lights (like in Mark of the Ninja)

    * Light Cones

    Get those working, and this'll be perfect. I wouldn't mind also being able to detect whether an object is 'lit' or covered by a shadow, for stuff like stealth games.

  • Well, looking at the engine itself, it's a "tile-based" engine, but the number of objects on-screen that need to be checked at any one time isn't much. The player object has a set of 16 sensors (which are required for operations that overlap offset isn't appropriate for). It's not that many, but I'm still seeing the number of collision checks in the realm of nearly 2 million per second, which is kinda insane.

    Besides, I did a re-examination of the debug results, and it provided an eye-opener. The events that take up the most CPU are the movement routines, which totals around 35% CPU use out of 45%, and considering it's a basic test level and it's still causing a lot of slowdown, that's not good at all. I think the way the engine itself is set up is incredibly inefficient, which is surprising, considering it's a port of a similar engine from Classic, which ran fine.

    In short, I suspect that I'll need to find another implementation if I want to do a Sonic engine... Or just have someone write up a javascript behaviour. XD

  • From what I can tell, the 'every 0.1 seconds' method mostly breaks the engine completely. To be more specific, the engine is a pure event-based Sonic-style platform engine, and the collision checks are for a set of collision 'sensors' checking for overlapping with terrain objects. The engine itself uses a lot of functions for collision checking. The engine itself is about a year old, but it still works fine, aside from being seriously unoptimized to hell and back.

    So, yeah, using the 'every x seconds' condition doesn't work, and the other tips aren't really applicable here, which is why I was mainly asking for a distance-based method, since it would massively cut down the number of objects that would need to be checked at one time.

    Nobody said making a Sonic engine was easy :p but thanks for the tips.

  • Okay, that's some very impressive stuff. You plan on sharing the code for it? Because this would be very handy to have available.

  • I went and revisited an old engine I was once working on but abandoned because it was ridiculously slow, and what I found via the debugger was, that, as I suspected originally, the number of collision checks were though the roof (due to the engine's need for multiple detectors).

    Now, the question is, are there any methods for cutting that down to size? I was thinking of using a distance check to determine if a solid object is close enough to the player to actually be worth checking, because there's no point trying to check for a collision with an object that's ten-thousand pixels away or something, but I can't quite figure out how to do that.

  • Of course, the logistics of this whole thing are going to be interesting, to say the least. I'm assuming that testing a C2-made Wii U would require a dev kit, which, unfortunately, can be somewhat expensive, though I imagine there might be ways around that, considering the type of stuff we're working with. Actually providing dev kit functionality to normal Wii Us runs the risk of exposing exploits for hackers, which Nintendo does not want, though I am personally a supporter of the homebrew scene.

    Still, I really do hope we'll be able to test C2 games without having to get a dev kit just to do it.

  • It is interesting to look at. I know an XML-based system would admittedly be somewhat trickier to implement, but it's still based on a single image, but rather than in a uniform grid, the characters are packed together and split via information retrieved from the XML. I'd honestly say that using a format generated by, say, ShoeBox, for example, would be easier to fit within a power of two image without actually needing to fiddle with fitting all the characters into a suitably sized grid.

    I'd really like to be able to use something like this without needing to go to all the trouble of assembling it into a grid manually:

    <img src="http://opengameart.org/sites/default/files/boxy_bold_font_4_0.png" border="0">

  • Have you tried the tool here?

    http://www.scirra.com/forum/sprite-font-generator_topic72160_page1.html

    Also it seems like the only benefit from using what you suggested is those pre-made fonts. That's fine and all, but don't you loose the ability to edit them graphically?

    I haven't used that tool yet, but it's not really what I want either.

    And no, you don't really lose that ability to edit them, all you really need to do is throw the modified bitmap font image into ShoeBox to create a new .fnt/.xml file. Not exactly rocket science.

  • Honestly, I'm gonna have to put this out here: the sprite font plugin as it is, quite honestly, quite tedious to work with in order to get the bitmap font set up in the first place. It mainly has to do with how the sprite font files are formatted.

    Nobody makes sprite fonts in a uniform grid. No-one at all. And quite frankly, there's a good reason they don't. There are already standard formats for bitmap/sprite fonts, one notable one being Angelcode's Bitmap Font Generator format, .fnt, which is supported by multiple notable engines already, and it can also be generated in an XML format. ShoeBox can also generate bitmap font files for fonts hand-made in image programs, as well, and can also generate it in XML.

    And then there's some bitmap fonts out there that use the format used by the Bitmap Font Writer.

    I really do think sprite fonts are great, but the problem is, the way the plugin is set up right now just makes it far too tedious to actually set up a sprite font properly, especially with the knowledge that there are far easier methods of achieving the same result.