Function calls another func which returns value into func

0 favourites
From the Asset Store
Game "Little Dino Adventure Returns" with complete Source-Code (Construct3 / .c3p) + HTML5 Exported.
  • Point 1 is irrelevant. For a 0.5 second wait to become 2.0 seconds, the game will be lagging to hell. And no matter what kind of method is in place to schedule events, everything will be a complete mess.

    All others points become moot using the example I provided.

    However, I am also an advocate of the "no wait action" philosophy. Timers are incredibly more versatile and easier to manage. They are basically deferred functions that use instance variables as parameter.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Thank you for taking me serious independed of my childish English. I cant do better.

    First off, its not important if your english (or whatever language you write) is correct or not (my english isnt better at all.. <img src="{SMILIES_PATH}/icon_e_biggrin.gif" alt=":-D" title="Very Happy">), the context of what you are writing about is - and yours is! <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";-)" title="Wink">

    Indeed, your points are right. I just tested it out a bit, playing arround (the player now auto-attacks in 3 second intervalls, the enemy attacks with the same function in 0.5s intervalls). The "animations" are looking fine, also the GUI (after pressing attack, the attack-buttons are faded out (and will be faded in back again when cooldown=0)).

    Arent wait timers frame indipendend? Normally they should not be affected by framerates in generell. For every kinds of movements Im going to use dt. There shouldnt be *that* many particles (if realizable, Im going to make a little benchmark on the first start, getting the cpu usage/framerate while showing a few particles; then the game should set up correctly itself for having the best gfx/framerate option... gonna make a "graphic" option menu where the player can adjust things like max. particles shown or particle-quality in general for choosing his best experience ingame) because its aimed for mobile devices. Testing this will become a bit hard, because I got a nvidia shield k1 which doesnt represent the hardware on Android in general (and a Lumia 640, which is also not that interesting for the most users).

    Back to topic:

    Yes, you are right about what you say on timers/wait-actions. But while testing I didnt encountered any problem with that. At first Im doing the PvE version - PvP is part of a far future for this project (when its about doing the PvP part Ill do a server/client version... PvP games are hotspots for hackers, so the client will only be there for sending requests to the server/backend which does everything when it comes to calculate, displaying health, etc.; the client will only be there for the "visuals" - but thats another point which isnt worth mentioning here.

    Heres a "demo" of the current state (sorry for the very rudimental graphics.. how I said, first I need the core-system, then Ill go for gui, graphics and the stuff that makes fun.. gfx used are from Kenney, if one wants to know: http://kenney.nl/projects/kenney-game-assets-2), enemy attacks in 1.5s intervalls. To attack, just press the light-green-button (bottom left of the gui above the right player character):

    (to /2: while testing I didnt encountered problems, as already said)

    http://proxy.wtf/construct2/combat_system_test_timers/

    to 4/

    As the "wait" time is influenced by the attack-speed which is calculated out of your stats, I (at least hopefully) think, that the "unpersonal" scenario will not hit onto this. Ill also have no collisions (sprite collisions); I plan to include hitboxes. Since there wont be a "dodge" action, I dont have worries about that point. When player/enemy is killed, im going to deactivate the groups which are responsable for initiating attacks.

    Ive also tested "signals" and waiting for them, but that would extent the code pretty much, thats why Ive chosen the wait action.

    Sorry for that wall of text <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";-)" title="Wink">

    Have a great day,

    Proxy

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)