sleeper_service, that thing looks huge (the events and elevator), thanks for posting it as an example. Something unrelated to the issue at hand but that I want to comment on: the player space ship is moving very smoothly and the boost controls seems natural. I think good controls are very important in a game so I congratulate you on that.
Possibly, though I didnât add platformer behavior to the mustache. I only gave it animations that change the same way the player animations change and told it to follow the playerâs position. Although the player has behaviors added to him, the mustache is only tracking his position and its animations are handled the same way as the playerâs.
Indeed the turrets move out of position a bit, but the displacement is minimal. I donât know how to explain why but it feels right in a space ship game, but not on a character holding items.
Yes, yes yes yes⌠Mea culpa, mea culpa. I shouldâve noticed the descriptions above, but I didnât, sorry.
Thatâs exactly what I did:
But:
Are you suggesting using variables, like:
Do =0 to variable Player_Direction
Do =1 to variable Player_Direction
0 being the player is facing right and 1 player is facing left, and then flip the glasses according to the Player_Direction value? I donât see how that would avoid creating and destroying the objects though, the player should have the freedom to equip/unequip the items, and the only alternative to creating/destroying the items is creating them all at the start of the scene and make them invisible, then change visibility when the player change them.
You can create/show the item when it is equipped and then destroy/hide it once it is unequiped. Since youâll need a framework for that anyways to manage item effects youâll have the conditions at hand. With âlink objectâ you can reference the gear in later vents but that isnât event necessary if gear objects only appear on the player.
Also Iâd probably use one universal object per equipment slot, like âheadgearâ that has animations for every possible head gear in the game and only changes stats and animation per instance on creation. Easier to manage when dealing with large amount of gear. HDog has close to a 150 items but they are all handled through the same three objects.
Since they are evenly spaced down the side of the main craft I wonder if it would make any difference to position them all relative to one point, rather than having lots of points. So have one point for group_mountable 1 and then:
and so on, depending on what the actual vertical spacing is.
By picking precise relative positions it may avoid shifts in the position caused by the points moving just as the position is being set. Presumably, you could also make them all relative to the origin of the main craft.
I agree with sleeper_service that rather than constantly creating and destroying different glasses objects, just have one âglassesâ object and store all the glasses sprites as separate animations within that glasses object. That way the object is created once and then visually altered by stepping through its animations when keys are pressed (or power-ups are collided with).
If one of the animations was completely transparent (such as animation 0) then the object could be there from the start and would seem to be created when you changed to animation 1 and destroyed when you changed back to animation 0.
I think @Lizard-13 already narrowed down the cause of the lag.
Forces are always applied after after events, while âchange positionâ actions are always handled during the events. So object movement cause by forces will always applied after changing the position of attachments. Unless there is a separate âchange object position after forces appliedâ action added, GDevelop will never handle attachments correctly at objects with forces applied. I guess what you described could be done by moving the elevator thing with change position only, but that would hell to get right. Iâm not even sure one could create smooth movement this way and it probably is way less economic than the âadd forceâ actions.
For something quite slow moving, that just moves up and down, changing the Y position âmanuallyâ should still look pretty smooth. You could then move everything (the ship and all the turrets) up/down by a few pixels in one event . You wouldnât even need to use points then.
Yeah but if you want to have anything else than rigid movement you want to have stuff like dampening and aditive/counteracting forces. That stuff is super complex to do with âchange yâ. You couldnât move the elavator as smothly/efficiently as in the gif and the problem doesnât stop there anyways. Usually you want to move objects in all directions and react to obstacles/player behavior and a dozen other things. There is no feasible way HDog could do this with just âchange x/yâ. The whole force system exist to make object movement managable in the first place, but itâll always struggle with managing multi component objects in the current state.
I was testing the proposition of having a single object with multiple animations, and while the concept worked, some weird behavior was observed when using the selection mechanism I set up for the test.
To test the above proposition, I made up 3 armors: Default, Fire and Ice. The variable âArmorIDâ identifies each of them, with the extra number 0 meaning âno armorâ:
The selection works with the events shown below:
(Iâve set the ArmorID to 0 at the beginning of the scene too)
So by pressing w (let us call it the âforward selectionâ button), the number in ArmorID increases by 1 and goes back to 0 if itâs on 3. By pressing q (let us call it the âbackward selectionâ button), the number is decreased by 1 and goes to 3 if itâs on 0. The problem, though, is that it seems to be skipping the number 3 (shown in the gif below), and the forward selection button always sets ArmorID to 0, instead of going through the numbers correctly. To my eyes, the mechanism shown in the events above looks correct, so the problem isnât there. I took a look at the âArmorâ objectâs animations*, and they are also correctly implemented. Afterwards, I checked the player movement events**, and they also appear to be correctly made. Therefore, Iâm completely stuck.
By the way, the number for ArmorID keeps changing for as long as the key is pressed:
Iâve found no action that allows me to stop the pressing of any buttons for a certain amount of time or just delay it. The only way I could come up with were with timers but this method looks so convoluted I doubt itâs the correct way of doings.
This is a classic problem of the âkey being pressedâ condition checking whether the key is being pressed 60 times a second. That means long before you can release the key, GDevelop will have cycled through events 1-4 multiple times, changing the value of ArmorID multiple times too. Which value it has when the text object is updated will vary.
There are two simple solutions:
Use the trigger once condition (found in Advanced)
Test for the release of a key rather than if it is being pressed
Something else you could do just for your own sanity and to cut down the number of events/sub-events is tweak your ArmorID numbers so they match the animation you want. That way instead of having four sub-events for each of moving, jumping, falling etc. you just add one action to their events along the lines of:
Do =Variable.ArmorID to the number of the current animation of Armor
By doing that, GDevelop will always pick the right animation any time you change ArmorID.
If you need a different âArmorâ animation for jumping to moving then just have the correct jumping animation set to always be 4 more than the moving one i.e. ArmorIDs 0,1,2,3 are the moving animations for four different armours; ArmorIDs 4,5,6,7 are the jumping animations for the four armours - and so on.
The jumping event would then have the action:
Do =Variable.ArmorID+4 to the number of the current animation of Armor
This will also simplify your âArmor Selectionâ events as you can get rid of them all and just have:
w key is pressed | Do +1 to variable ArmorID
and
q key is pressed | Do -1 to variable ArmorID
You will also need to add conditions to check that ArmorID<=3 when w is pressed and >=0 when q is pressed to avoid sprites disappearing if you go outside the range.
(the events and elevator), thanks for posting it as an example. Something unrelated to the issue at hand but that I want to comment on: the player space ship is moving very smoothly and the boost controls seems natural. I think good controls are very important in a game so I congratulate you on that.
