SoldjahBoy's Forum Posts

  • I would suggest the player remains static on the screen, and the background scrolls around the player/screen... enemies would also be queued to appear at specific intervals based on position of the backgrounds, or maybe a timer.

    ~Sol

  • The most reliable way to do something like this would be to use the timer behaviour, or make a timer for the object yourself (instance variable perhaps).

    [Object Is on floor]

    [Every 1 seconds]

    --- Subtract 1 from timer

    [Object is on floor]

    [Timer = 0]

    --- Do stuff

    [Object is not on floor]

    --- reset timer

    Hope this points you in the right direction

    ~Sol

  • I do this all the time using nwjs... i have my fame open while working at the same time.

    ~Sol

  • I'm in Australia bud

    Can't wait to see how the enemies look... and how the world shapes up.

    ~Sol

  • Looks cute so far

    ~Sol

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I would suggest making a level editor that is separate to your game. I don't know how you are storing level data at the moment... but you could have the editor export a "level file" that the game will automatically read.

    I have made things like this in the past, and having another program that can run independently is a big bonus.

    ~Sol

  • You need to add the "browser" object to your project.

    Button is clicked -> BrowserObject.GoTo (URL)

    ~Sol

  • > i prefer to place em just outside and then destroy them in the layout start up. Create when needed.

    >

    This had never occurred to me before. I think i'll play with this when I get home. I have a lot of sprites on certain layouts, and I take it destroying them on Start of Layout and only recreating them when I need to saves processing?

    Yes it sure does.

    Destroying on startup can be problematic in some situations though - like if you're loading data for objects.

    I destroy things on startup as well, but often use an instance variable to declare "unused" objects before destroying them.

    I have something like;

    [ON STARTUP]

    --[Object.InstanceVariable=0] Destroy Object

    This way, I can set that variable to 1 or whatever for loaded items, and the default value (0) gets destroyed.

    ~Sol

  • I'll be asleep by then (it's 12:30AM here now) but I'll be sure to have a look in the morning

    I want to see, because your graphics are quite stunning - so seeing it motion is really going to be cool

    ~Sol

  • I can't wait to have a look

    ~Sol

  • > Either method works fine... a separate "global" layout, or just outside the layout bounds (then destroy on startup).

    >

    > There's no real benefit to using either method, apart from calming any OCD tendencies you may have.

    >

    > ~Sol

    >

    Actually I never thought of creating a layout with ALL objects. Cool solution, and saves event/actions of destroying on starup...

    Please note the layout must be set as GLOBAL in it's properties, or else it may not work the way you expect it to.

    ~Sol

  • I've now reduced the limb count on each dude to be like "normal" people - two segments per limb. Having loads of segments was fun - but it was causing too much impact on over-all performance (especially with a lot of dudes) so I will now be re-doing how they're animated as well. Currently the old "walk" animation is still there and looks more hilarious than ever.

    Please note, the standalone build still has the old arms and legs for now. I will re-upload that later.

    ~Sol

  • All of my map stuff is "flat" because it's a top-down view map. Rivers will basically be somehow "drawn" or "doodled" onto the tiles, maybe.

    My weather is pretty okay actually. I have limited it to around 200 "particles" and each "particle" is drawn with several streaks of rain/snow/etc and randomised speed. Each particle block is actually fairly large to give the impression of more individual particles, but in reality there is like 10 streaks of rain or about 8 snowflakes per image.

    So as far as having a blank tile set goes, I want to be able to specify a series of things - like terrain type (grass,dirt,sand,etc) as well as have points of interest (like a town that generates random(x) number of buildings). Everything is tile based so things like towns would, I guess, be generated from some kind of central "Seed point" and just spawn buildings around/near it until the conditions are satisfied. I can probably figure it out, but any tips on how you did your islands would be appreciated. Did you start with aLL water and place the land over it... or the other way around?

    ~Sol

  • Thanks a lot R0J0hound I will give this a try.

    I have managed a bit of a "hack" method using some distance comparisons - but I don't think it's ideal. I will try out what you've listed here. Cheers!

    ~Sol

  • Been thinking about how to approach this problem recently - and I have a couple of ideas but I'm hoping for something a little more elegant.

    I have a main "body" object and a smaller object which are part of the same container. I want to be able to freely move the small object around, but keep it constrained to the large "body" object within a defined circular radius. I have thought about using another sprite set to opacity 0 (and set as solid) as sort of a "wall" around the large object so the smaller object can't pass through - but that seems sloppy - and will cause issues with other objects colliding with the "wall".

    The second idea I had was to use physics and just hinge the objects together with an armature (think of like, a rope tied between to objects). I didn't really want to go this way either, because adding physics to the project is only replacing one problem I'm having with another. I'm trying to do this to optimise some stuff - so going with a (probably) more CPU intensive method isn't really going to help.

    Anyone got a better idea how to constrain the movement, maybe based on a distance calculation or something? The smaller object would need to have freedom of movement within the radius of the larger "body" but not be able to "escape" past a maximum distance in any given direction.

    I'm sure this has been asked before, but for the life of me I can't find any real references to the problem.

    Thanks in advance for any suggestions.

    ~Sol