Naurgalen's Forum Posts

  • 9 posts

  • I really like some of the ideas and it really seems to be fun to play BUT I have 3 graphic problems that totally break the game for me:

    1) As others said its not an easy-to-read game: Its not 100% obvious which objects are decorations, interactive, impassable and even the buy menus. There are many ways to fix that: contrast, glows, groups of colors, borders.... you decide.

    2) This may be 100% personal but the fact that the "camera" is really close to the character really increases to me the confusion. I really really feel that I would need a zoom out option to even try the game.

    3) As a graphic designer your HP UI gives me cancer (Im not intended to offend, its just that it contradicts all good GD implementations)

    a) Its too far from the main area were the player concentrates its vision//focus, and knowing how much HP you have is essential to surviving/playing

    b) its tooo tiny (it even has the same size as the gold, but is far more important)

    c) Numbers are"slower" to understand than other more visual options like "life bars" and you are making an "action" game

    d) Has 0 contrast or background, meaning that if the floor beneath its is brown or red you cant even see it

    Beyond those 3 things, I really see the potential for a fun game .

  • I solved it! 2 days of MADNESS and finally!

    The problem was in a part of the code AFTER the event. (I searched the code for the error allways BEFORE it, not even thinking about other possibility)

    Im sure its a rookie mistake that every programmer will have fun off, but how I suffered for it.... lol =P.

    It really helped a TON, having lots of folders/groups to disable/enable and sectorize the problem. I highly recommend it.

    Thnx all for the help!

  • It's pretty obvious if you compare the two, look at the order of the events in actual compared to test. The test code is correct picking, every time you pick an enemy you set the name to the glob var then add 1 to glob var. In actual you are adding 1 to glob var for every enemy, so the total number of enemies, then setting the enemy name for all enemies to the glob var number. Be careful with the order of events and sub-events, you've done it correctly in test code though so I can see you know what you're doing.

    I tried using that exact order but when I do that (the image below) some strage things happens too: The global variable that started in 1 gets to 4 as expected (because there are only 3 enemys that increase 1), but all the Tagnames are called the same "Enemy1" as if the data from the global variable was extracted only once for the 3 objects before it changed to 2,3 and 4.

    https://ibb.co/dkPGfn

    PS: I checked all those things tarek2 and many more, but thanks for the suggestions!

  • I want to give my all-ready created enemys (objects) a "name" (instance variable) that is different from the others (enemy1, enemy2, enemy3 etc...) as it solves tons of problems for me later on.

    I use for that a global number (EnemyName) that should increase every time the "for each" works.

    The problem thats driving me mad is that it works on tests but not in the actual project!

    It sets all the TileEnemys (objects) to the exactly same name (the global "enemyname"+1)

    Actual Project Code:

    https://ibb.co/kqBLO7

    Test Code:

    https://ibb.co/m4RyAn

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Link to .capx file:

    dl.dropboxusercontent.com/u/74420827/WARPFxtest.capx

    Steps to reproduce:

    1. Move the truck by pressing the arrows and watch how the warp FX works on the trees.

    Observed result:

    The slowly moving trees start moving FAR faster than expected on some conditions. In my original capx they move faster every time I move up or down,but in the example they move faster when they are at certain positions (normally when you move the truck up/down and it is at the same height that the trees sprites)

    Expected result:

    Even if there is no bug, the FX should work consistently and continue to behave / move in a controlled manner unless we change the attributes.

    Browsers affected:

    Firefox: yes

    Operating system & service pack:

    Win 7

    Construct 2 version:

    releases 152 & 161 64bit

  • Badass pacman LINK

    The only problem will be if you want the ghosts to don't collide with themselves. I'm breaking my head with that.

  • Hi people, I'm making a game that uses the same movement mechanics that in this THIS Pacman tutorial. (Here is the CAPX)The thing is that I don't want the ghosts to overlap cause in my game they are no ghost at all :P. I have tried every single thing that my mind can come with, but they all didn't work. Its like all that's spawned in the movement events wont work/be taken on account in the checking phase by the overlapping thing. If it is present at the beginning or spawned earlier it works fine. If someone can help me I will be VERY VERY grateful.

  • Maybe these are dumb suggestions because they are too easy, too complicated to implement or they can be done actually(I suck at programming :D) but still:

    1) It would we awesome if one can make the sprites/objects don't collide/overlap with others instances of the sprite/object. Making the sprites themselves obstacles or solids doesn't work (don't know why)and while the flock idea has some nice uses it wont help if someone wants his individual rts tanks going to different places. (*)

    2) This is harder probably: if the destination is unreachable why don't make the sprite/objects go to the nearest empty/reachable place instead. Something like "find nearest path to X,Y"

    (*) Using "on collision" + wait 4 the further instance it gets a little better but they still overlap randomly and sometimes even trespass solids.

  • Sorry to bring this up but for someone new like me this helped a lot and I wanted to help a little more: If you change "on collision with N" with "is overlapping N" you don't have the overlapping problem that happens if the player gets stuck to the structure walking from top to bot.

  • 9 posts