cjbruce's Forum Posts

    What country are you from? XPF is set to default currency for:

    Wallis and Futuna

    New Caledonia

    French Polynesia

    Is that wrong?

    I am in the US, but my payment defaulted to "XPF" as well. I have never heard of the islands, but they led to a fun little geography lesson.

  • Solved it! The problem with parenting and setting transform = Yes is that I had initially scaled the laser body model in x,y, and z. This meant that the motors were also scaled in x,y,z and came out elliptical instead of round. All I had to do was to scale each motor/wheel by the same amount whenever I created them. The correct order of operations is:

    1. Create a "laserwheel".

    2. Set it to the correct position on the laserbody.

    3. Change the laserwheel's parent to "laserbody", with Transform:Yes.

    4. Set the laserwheel's local object scale to the same ratio of Sx, Sy, and Sz as the laserbody. In this case, (self.Sx*1, self.Sy*0.6, self.Sz*0.7).

    Now that everything is parented correctly, it takes a single event running each tick to correctly rotate each wheel and motor about its local y axis. This cut the CPU usage for these events by 80%.

  • Love the promo image! Nice work!

  • Gosh. Imagine designing a wide variety of vehicles like this as opposed to having a 3D modeller design and rig it, you use a single Object3D and have it's children transformable whenever needed. The division of labor is also clear cut.

    But I digress, parenting not working for you?

    BTW. Nice game!

    Thanks for the encouragement! I'm hoping it turns out well so that more people see html5 as a viable alternative for 3D.

    I will definitely take a look at parenting again. It should work, its just that each time I tried, it came out wonky.

    I realized after the first version of Robot Rumble, people weren't as interested because I tried to do all of the artwork myself. This time I have a professional 3D artist on the project, and I'm really excited to see how it goes!

  • cjbruce

    I suggest doing away with the physics based wheels entirely, and making the cars spheres/blocks instead. This should significantly boost performance and is how most video-game cars are implemented. Im assuming you made the wheels invisible because they were acting strangely? I realize this is probably a big change to make but my experience tells me its the best way to go.

    The physics-based wheels are acting great, and aren't the CPU hogs that I am referring to. The reason I want to keep them and not show them is they provide for a nice movement feel and automatically take care of orienting the players properly when going over rough terrain or when driving up on top of other players. I tried a raycasting solution earlier, but it was a little wonky and never looked quite right. In the end, you might be right--it will make for a much simpler game to remove the wheel-based movement, but I would like to try to keep them for now.

    The CPU hog I am referring to has to do with positioning/rotation of the visual elements. I should be able to parent them to the body and do rotation about a local axis, shouldn't I?

    Edit: Here is a screenshot showing the offending events:

  • cjbruce

    The issue seems to be with the use of physics more than with the rendering of objects. A scene without physics should take many many objects before it slows on any okay CPU.

    It's probably a better idea to fake the movement by considering the entire car a single rigidbody and applying torques to that to emulate wheels. Using hinges on cylinders will lead to trouble getting a good contact patch and make the controls poor, as well as open up the possibility of wheels getting out of alignment. This will also be much less costly

    Actually, what I wrote above isn't exactly true. I am using a separate set of 4 invisible cylinders for the physics movement, and just setting the rotation of the visible wheels and motors based on the angular velocity of the invisible drive wheels. I really like the way the robots drive, and it gives the game a good feel when you land on a ramp or hit the ground:

    https://dl.dropboxusercontent.com/u/55106174/rrfpsbattlearenatest/index.html

    Press "2" to switch from the electric tank to the laser tank to see a closeup of the motors and drive wheels.

    My problem is that 4 of the "laser tanks" require 6% of the CPU time in the debugger just to handle the position and rotation of the wheel and motor "eye candy". I would like to put visual wheels and motors on the other robots as well, but I will quickly overload the CPU if I try to do this. I feel like I should be able to save some CPU cycles by parenting the wheels to the body and positioning/rotating them locally, rather than in world coordinates. I just can't seem to get this to work correctly.

    Edit: You can see the "invisible wheels" on the electric tank. The laser tank uses these as well, but they are invisible for the laser tank. We aren't done with the 3D models for the electric tank yet, so the current model is just a stand-in.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • cjbruce

    What do you mean by instancing?

    "instances" is a term used in babylonJS to describe identical 3D objects added to an array and rendered in a single draw call. I have been struggling with adding more than a handful of projectiles onscreen before frame rate drops, and was hoping that I was missing something in the way I was creating and handling the objects.

    I'm also a little worried because I haven't really started populating levels with anything more than blocks. I assume that the best practice is to import the entire level as one big 3D model, correct?

    One more question: I have created toy robots that consist of a body, 2 motors, and 2 wheels. The motors and whels are positioned on the body, and their rotation is controlled programmatically by torque applied to the wheels. I am setting the position of each wheel and motor in world coordinates, because I can't seem to correctly parent the rotating objects to the robot body and spin them in terms of local coordinates. Am I missing something here? I should be able to do this, shouldn't I? Setting position and rotation of all of the wherls and motors every tick is taking up a significant chunk of CPU time, and I need to figure out how to do things more efficiently.

  • jobel - that's literally nothing. It's a change because green light wouldn't just allow everything in. Now everything is fair game. If I make a crap game and sell it for $10, I'll easily make my $100 back, so where is the risk?

    I agree with you there. The barrier to entry seems a little low for publishing on Steam. Then again, they are Steam and have access to more data than the US government. I hope they have kept quality in mind when they made the decision.

  • tunepunk,

    Thanks for the insight, and I think you are spot on. All of my experience is with non-game mobile education apps, released in 2012-2014:

    App #1 was a traditional iPad-only app for a niche education market (high school physics), sold 1400 copies over three years for $5 each, was promoted by Apple, and made $5000 in sales from 2012-2015.

    App #2 was a free iPad-only app with two in-app purchases. It was a classroom collaboration tool that required a server backend. It was not promoted by Apple, was downloaded about 1000 times, and made $10 in sales From 2013-2015.

    App #3 is a free circuit simulator app for classroom use built in Construct 2 with poorly targeted Admob banner ads. It has had about 200,000 downloads total between iOS and Android since its release in 2014, and has made $0.67 in ad revenue.

    I have been really disappointed by the ad monetization model. Poorly targeted ads have made essentially $0 in my case. Based on my own limited data, the only way to make any money at all is to invest a ton of time making a great, polished product, and selling it for more than $0.99. Then again, based on the 1300 hours I spent in development of the first app, I earned about $3/hour, so it certainly wasn't worth the time financially.

  • >

    > I have done one walk through tutorial already, and might do more, depending on interest:

    >

    > https://www.scirra.com/tutorials/9456/building-your-first-3d-game-with-the-q3d-plugin

    >

    > Is there anything in particular you would like to see?

    >

    Sure. My idea is a tutorial teaching how to create borders in 3D models like seen in Ultimate Spider-Man and Pokémon Sun & Moon, bringing a cartoon look-like to 3D games.

    I'm playing around with the approach I described with the "shell" and flipped borders. It works, but it will take an artist to make it look good. I have it working with the Q3D "basic" shader which doesn't use any lighting information. This means only the diffuse color channel is used. It should render really quickly, but someone has to hand-paint all of the color detail in Blender. The black border just happens automatically this way.

    I suppose you could do it with a Phong or Lambert shader instead of a Basic shader, but these might look a little weird because of the extra lighting/shadows. Q3D doesn't have a "toon" shader built-in.

  • I'm having some probems with Z sorting 3D files in Q3D. Even if I palace things on different layers they seem to have Z errors. Thought that the order creation would place them on top but no luck. Any ideas? Or am I missing something here. Tried Scirra z order, and Q2D sort order but they still display wrong.

    Cheers,

    http://www.liquid-glass.com/123/test.capx

    I'm sorry to take so long to look at the .capx. I was out on vacation, and just got back today.

    I noticed a few odd things:

    1. You are creating 4 new objects every tick in the "MATRIX" event sheet. This makes it almost impossible to debug anything because it quickly drops the frame rate to a standstill. I put all four object creation events under a single "On Start of Layout" so that you only create them once.

    2. You are placing each object in an unexpected way. They all have almost, but not quite, the same z position:

    (500,500,1)

    (500,540,2)

    (500,580,3)

    (500,620,4)

    Given that each box is a 50 x 50 x 50 cube, did you really mean to space them 1 apart in the z-direction?

    3. You don't need to create a new object type each time you want to place an object. I assume each of these should be an instance of the "crate" object, or something similar? If you want 4 of them, just use a for loop to create one and place it appropriately each loop. Or just drag them out onto the layout by hand. I place everything in my level using a top-down view, then position the camera so it looks at everything from a 60 degree angle.

    If you are interested, I can send you a sample .capx showing how I would place things in the layout, then design the 2D UI on top of that.

    Have you given any thought to how you want to design x-y coordinates? Do you want to place everything on a standard x-y grid, then move the camera so it is looking from an isometric perspective? Or do you want to place everything in an isometric grid to begin with? I haven't done an isometric game before, so I'm not sure how people typically lay things out. I suppose it primarily affects the mathematics of character movement...

  • I would love to see some numbers here too. My next game release is also mobile first, and I need to figure this out pretty soon so I can design around it.

  • > Being able to do instances of objects...

    >

    I've just tested with ThreeJS/JavaScript and it is possible to do so -- absolutely.

    In fact, the name of the mesh (obj's 'o' key) is retained, where, you can access it by the child's .name property. From there you can then translate, rotate, scale etc...

    The caveat in going that route is, of course, the missing "IDE" but other than that, the plumbing work in ThreeJS is already there.

    EDIT:

    Just noticed that .PickChildren is also available for Q3DModel plugin (that loaded .obj files) but doesn't expose the .name property. Why?!

    EDIT 2:

    I see why. The OBJLoader.js included in Q3D is actually a different implementation than Three.js and only accounts for vertices, normals, uvs and disregards the rest (including grouping names). Perhaps this was done to allow certain use cases in the C2 editor that, over time, was never meant to be.

    cjbruce

    I don't think we'll ever get that feature in the current Q3D -- despite it being perfectly doable in actual ThreeJS + JavaScript. That is, unless some major work is done to the OBJLoader (and some other implementation files).

    *sigh* what a downer.

    Thank you for looking into this! I agree with the design decision. Given the choice between using C2 style picking that just works in Q3D, and the confusion that arises with "meshArray" in B3D, I would go with the simpler-to-understand Q3D approach as well.

  • Hi, it's been a while. To anyone who knows the answer to this question (I've searched). But to setup the context, lets say we have an .obj with three cubes.

    I see the "SYSTEM --> For Each child" and upon iteration, the .idPicked property shows unique numbers. Great.

    But applying something like "Q3DMaster --> Set object visible" to false doesn't seem to have any effect.

    QUESTION:

    Does the "System --> For Each child" work for loaded .obj that has children (the three cubes in this case) at all?

    Or is it only useable for Q3DModels instantiated/created in C2?

    WHY:

    ThreeJS's Object3D.traverse(callback) seems to fit the bill for this type of useage. Just asking

    https://threejs.org/docs/#api/core/Object3D

    Super interesting question! One of the limitations I have been living with is a low object count. If I try to do lots of objects, I quickly overload the CPU. Being able to do instances of objects like you can in Babylon3d would be great. QuaziGNRLnose, is this possible with Q3D?

  • I dont know how to make the 3D things in C2. Did you use a plugin or 3rd party or something?

    I used a paid set of Construct 2 plugins called Q3D. You will also need 3D models to play with to make games, so a free program called "Blender" is a good place to start learning how to do 3D modeling and texturing.