C-7's Forum Posts

  • You can't click on Watch right there next to Inspect in the free version? Regardless, just make a text object that is updated to show fps and cpu utilization (both are system values) and skip the debugger all together. That will give you more realistic data. My game regularly uses 20+ layers, multiples of them with opacity/shaders/force own texture, all of the layers have a lot of images, and my performance is fine outside of the Inspect tab of the debugger (understandably so).

  • I thought I'd give it a test too just for more results.

    With the layer: 60 fps, 11% cpu

    Withou the layer: 60fps, 3% cpu

    And adding more layers can slow it to a crawl.

    The problem, however, is the actual debugger. Switch over to the "Watch" tab in the debugger instead of "Inspect". I can have 30 layers added onto your project and not exceed 1% CPU use. The Inspect tab keeps track of a lot of stuff. It's meant for really detailed display of everything going on under the hood, whereas Watch is a bit closer to an actual gameplay environment. I use Inspect to pick the variables and values I want to watch (with the eyeball) and then just check that stuff in Watch so not everything needs to be accounted for.

    Fore reference, Core i7-4770 3.4 GHz, NVidia GT 640 4GB, 32 GB Ram. This was Chrome on Windows 10.

  • I don't know about one compute vs another, but don't worry--you're not the only one who must run their project with the cache unticked I can open it last I tried, but it will soon run into massive problems. The downside is the editor is slower without the cache, but that's still quicker than reloading regularly.

  • It's a little tough following what you're doing without at least a screenshot of your events, but I would give each music track a tag called object.animationframe. Then I believe you could use the inverse of is tag=object.animation frame to mute all of the others.

  • Unique just means individuals and excludes repeat visits.

  • R0J0hound Thank you so much for the update! It does everything I could have hoped for darn-near flawlessly! It was pretty easy to integrate into my game, though I had to change one thing to make it properly recognize objects with a negative width or height--just set boxWidth and boxHeight to abs(wall.width) and abs(wall.height). The new example with pushing stuff around looks amazing too! I wish that is what the built-in collision engine did!

  • You do not have permission to view this post

  • Gearworkdragon I would store the X/Y position of the enemy in something like target variables. Then you can do attacks toward that position and not worry about picking. It's gonna take a lot of testing, debugging, and stepping through to make sure all of your logic flows correctly, but you should end up with a nice system at the end if you follow it through!

  • I guess I don't have the specific answer to your individual problems, but I think the problem lies in your system anyways. You need to look up a little bit of what a state machine is. I'd actually recommend pulling out some paper and a pencil and draw a flow chart for how your battle system should work. Take things like speed (attack order), secondary attacks, multi-turn attacks, and specials into account.

    So it should start with if the battle is one or off, of course. Please don't use booleans for this, though. Use numbers to increase your flexibility (like if you want global changes later).

    Battle = 1.

    Then you need to decide whose turn is next. If you're using an ATB (active time battle) system then you would let players choose attacks once their bar is full (a state) then add them to a queue (probably an array) of attacks. If you're doing it true turn-based, then skip the ready bar and put everybody in an attack order/ready queue. If you're doing it speed-based, re-order the list by player speed every turn (in case you use abilities that increase or decrease speed). I don't know if you're doing all the good guys go and then all the enemies go or if it's more organic, but if you're doing it one side then then the other, use two lists and a state to switch between them.

    Then, you can use the coordinates in your list to decide clearly mark who is attacking and who is not. You should have something like 'is attacking" for all of your players and turn that off at the end of a character's turn. When their turn is started (probably called with a function), turn their attacking condition on so you can do necessary UI changes and then each attack is a function. The parameters should be the target, damage, modifiers, etc. You should also include which character is performing the function/attack so you can use the same code for multiple characters.

    It's really complex, but plan it all out on paper exactly how things will work, keeping functions, arrays, possibly the dictionary object all in mind. Then, it's much easier to wrap your head around how to set up your state machine so it can run itself based on your values in battles.

  • HZGaming

    Ah, sorry. I didn't see any mention of control type--had no way to know you were talking about touch. Most games I've seen that require constant dual-analog use automate the rest. Like the character automatically fires their weapon, you just have to aim. So make firing automatic. As far as environmental interaction, I don't think that's so awful to have the player stop momentarily for that, depending on how often you do it. Or you could make everything trigger automatically in some elegant way.

  • For a dual-sick setup, typically the shoulder buttons are primarily used with the sticks. The face buttons would only be used in the instance of special functions that aren't always done.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I think the center of your viewport in the editor is the same as the center of your view on the game window, so that should help a LITTLE with lining things up. I dunno, perfect alignment hasn't been important for my game so far.

  • Not to mention you've titled it similarly. Hundreds of shooters have similar styles, but you are nearly copying Angry Birds in nearly every aspect save for apparently gameplay. At least use a different color scheme or SOMETHING that people can identify as yours.

  • I think it's perfectly doable. I'll go ahead and link to the thread for my game Courier. I don't have hundreds of layouts, but I do have a lot, and they're all quite detailed. I have a ton of unique different objects, though I reuse assets as much as possible (note, though, the game is NOT built up of tiles--I wanted more freedom). Land-wise, my game is larger than Ocarina of Time (excluding the dungeons--just everything outside of them). I haven't had any trouble with stuff getting slower because, as far as I know, js will eventually cleanup and drop out unused assets. I've tried to be pretty efficient, however, so my vram use is never very high. The downside to piecing things together like I do is an increase in object count, but I can get a ton more freedom while minimizing the amount of assets I need to create. I rely on some fancier graphics tricks, however, so I don't think a phone version is possible right now (and I'm not interest in mobile anyways), but it's been smooth sailing on PC.

    Not as a bragging point, but for comparison: I have more unique NPCs than OoT and LttP combined if I'm not mistaken, my overworld and surrounding areas are bigger than either game's overworld and surrounding areas, every character is animated, grass sways, trees sway, the ocean has waves, etc--it's all very detailed. I have a pretty detailed shadowing system in place. I have maps in excess of 10,000 pixels across. And C2 has run it just fine.

    So long as you're careful and put thought into how you design the game, it's perfectly doable.

  • > It's tough to know exactly what you're talking about without a screenshot, but set snap to grid to at least 1x1. This way, you won't be dealing with subpixels. Depending on your art style, you could also switch to point sampling in project settings. And, if you're unfamiliar, when you set the snap to grid settings, don't click off of the numbers until you've clicked back on the previous number entry box--otherwise, the values get reverted. You'll see when you try it.

    >

    See how it fades? the lining things up like that is irritating.

    Also, snapping to grid now would require a complete level redesign, since some are alreday in subpixels and moving them doesnt just snap them to a whole pixel

    That looks sort of like stretched out sprite objects. If it's just repeating/one-color stuff like that, use the Tiled Background object so you don't get stretching. If that isn't a stretched sprite, then I have no idea what would cause that other than something in your source image.