Rhindon's Forum Posts

  • Thank you, plinkie! I'll review those later today.

  • Gooood day, ladies and digital-men!

    I'm planning a game set in a large-scale "sandbox-style" city with roads and buildings and everything in-between (except the kitchen sink...that might break the game...all that plumbing...).

    There will be very little changing of layouts - ultimately, I want the game to take place in one giant city. (Although, literally as I was just typing that, an idea occurred to me on how I could change layouts and yet still keep the semblance of a large city...more on that later.)

    My #1 concern is CPU/GPU overhead. Obviously, the more the computer has to compute, the more bogged down it's going to potentially get. Ashley & Co have been working miracles and wonders to make everything work as efficiently as possible so my concerns may not be all that warranted as they might have been had I tried this game on, say, C2. Still, I think it's important for me to begin keeping this detail amongst the top of my priorities.

    Here are some things I know of or I think I know of that will help to keep CPU usage down...

    - Keep related objects in folders. Objects that are directly associated with each other (ie: containers, objects pinned to another, etc) should all go into a folder. For reasons I cannot articulate, this just makes it easier for the computer to reference, drawn, manipulate, whatever every tick.

    - When dealing with road objects, specifically long road sections, having the road pieces stretch via height or length will obviously reduce the number of objects needed to be drawn on-screen (and less to track overall). I am, however, unaware of the use of a 9patch vs sprite vs tiled background will be of any benefit in terms of CPU usage.

    - Effects, WebGL, particle objects, etc, tend to be a bit more demanding on CPU/GPU. I should use these sparingly, even with the improvements to C3 runtime. ...... At least, this is my understanding. I fully welcome correction.

    - Objects off-screen are not readily drawn. So I don't need to tell C3 to draw objects as invisible when off-screen because they're literally NOT drawn given that you can't even see them anyway.

    That's all that comes to mind at the moment.

    Any and all suggestions would be greatly appreciated.

    Also, please go easy on me on technical jargon. I've been using C3 for a while, but some of the terms and such for more "professional" level of game design is still rather foreign to me. I may need to ask questions for clarification in order to make sure I know I understand what you're explaining.

    Also, my friend, SycrosD4, is teaming up with me and is very new to C3. He'll be handling the art-side of things and I'm sure he'll appreciate the info, too.

    Thank you everyone for your help and input!

  • Great info!! Thank you! I'll work on plugging these in soon.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • As I understand it, 0 db is basically the "original" volume level for a given audio file (master volume of the device notwithstanding). Going negative will, of course, lower the volume; going higher will increase it.

    My question is, though, what is the db you can set the volume to at which point there is officially no sound? It wouldn't make much sense to keep telling the game to continually lower the db when, realistically, the volume is already nill anyway.

    This is my first real jump into manipulating sound levels apart from audio playback actions on the event sheet, so I want to gather all the info I can.

    I'm trying to set up a basic "master volume" option on my game's title screen to set the music and the SFX volume levels during the game.

    Thanks for your help!

  • Actually, yeah, that's just about what I had in mind.

  • ...YUP! That did it. Thank you again for the find. Things are working now.

  • Aaaaah! Well, if that's the case, I can work around that. Thanks for your help!

  • Yeah, that's the problem - the Enemy_Text object contained with each Heli verifies that none of the UIDs assigned to each Heli are correct.

  • .c3p file: dropbox.com/s/o0wuhllutq7uxsr/The%20Getaway%20v3.c3p

    I have a 3-object enemy (by way of a container) which is meant to patrol a designated area, marked by another object, the "District_Area".

    Using the Bullet behavior, I make the Enemy_Heli_Move object (contained with the Enemy_Heli_Blade and Enemy_Heli objects and pinned together) patrol the designated District_Area. At the start of the layout, I assign the District_Area UID # to an instance variable in Enemy_Heli_Move object.

    I then pick the District_Area according to the value of the Heli's instance variable and check if the Heli is overlapping that select District_Area or not.

    If not, I tell it to rotate its angle (with Bullet behavior "Set Angle (of Motion)" checked in the properties window) back to the District_Area it's assigned to.

    The problem I'm having is that the UID of the District_Area is not being properly assigned from the beginning and I cannot understand why. I've done things like this before and it worked fine.

    Here is what I have for the setup and the workflow for the Heli.

    Thanks for your help!

    START OF LAYOUT:

    ENEMY PATROL CHECK:

  • Ah. I'm using Chrome (forgot to mention that in my post... Now updated). So maybe this is worth posting to the bug site for Ashley to look into.

    Thanks for the info!

  • That...is so ridiculously simple and awesome.

    Leave it to me to find the more difficult ways of doing things. THANK YOU, so much. LOL

    To answer your question, I was aiming for the Tween feature because of its easing into its end value. Whereas lerp is more all-or-nothing. But what you have here actually works perfectly!

    ALSO, thank you for reminding me about the reinitializing of the Tween behavior. I forgot about that. When I was doing my testing, I did notice that the value for the Tween seemed to "flicker" but I didn't catch on what was really happening. I'll try to remember that next time I think Tween is the way to go.

  • In my top-down racer game, if the Car overlaps a piece of road (the Onramp), there are several layers (for now, just "Road" or "Overpass") which are meant to zoom in or out based on the lerp value of the Car on the Onramp.

    Overview:

    1. Car overlaps Onramp (single object with four different animations for its up, down, left, or right-facing position).

    2. C3 calculates either the X or Y unlerp value depending on the position of the Car and whether the Onramp is facing up/down or left/right.

    3. Using an off-screen "Zoom Meter" object with the Tween behavior, I Tween the Zoom Meter to the unlerp value as determined by the position of the Car on the Onramp.

    4. The Tween is meant to arrive at the corresponding unlerp value shortly after the Car gets to its at-that-moment position.

    5. Using the Value of the Tween, I update the scale Road and Overpass layers.

    Just in case that didn't make much sense, this is what it's supposed to look like...sort of.

    Not properly illustrated, as I stated above, is that the actual zooming/scaling will be "lagged" behind the actual position of the Car relative to its position of the Onramp. It should act like this (which is where the Tween comes in):

    C = Car

    Z = Zoom/Scale of layer

    <--C-------->

    <Z---------->

    ...then...

    <-------C--->

    <----Z------>

    ...

    <-----------> C

    <----------Z>

    Basically, the Zoom is always playing catch up to the unlerp value of the Car's position on the Onramp. If the player slows down on the Onramp or even stops, then the Tweening of the Zoom value should eventually (like, within a few seconds or LESS) match up.

    Problem is I'm having trouble properly making this work. I had it set up before where it would update the Zoom based on the at-that-moment unlerp value, but not with a delayed value.

    Here's a screen-shot of my current event/action set up:

    I hope that all made sense...

    Can someone help me see where I made my error? Thanks.

  • OH! So basically it's a FRACTION of what the CURRENT scale is.

    Similar to how lerp works out a value between [start] and [end] values given the percentage between them.

    I understand now. Thank you very much!

  • I am unsure if this is truly a bug or if it's just because of the demands of my project...

    Simply...

    When I load my game via debug, selecting any - literally ANY - object instance takes a long time to bring up any info about it. It's like I never clicked it at all if not for the fact that eventually the info will populate.

    Worse, the bounding box - the red dotted line that highlights the object in the game window - also lags. When the debug info populates, the bounding box will, as well, but if the actual object is moving the box will not update in real time. There is anywhere from a minute to several minutes before anything happens.

    The game I'm working on has numerous roads and other road-based objects in the layout, as well as several layers. But I've seen games with lots more going on and it doesn't seem to matter. When I play the game normally - as far as I have it - it doesn't have any noticeable issues, other than the occasional "stagger" or drop in framerate at random times. I think that may be due more to my laptop than anything else (even though it's still very new).

    I've been working on setting groups active or inactive depending on the need in order to reduce the amount of events the game has to process at any one time. I'm also working on reducing the number of objects consistantly in the layout to reduce how much it has to redraw every tick. Still, the debug persists in its laggy-ness.

    I'm using the most recent version of Chrome.

    Here is my current WIP .c3p : dropbox.com/s/my7t3c42aao38g0/The%20Getaway%20v2%20resize.c3p

    The controls are:

    UP arrow: accellerate

    DOWN arrow: brake/reverse

    LEFT/RIGHT arrows: turn

  • I'm working on adjusting layers at certain times and then shifting them back.

    However, what I don't fully understand is how the "Set Scale Rate" works. Setting the scale immediately makes sense, if it's X at one point, setting the value to Y takes immediate effect.

    With Set Scale Rate, my assumption has been that it works something like a built-in lerp or the new Tween behavior. Meaning, if the initial scale value is X, it will gradually move to Y once it is told to set the scale to Y...it won't be an instant update.

    My confusion comes in during an initial test...

    I set the scale rate value for a few layers at the start of the layout then triggered some events to adjust the scale. As before, it updated the scale of those layers immediately...there was no indication of "rate" or "gradual" as I supposed.

    Clearly, I'm misunderstanding things but cannot figure out what, exactly, I'm missing.

    For specifics of what I'm trying to do, here's the .c3p

    dropbox.com/s/my7t3c42aao38g0/The%20Getaway%20v2%20resize.c3p

    Event line 1 (look for the actions towards the bottom of the first even line; ignore the sub-events) and the group event starting at line 96.

    Could someone clarify this for me, please? THANKS!