Rhindon's Recent Forum Activity

  • 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.

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • 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!

Rhindon's avatar

Rhindon

Early Adopter

Member since 8 Jan, 2013

Twitter
Rhindon has 2 followers

Connect with Rhindon

Trophy Case

  • 12-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
  • x2
    Coach One of your tutorials has over 1,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

19/44
How to earn trophies