Mipey's Forum Posts

  • If objects are too close together, then the condition remains true while mouse moves over objects, as it doesn't actually leave the object type yet.

    But here is an unique property of each object instance: Unique ID - UID. See the code:

    +MouseKeyboard: Mouse is over Sprite

    System Set global variable 'Test' to Sprite.UID

    Sprite Set opacity to 50

    +Sprite: Unique ID is NOT global('Test')

    Sprite Set opacity to 100

    [/code:nwff6iyo]

    Basically, whenever you hover mouse over an object, you change its opacity and store its UID, so it is exempt from the other event, which sets objects with different UID back to original opacity.

  • Or you can compare the sprite position with a map of corners/intersections. When it runs into one of those, it performs the turning event (if available for that spot). Remember that actions should depend on the intersection/corner type, for example in a corner you can't go forward or right, just left or back, so it would contain "Stop if no KeyPressed" and "set angle to 90 if KeyPressed" actions, for example. There are several options for each hotspot.

    But I'm not sure if the sprite won't just zoom past due to frame skipping...

    EDIT: You could simply set it this way... create 1x1 boxes, place them into 'hot spots', add them all to the 'HotSpots' family and then:

     Always
+Sprite.X=HotSpots.X
+Sprite.Y=HotSpots.Y

    Stuff to do at that HotSpot[/code:3d3nd2or]

    So it always checks if the sprite is overlapping any of boxes within the family, then it performs the action such as turning the sprite or simply letting it go if there is way and the key has not been pressed. Handle differently for ghosts (AI) through sub-events.

  • Make your Pac-man a bullet.

    If Pacman is moving to left, pressing right should turn it instantly, pressing up and down should make it turn at the next intersection or corner.

    If Pacman is moving to the right, pressing left should turn it instantly, pressing up and down should make it turn at the next intersection or corner.

    If Pacman is moving up, pressing down should turn it instantly, pressing left and right should make it turn at the next intersection or corner.

    If Pacman is moving down, pressing up should turn it instantly, pressing left and right should make it turn at the next intersection or corner.

    If no keys are pressed when Pacman hits an obstacle (corner, wall), then it would just idle and wait for the input.

    Simple, really. All you need is to make Pacman remember the keystroke until it reaches a turning point, then it makes a turn and forgets the stroke.

    For ghosts, implement a basic bullet AI that decides where to turn on each intersection/corner based on distance from Pacman. You just change the angle, but keep the speed constant. Make sure they can turn in an instant.

    As for corners and intersections, think you'd need to make some sort of detectors. In intersections there is no collision unless you make a detector there. So whenever Pacman or ghosts overlap the detector, the turning event would be initiate.

  • I see, so the issue is with time periods of spawns. Have you checked the timer variables and TimeDelta? Since this stuff was introduced with music, have you tried disabling the music event?

    It is possible that after replays the timers (or loops) are somehow messed up, most likely by referring to a bloated variable.

    Let's assume this order, see if I understood you:

    • First play, everything normal, spawns on 4-5 second, DEATH, prompt for replay.
    • First replay, spawns on 4-5 seconds... on end of this game, you're prompted again.
    • From here on, things start misbehaving, long spawns but FPS is fine

    What is the difference between first and subsequent replays? The first one is CLEAN, it came straight from the first game. Others followed a replay. Following that train of thought, hopefully you can figure the error out.

  • Check if you're not duplicating anything on "Play Again?". You have to clean the old game objects up. The slowdown hints to a large number of objects being processed, even if it doesn't look like that.

  • Awesome! I figure I could achieve anything I wanted with the described abilities.

    Don't forget Z-level changes while moving! With it one could create quasi-3D movement.

  • For example I'm going to use hashtables for each entity, if a number of entities gets into hundreds, I imagine simply saving hashtables would result in hundreds of small files. Not good. So I was thinking I could dump them into the ZIP.

    On another thought, I guess there is no point of removing a specific file at all if I'm just using this to save and load the game. Either load all or don't load at all. Dynamic file structure - such as some sort of database - would probably be better off with something other than the ZIP due to the performance hit.

    Thanks!

    Edit: Funny thing, I was experiencing a crash on closing the application until I removed the ZIP object. All I could get was runtime error popup, which disappeared too quickly.

  • From what I have garnered from object information of the ZIP, a couple useful features are missing:

    • remove a file (it supports adding, but not removing files from the archive)
    • password protection (so that nobody but the executable can access the zip)

    A couple trivial things, but they would greatly expand the practical uses of ZIP object, such as an use as save file.

  • But what if you store values externally, say, from a hashtable, which is in a container with the sprite? Would the proper sprites be picked up by checking for hashtable key value?

    As you can see, I used exactly that in the above example and it behaved funny if I picked families by contained hashtable values.

    I want to use hashtable as I will need a dynamic table of variables, while there can be only a fixed number of PVs. Well, I could put numerous values into PVs as concatenated strings, but that'd make things unnecessarily complex (i.e. using Find() to locate the exact string in PV for each object would take more CPU time than just reading hashtable value).

    Oh gee, am I complicating too much? I just want a sprite or some sort of object that represents a RPG character/NPC/enemy with lots of variables of varying amount... the system has to be very robust, if I get bugs like my huge male barbarian suddenly becomes a female gnome witch... well... that'd be fun, actually.

  • I see, makes sense now. I need to clear this up (among other things) before I attempt a real project, so I am making weird stuff like this to see how it works.

    If I got it right, if I want to change a specific sprite, I should pick it singularly instead of the family, but where I need to address a number of sprites, I should use a family instead?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Okay, I have attached a demo, which uses contained sprites and hashtables. By right clicking them, the hashtable value is incremented by one.

    At 1 click the sprite turns green, next click it reverts to yellow. At 5 clicks it is destroyed.

    Now, click around a bit and you might notice a funny behavior... Like, sprites start rebelling and changing color when they should not or even get destroyed en masse.

    What gives? Is it a bug? If so, I'd like to pinpoint it down before submitting a report. If it is just sloppy programming on my part, I'd like to have the flaw pointed out.

    Thanks!

  • All this can be dumped into its own event sheet and then pushed aside to be included in any layouts where necessary. A simple way to execute actions linked to buttons would be with a function call.

    MouseKeyboard: On Left Either single or double clicked on Blue

    FunctionCall function Blue('MenuItem') (and Forget picked objects)[/code:2f5tekex]

    As you can see, this calls a function with name taken from the menu button variable. The function can be stored anywhere, best on the layout event where menu was generated (assuming the button clicked has "exit" stored within MenuItem variable):

    Function: On function "exit"

    System Close application[/code:2f5tekex]

    That is all it takes. And when you need to disable the menu after clicking a button, just set the global variable 'MenuToggle' to 0 within the called function. Poof, menu gone. Hooray for clean code (at least within the layout sheets)!

  • As long as menu operations don't make use of timedelta!

  • I use web space on Google Pages, I just upload stuff and link it there. 100 MB space, which is more than enough for my needs. They have locked signups, though, as they're developing Google Sites, which will have more features.

    Should my creations gain in size in a way Google wouldn't satisfy me anymore, it would be time to get professional, heh.

  • This demo shows how a dynamic menu can be created using a hashtable. The hashtable contains menu items (such as Start Game, Load Game, Save Game, Exit Game etc.), which are read and used to build the menu with. The menu automatically expands and adds necessary amount of buttons as well as set them up to work with.

    All this can be done in runtime; just change the hashtable entries. See the demo here:

    Menu Demo cap

    I am open for alternatives and optimization tips.

    Bug: Also, in this demo the debugger bug is apparent. Run in debug mode, open and close menu, in the instances list in debugger the MenuButton shows as 0 instances, but it contains entries. Clicking one of them will cause a crash. MenuButton is a container object, contained with MenuButtonText, and is destroyed when MenuButtonText is destroyed. Debugger doesn't seem to register this and so refers to non-existing isntances.