megatronx's Recent Forum Activity

  • Or just small icon before the name.

  • It is problematic in did, and definitely happens when game is upscale, but not sure if the problem exists if displayed in original window.

  • Thanks for the reply! That's a valid way to do it, but I want to keep all turret initialization logic in the turret's on created event even if it adds one additional condition per faction (color). I'll have various things using these faction families and hate to spread the initialization logic for them around at that level. But your suggestion should definitely work and in the short term I'll probably do something like that so I can move forward.

    Still, my first approach should work - do you have any idea why it wouldn't? I'm using a similar picking system in other cases to treat families more like components, and it seems to be working just dandy. But this makes me think I'm misunderstanding something fundamental (and apparently pretty important) about the way families work, picking works, and/or the way the turret behavior works.

    Then the events that are the same for both, make for the family that includes both types. But when you need turret to aim at the other group, it's best to have it separated. Will save you time, and frustration, and performance is the same!

  • megatronx it's almost possible, but families in their current form + containers just doesn't cover all the situations well enough to reduce my code, so it's pretty much one sheet per enemy graphic and even then I'm having glitches with multiple enemies using the same code, just not quite 100%.

    Yes, it can get problematic when a lot of units are using same events. However, make sure it is not a problem with your code. I say that because I had 100 of minions walking back and forth, all using same events, and for first few days I was battling with code, as on occasions they'd stop at the node, and not turn back and move. But, after several changes it all started working almost perfectly; almost because timer would not be precise, so some would move after longer time period then they were suppose to ( ease to check, seeing distances between minions becoming tighter ), which is a shame. But it worked in the end. I was only using platform and timer behaviors.

  • Objects are being created on the next tick, if I'm correct. So you got to use On created instead.

  • If it was easier to write events as "custom behaviors" that you can apply/stack on multiple objects (and object types) as has been requested/suggested/begged for over the past few years then I would never need to duplicate event sheets

    It would be good, but it would require to change workflow. And currently, really, you can do it, buy having dedicated event sheets, include them, with some conditions and it's almost the same.

  • Just simplify it:

    On green created : target red

    On red created : target green

    Or you can create txt variable and set them on their creation to either green or red, and then pick by that variable.

  • Generally 9path is putting quite a strain on performance. I suggest you just create several 9path objects, each with different animation frame, and animate them trough events. Best way to do it is to create a family for it, and create family numerical variable, then set object's value of that variable representing a frame that is suppose to be displayed, and then trough simple events, create static local variable with total number of frames and another one that will hold the number of current frame, and then every x ms add 1 to current frame local var, and trough events hide 9path family objects but display the one with variable that local static variable is currently set to. when current frame local var is equal total number of frames, reset current local var to 0.

    Hope that makes sense in writing

  • No "power of 2" "magic" involved here ; it's just pixel rounding, which does exactly what it says.

    As for n^2, it works "better" since content designed to work in n^2 can easily be accessed with data encoded on 8/16/32/64 bits, which are native data types, without waste, memory alignment or performance issues

    Setting values to n2 did improve smoothness for me significantly.

  • I think this would be a bit restrictive, in the sense we would lose some flexibility ; the layer system means we can split and mix & match bits of global layers the way we want, so that we can "include" relevant bits of gui/inventory/options depending on the context / levels / etc. To keep this functionality, we would still need a place to define what to include/display in each layer, which would make "automatic" global layers clunky

    Not necessarily: you could have default menus on global layout and if you'd want more flexibility you'd do that in current way. One extra option would be program to store gui layout ( as placement ), and do the rest automatically. Many ways to streamline current, often cumbersome workflow.

  • Technology did speed things up - the productivity has significantly increased. It's now possible with very limited knowledge, resources and time to create games that would have taken teams of experts years in the past. Think Super Mario on the NES ; it's now possible for a single person to create something better using modern software. Of course this example is a bit extreme and we usually want to do "more", but this in itself proves things are moving forward.

    If stability is the key, focus on mature platforms and technologies ; though while this mitigates the risk of "innovation" this also adds the risk of "obsolescence"

    I would argue that with progress of technology, everything becomes more and more loose, as less and less tight, and mario on nes is a great example, as there has yet to be a game made in c2 as tight as mario was for example . Even new smb games are not as tight as original. I played both fairly recently.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Technology was suppose to speed things up, but in reality, now everyone is waiting for someone else to fix something that is not working because of something else that needs to be fixed and so on. For years we are in pretty much same spot wasting time. And that's a problem across all software.

megatronx's avatar

megatronx

Member since 25 Sep, 2008

Twitter
megatronx has 1 followers

Connect with megatronx

Trophy Case

  • 16-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Forum Patron Made 500 posts in the forums
  • Forum Hero Made 1,000 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

23/44
How to earn trophies