Refeuh's Forum Posts

  • I haven't tried this example directly, but yes, something along this line should work !

    Note that if you have entities with "follow"-like behaviours, there's always a risk of the player aggro-ing the entire map, at which point you're back to square one, with the entire world being alive at the same time chasing the player, thus crippling performance.

    Which is why most of the time trigger areas are more reliable and robust ; you can activate but also de-activate certain entities when you enter/leave their area.

  • Do you use a browser or test environment/platform that supports webgl ? Does the hardware you're testing this on support shaders ?

  • I think you're misunderstanding how conditions work ; check how using conditions picks instances and progressively filter "down" the set of entities :

    scirra.com/manual/75/how-events-work

    If you've already filtered some instances with previous conditions, you cannot pick them again in a subevent. There are functionalities to control or reset the picking, or manually scan instances (for each, etc.)

  • It stills means that one sprite (Slot) cannot verify both conditions at the same time and the picking always returns an empty set, I think ; try using the picking to select one set of sprites first, then reset the picking, select the other set, and check for overlap, maybe ?

  • How could you have animations i2 and i31 both playing at the same time ? Unless I misunderstand the logic, there might a flaw in the condition itself

  • Not really, but you don't want to go too "over the top", as it might cripple performance on lower specs machine, especially if you're targeting mobile devices or platforms that don't have great HTML5 support. Also be aware that most app shops where you can publish your game have fairly low size limits (e.g. 50mb) which you could easily exceed if you're exporting lots of high-res frames.

    If you want high-res sprites with lots of animations while minimising asset sizes, have a look at Spriter ; it lets you animate sprite elements using a keyframing system

  • Hi !

    Vector graphics just won't work for runtime applications like games ; the hardware works with textures and vertex/pixel/geometry processing units, that's about it, basically GPUs don't "understand" the shapes used to describe objects built in vector format, i.e. contours/splines/formulas.

    Unless you want to ignore all hardware acceleration and create a custom vector-based engine, in which case performance is likely to become a problem, rasterisation is inevitable.

    Nevertheless, there's no reason your resources should become excessively pixelated ; have you tried simply exporting at a higher resolution ? It costs a bit of memory and disk space, but the performance is still good.

  • If I am not mistaken, when you create an object with System>Create Object, the picking for the current event/action block is set to the newly created object. Therefore you should be able to do whatever you want with the new object right after it's been created, in the same block.

    Though it doesn't really solve your problem

  • [quote:14y9jiye]Weeks of work down the drain

    While this is very unfortunate and never desirable, I must say this is also terrible working practices. I understand the bitterness, it's never fun losing hard work, but not having regular backups or reliable versionning in place is bound to cause major issues ; if it's not a feature not behaving as expected breaking the game, it will be user mistake, or hardware failure, or whatever that can happen and cannot be undone easily.

    This could have been easily prevented, and I urge developers working on "serious" "amateur/indie" games not using a versionning system to take some time to reconsider their workflow, development pipeline and production processes.

    There's a whole range of solutions suitable for all types of situations, depending on the complexity of the requirements, and with very little overhead

    Working on your own and just need regular remote backups ? > daily exports to dropbox, or similar

    Working on your own and just need file history ? > local SVN (e.g. TortoiseSVN) or Git

    Working on your own but want remote history, or working in a team ? > SVN + host provider or Git + host provider

    To minimise the risks (hardware failure, natural disaster, theft, etc.) ideally you'd want your project to be hosted remotely. I strongly recommend something like BitBucket + SmartGit, which ticks all the boxes and is very affordable for small teams, or even free for non-commercial developments.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There's nothing wrong with having large layouts, as long as there is something to manage the entities so that you're not running the entire world all the time ; sprites not on screen still consume CPU time to perform their computations for behaviours, logic, collisions, etc. if these are enabled.

    For large levels, you'll want most entities in a "dormant" state, that you activate only when necessary on triggers, or create them as they're about to enter the screen via invisible spawners.

    Also, you should be able to test some of that locally, even on a powerful machine, by disabling hardware support, slowing down your CPU, or running CPU-prefkillers that are sometimes used for emulating old software

  • I understood everywhere it would be best to use power-of-two-sized images

    Indeed, but the power-of-two thing (non-necessarily square, btw) applies to whole textures, i.e. as loaded in the video memory ; due to data alignment and hardware architectures, these textures are faster to process.

    When putting smaller textures/sprites into larger atlases (or spritesheets), the source size doesn't matter much, as long as the batching tool is smart enough to minimise wasted space and still produce power-of-two output sheets.

    Actually sprites in a sprite sheets don't have to be aligned to anything at all, as long as textures coordinates match. Some atlasing tools are able to generate non-uniform grids, i.e. mixing sprites of different sizes efficiently.

    It would be nice with C2 to at least be able to disable the 1px gap when using point sampling.

  • Without the 1px gap, resources batched together into sprite sheets would "bleed" when displayed on screen due to linear (or better) filtering on texture reads. We don't want sprites next to each other to mutually influence their colours around the borders.

  • Alternatively, you call also call level-specific functions by building the function's name dynamically using the current layout's name and some naming convention.

    Insert a few of these at key points of the event logic (layout start, layout end, player dead, enemies dead, etc.) and you have a fairly flexible system. You can fill in the bits for levels that require it

  • Personally I'm going for a hybrid system where I'm putting everything that can be shared into a single event sheet that deals with as much as possible (solo setup, multiplayer coop setup, entity logic, spawners, triggers, gameplay, etc.) with settings to be specified by each scene, and a callback-like mechanism for scene-specific events

    Each individual layout logic becomes very simple and looks like :

    • apply scene settings (scrolling speed, gameplay flags, etc.)
    • include the generic event sheet
    • deal with function triggers, e.g. "on PlayerDied()", "on EnemiesDestroyed()", etc. that are called by the generic sheet

    This requires abstracting the structure of each scene and making it follow a similar-ish pattern

  • [quote:yhs8f2x2]I deleated all behaviors of the match 3 objects

    I have add events that makes the match 3 objects falling down

    That's pretty much it !

    Basically, for such a constrained layout, you don't want to rely on complex behaviours ; these are good for platformers, top-down shooters, physics objects where you need the collisions when you can't predict the outcome, etc. but here you'd fight the behaviours to make them do what they're not really good at.

    Also, you don't even need the collisions for clicking objects, you can just use "on mouse click" + "if mouse overlap" > action. Actually maybe a "draggable" behaviours would be better, depending on your game.

    Anyway, don't use any platform or physics or anything. You can for example have a representation of your grid/board in a 2D array, and run logic on the data in the array to detect when symbols are aligned, when there are holes and other blocks need to move, etc. Then the game you present to the user just becomes a visualisation of the data in the array.

    At first, don't bother with sliding symbols, etc. just do simple straight cell swaps on a timer (i.e. symbols instantly "teleport" to the next empty cell when moving down). When you've got that working, you can add some variables and basic math logic to make the symbols "slide"

    A Match-3 game can sound simple, but unfortunately with WYSIWYG tools like C2 the built-in behaviour don't help you that much. You can achieve a clean nice result but implementing basic logic yourself.