Beat Attack [prototype] - Versus rhythm puzzle brawler

Tuism

Update 16 April 2015:

First of all, thanks for everyone's playtest feedback at the last meetup! It was super valuable!

You can play the game on web build here: http://gamejolt.com/games/arcade/beat-attack/60411/
(trying out gamejolt, please let me know if there are any problems/irritations)

This build a huge update to what's seen previously, fixed a bunch of stuff and added a bunch of stuff.

It looks a lot prettier than before (I can't help but work on the graphics when I know I should be prototyping gameplay but the new free bloom's amazing)


New: Character select + Speed select. You can mirror match too!



The Bear has chuck attacks:


And Landshark has missiles!


And there's a turbo speed setting that goes up to 170bpm (Just for you @chippit):


If you have a chance please give it a play!
http://gamejolt.com/games/arcade/beat-attack/60411/

Focus feedback questions:

1. How fiddly did you find the controls? It's meant for touch and *maybe* controllers eventually, but right now? Do you have any preferred keys you'd rather use?

2. How do you find the speed (on all three speed settings)?

3. Do you feel that either character right now seem imbalanced?

4. How would you describe this game? This is a very difficult one for me as "puzzle" is the default descriptor for me, but most people don't understand it as such. Please help XD


----------------------------------------------------------

Original old post with old content

Hi guys!!!! :D

TLDR: Play Beat Attack (tentative) HERE AND NOW:

*redacted*

Then TLDR 2: Screenie:



TLDR 3: Video:

http://instagram.com/p/tyeY1AN1Qk


Ya'll know about my love affair with a few things:

1. Japanese style puzzle games (not the western stuff. Not jigsaw puzzles, not Threes (though a great game too!), not Angry Birds (that hardly qualifies as puzzle in any culture :P))
2. Multiplayer games
3. Multiplayer games that fits a tablet
4. Music games

And I feel I've hit many of those with what I've made so far in Beat Attack (tentatively titled)! :D

It's finally ready, after adding layers and layers of juice and minute system changes (I'll tell you a game like this relies a LOT on its FEEL. When do the blocks drop? When do chains count? Etc, all changes the feel considerably. I've been working on those).

The massive heads in the back may be a bit distracting because they're animated, but I feel strongly about making the game feel something like DDR - that it's very visual to watch for people not playing. I've dimmed them back a bit with a black overlay, so let me know what you think of them.

Lots of stuff still to add :)

Looking forward to your feedback! Now go play it!!!! :D

*redacted*

Please? :)

Credit goes to the awesome Tim Harbour for working with me closely to make the kinda procedural music system for the game, dude you're a freaking legend!! :D

Tuism

Is it just me or is the video not loading? It's an instagrammy :/

Edit: for anyone else posting instagrammies, remember to take out the "/modal=true" in the URL - remember the slash too!

Kobusvdwalt9

That modals in the background looks awesome. This has come quite a bit keep it up. I am going to wait and play it at rAge...

moonstormer

very very cool concept, although it's a bit confusing at times - i can sometimes pick up blocks and move them where i want, but sometimes i can't pick them up, or it picks up more than one, or it picks it up and puts it down where i don't want it. i really like the idea, but i think i need to play it on a tablet instead. also, the pace ramps up really quickly so you don't feel like you have control of the game at any point.

Tuism

@moonstormer thanks for the feedback :D yeah I think I need some sort of brief tutorial - it's not a straight forward system after all.

The speed ramping is one thing I REALLY still need to look at - right now the linear progression is really actually too fast for most. I'll be addressing that before rAge.

The pick up/drop works like this - if you're holding nothing, you'll pick up everything on top of the same colour. So if there's 3 greens on top you'll grab them all. Then you'll drop anything you were holding if you press again. That's all really :) While you're holding blocks you'll see there are outlines of the colours you're holding to show you where and what you'll be dropping.

Tuism

@kobus dude if you play hexagon on hyper I'm keen to see if you can survive the current speed :P I wanted to bump it up to 200bpm :P

The speed mechanic needs work to fit everyone, and I'm not keen on making it one straight up difficulty setting thing. Need to think on it more, have one idea that I will implement soon.

FanieG

Those backgrounds are fine. You can never go wrong with the bear chuck and missile shark :)

Kobusvdwalt9

@FanieG I am so daft lol I didn't even notice they were from universe TU.

FanieG

Yeah they are definetly from TU limited.

Tuism

Seems I'm slowly but surely building my own Dark Tower :P

Will upload a new speed adjustment system soon. Don't have much time right now but sooooon!

Also I hadn't included any specific questions because I wanted to see if there was any general feedback on the game. I guess that's simply the wrong way to go about it XD Will also post more specific questions later :)

konman

@Tuism I love the Player versus AI or Player versus Player thing happening here. And the way the music tempo supports where we are during the game is wonderful. It's colourful and fun and invites one in and instills a feeling of urgency.

I know this is a prototype, but I would maybe need a big static picture (or sequence of pictures - maybe a slideshow?) as a tutorial that describes the game-play mechanics with bold arrows pointing to objectives etc before the actual game begins? or maybe as an optional thing for those that do? :)

One thing is for sure...I suck at this game, might have something to do with me being rhythmically challenged though :)

Maybe a feature that rates/test one's rhythm skill as a tongue in cheek option? Player must mash the test button to a preset rhythm and their skill level is presented like on one of those carnival high striker things? Just some random thoughts. I know rhythm is not the only focus of the game, but pattern matching as well.

Will definitely give it some more playtime. ;)

Tuism

Thanks @konman :D

Yeah right now the tutorialisation is just not there. But I actually want to build the game *so clear* that it doesn't need that. From my personal perspective I have so much frame reference into this world of games that I can practically pick up any of its type without tutorial and be able to play it - but I absolutely understand that I'm dealing with a VERY different populace of people here (Westerners!) and I think half of you haven't played half of the games of this genre that I've played.

So the context is missing and THAT is important. Regardless, I *still* want to add more juice to it to make it as immediately understandable as possible. Was there anything in particular that you really struggled to understand initially?

SPEED. Right now that's my biggest bugbear with this - I love the music system, how it can match the pace of the game precisely. But I'm struggling to find a good, fair and fun way to speed up/slow down the game. It was on a linear upwards climb until 150bpm, but then it just got brutal for most new players. I didn't want to make it a difficulty setting that you chose before starting the level, or just a linear trend going up (like it was)... I want it to be part of the play, but still be kept simple... Any ideas would be much appreciated :D

The "taps per minute" meter could be funny :P It's like Starcrafters with their Actions Per Minute or something. Not really the point of the game but yes it could be funny. There was a score in there, and that was pretty fun to build (chains multiplied your points exponentially, which is really satisfying) but I took that out for the two player matchup because it simply meant nothing. I'll implement that for a single player mode (like not versus even against AI.

Tuism

Hokay guys, I made a few changes to the latest build, still here:

http://www.twoplusgames.com/beatattack

1) Added a "connecting" visual cue to show that blocks connect. I realise a tutorial type thing is probably still necessary, but any juice to demonstrate mechanics is better than not :)
2) The speed change is now dependent on the gamestate - ie it slows down.
3) The win/lose thing is clearer at the end, you'll see.

Now I have some specific feedback questions! :D

1. Do you understand it initially? If not, what don't you understand?
2. Was it / is it too fast?
3. Have you played other games like this, and if so, does this feel different enough?
4. Did the giant animated heads make it difficult for you to read the game clearly?
5. Were there parts of the interface that didn't make sense initially?
6. Does the game make you want to "get better", does it feel satisfying making the matches then chains?

Thanks guys!! :D

Tuism

Getting ready for rAge... WHAT EVEN IS LOVE?! <3

http://instagram.com/p/t71TBit1cJ

Tuism

Beat Attack's rAge build is now online :) http://www.twoplusgames.com/beatattack :)

Thanks to everyone for giving Beatattack a try at rAge, it's truly been awesome and I totally forgot to ask everyone to help me make a video like this :(

mattbenic

Any chance of a downloadable build for those of us that the Unity3D plugin hates? ;)

Tuism

Your wish is my command :D And yeah I know my computer bombs every second instance of Unity3D plugin. I don't know why, just testing Dead Run before had been hell :/

Windows build right here!
http://www.twoplusgames.com/beatattack/beatattack_windows.zip

Gibbo

Goddamit @Tuism I have had that intro screen theme stuck in my head the entire weekend! :P

Beat, beat, beatbeatbeat, beat, beat, beatbeatbeat...

Tuism

Hey guys :)

So I tried an iOS build on my iPad 2, which is obviously not the fastest hardware these days, but I was wondering if there was a way to "simulate" the frame rate and speed of iOS while compiling and playing on desktop, because I was noticing that the frame differences was making the game feel different, like the lerping of objects between static states were taking longer (frame rate was probably lower, but then the game should be framerate agnostic, right?)

http://instagram.com/p/u3-GEIN1Ql

creative630

Are you using Time.deltaTime with your lerping? Then it should be framerate agnostic.
http://unity3d.com/learn/tutorials/modules/beginner/scripting/delta-time

There is also the fixedupdate function, but delta time should be fine for lerping etc. Fixed upate is for an update call that's more regular and mainly used for physics updates as far as I know.
http://unity3d.com/learn/tutorials/modules/beginner/scripting/update-and-fixedupdate

I'm not sure how to simulate slow framrates.

Tuism

I'm not using Time.deltaTime, but I am putting things in fixedUpdate.... I think most things are there. But I'll give it another check, I was wondering if it's something that duh :/ Guess it would be! Thanks!

critic

Yeah, in principle all the position adjustments (manual animation) that you make should be multiplied by Time.deltaTime, this way you are not reliant on the actual hardware, the constant you use with it is up to you.

As for slowing down the time or speeding it up you can set Time.timeScale (hope that helps):
http://docs.unity3d.com/ScriptReference/Time-timeScale.html

Nice game, you planning on releasing this?

dislekcia

Also, if you're doing any easing (making movements and lerps seem to accelerate or decelerate) the naive way of saying "move half the distance each frame" is super framerate dependent. That tends to keep coming up.

Tuism

@critic yeah the responses have been good, I still need to get the core to be sound (a lot of juice and feedback is as yet not adequate) and get, do some more testing with difficulty curve, and add a bunch of stuff like a progression and some things like different characters. More and better art, more music, etc. It'll still be a while!

@dislekcia yeah I realised the frame dependency stuff, I'm migrating everything over to FixedUpdate :) What, if any, is the better alternative to making easing stuff?

Kobusvdwalt9

Cant you multiply the lerp function by deltatime as well ?

x = lerp(curruntX, desiredX, 0.1f * 60/ Time.deltatime);

Also what about smoothdamp ?
http://docs.unity3d.com/ScriptReference/Vector3.SmoothDamp.html

SUGBOERIE

I hate using time.deltatime in the lerp function. What I like doing is using Animation curves which I can tweak for tweening.

float step = 1f / totalMovementTime; //frequency (how much it should move per "step") 
float elapsedTime = 0f; 
while (elapsedTime < totalMovementTime)
{
   float s = elapsedTime * step;
   float t = animationCurve.Evaluate(s);

   yPos = Mathf.Lerp(startPosition, endPosition, t);

   elapsedTime += Time.deltaTime;
   yield return null;
}

I like to have this in a Coroutine, So in your case (I'm assuming) the instance you pick up a block you start this coroutine. This will be frame independent using time.delta time to evaluate how far along the animation curve you're are at giving you the position you should be in the lerp. The reason I like to use animation curves is because I can tween it as I like very easily and the function just works. You've got to make the AnimationCurve public to see it in the inspector.

critic

@Tuism, I think fixed update fires every 0.02sec, which basically caps your update logic to 50fps. If the hardware is running slower, you are updating your animation more times than it's being drawn, on the other hand if the hardware is faster, you are still capped at the 50fps update frequency, essentially missing some draws...

Not sure if you need to worry about such issues for this project, since you are not drawing huge amounts of polys.

Tuism

@Sugaboerie most of what you got there is gibberish to me but I'll try and figure it out XD Although I'm not using time.DeltaTime, I'm using FixedUpdate... And even if it's capped to 0.02 seconds it's really not a big deal, it's not like I need super amounts of computation... I think, yeah?

@critic wait, so the 0.02 secs of FixedUpdate is a mandatory step that will always take up cycles even if it doesn't need the cycles... And so using FixedUpdate could actually lag the game out by computing too much?

When you say I'm not drawing huge amounts of polys I'm not sure what the standard is... I was testing the current, obviously un-optimised version on my iPad2, and it was laggy as hell :/ So I feel like I need to squeeze as much performance out of it as possible. And/or change the entire visual style... Right now the blocks are polys and that's probably taking up a fair bit of rendering, I can change them to sprites, which would be easier on the rendering, right?

critic

@Tuism, I think that the fixed update is an interrupt in Unity, it will fire every 0.02sec, I don't know the details, point being that Update fires on every frame and that's probably the best place for your animation position update.

Looking at your game I don't think you are anywhere near the lagging point when it comes to poly count, the current gen iPad can handle over 200k poly. There is a stats button on Unity game window that can give you some more insight.
http://docs.unity3d.com/Manual/RenderingStatistics.html

Elyaradine

Er... polycount and updating positions are different things, afaik. It's a lot more complicated than this, but super simplified the polycount is (usually) a GPU-related thing whereas the updating of the positions of things (usually) is a CPU-related thing. If you're trying to optimize the thing that isn't your bottleneck, you get no benefit whatsoever.

The Unity Profiler should help quite a bit with that (I assume you've got Unity Pro, given that you're deploying to iOS?), and you can also deploy builds with various things turned on/off to try and narrow down what the problem is.

Just looking at your screenshots and stuff, I'd try changing all of your shaders to not be using anything that takes any lighting whatsoever (like Unlit Texture or something), and see if there's an improvement. (I mean, it's possible you've baked your lighting onto your 3D geometry, but I suspect you didn't.) It'd probably also be useful to get some kind of FPS/mspf display going on device, so that you can see with actual numbers whether what you've changed is an improvement or not, rather than guessing. I imagine a script for that must be on the Unify wiki or something, because it's super handy.

Also, @AngryMoose is, like, the best person to talk about this stuff BY FAR.

critic

Well if you are updating the position of your polys 3 times per draw instead of once it can have an effect, an effect that probably wont be notable on a puzzle game, yet a problem when working with numbers that are close to the limits of the device.

@Tuism, do those blocks have top/bottom/left/right/back sides? If they do you can probably safely get rid of them.

AngryMoose

Tuism said:

if there was a way to "simulate" the frame rate and speed of iOS while compiling and playing on desktop

If you are using Time.deltaTime in a standard Update loop, (and if you're not, you really need to learn how to! All game updates should *always* be frame-rate independent!!!), then you can set the maximum framerate in Unity via Application.targetFramerate (ie. -1 means as fast as possible, 10 means 10fps, etc.).

Alternatively, if you're using FixedUpdate (which like was said above, is generally used for consistent Physics updating), then you can adjust the frequency to be less in Edit->Project Settings->Time->Fixed Timestep.... setting Application.targetFramerate will also affect the maximum frequency in which FixedUpdate is called as well.

Remember though, even if you want FixedUpdate to run at 50ms (0.02), if your application's frame time takes longer than that to update and render, you're going to get messed up as no matter what you do, your app cannot time travel :)

Tuism said:

my iPad 2, which is obviously not the fastest hardware these days

iPad 2 is actually still one of the best graphically performing devices out there when comparing GPU power to pixels rendered. It's going to lag behind in terms of CPU compared to more recent devices, but in terms of pushing pixels when comparing apples to apples, it's still right up there.

As for general mobile performance, your 2 killers ARE ALWAYS going to be 1) DrawCalls (if you're > 150 you're doing it wrong!!!) and Fillrate (more than 2 or 3 full screens of pixels are likely going to hurt you, depending on your shader complexity->doubly so if they are alpha blended pixels).

critic said:

Well if you are updating the position of your polys 3 times per draw instead of once it can have an effect

You're only every going to get any benefit of greater physical updates vs. visual updates when you're talking physics integrations or collision detection. For merely updating visual items, one update per render is always going to be sufficient; any more and you're just wasting CPU cycles that could let you get another few Drawcalls out :)

Tuism

Thanks everyone for your inputs!!! :D It's been super valuable, and now I know a bit about draw calls :D Thanks @elyaradien for a super helpful call last night :)

Last night I took a snapshot of my game stats while running:


And today's results:


Yay! So what I did between the two:

1. Changed all the blocks geometry to sprites (they're pretty much ugly placeholders for now :P)
2. Deleted two lights that were unnecessary (they were providing the shading in the gems because they were 3D), left one light to light the two models in the background.
3. Changed most things from FixedUpdate to Update (there was one or two things I couldn't move because they were game-breaking but I need to fix that eventually)
4. Implemented the lerp with deltatime thing (@kobus your formula appears to be wrong? I eventually just went with a * time.deltaTime thing without the division and it works)

So now it runs fairly ok on iPad, but still lags when things get full... Though it's still playable. Is it actually still a graphical bottleneck, or is it now computational? How do I tell on iPad?

I have an idea of what to still do for performance, but these are harder and will take longer:

1. Convert the system to Grids (I'm currently using my own system that uses blocks' xy positions to calculate their position in their 2D array... Which is probably terrible)... I've started with this but Unity Grids is kinda hard to get to grips with so I'm stuck :P
2. Pre-create all instances of the blocks (and popping particles?) instead of instantiate/destroying them <-- is this a major thing? It'll be a hectic system to implement :/
3. Simplify the 3D models in the background by rebuilding them and UVing + texturing them.

Slightly concerned that even in a stripped-down version it's straining the iPad2, I still have yet to put in stuff like backgrounds and more pretty things, which I want to, eventually. Is this just iPad2's limitation and I can't hope too much from it?

Are there anymore things to watch out for?

You guys are the bestest :)

AngryMoose

Tuism said:

Is it actually still a graphical bottleneck, or is it now computational? How do I tell on iPad?

Only way to really know is to use either the Editor Profiler (you need Pro) or at least, the Unity Built In Profiler.

Chippit

Tuism said:

Slightly concerned that even in a stripped-down version it's straining the iPad2, I still have yet to put in stuff like backgrounds and more pretty things, which I want to, eventually. Is this just iPad2's limitation and I can't hope too much from it?

As @AngryMoose said above, the iPad 2's actually pretty excellent target hardware. At the time of release, it was one of the best performing devices for Bladeslinger, and we managed to squeeze quite a lot out of it from a graphics perspective.

Basically, to reiterate on what @Elyaradine said, you can't really guess when it comes to performance stuff. There is only one hard rule, and that's to measure first, then fix what is ACTUALLY slow. There are good practises in literally every domain of game development that affect things, but the degree to which they do varies based on what your actual bottlenecks are, and what kind of game you're making. I recognise that's not necessarily useful advice in this case, but them's the breaks.

So short answer is, run it through the profiler. If you don't have Unity Pro, now's a good time to buy it. The profiler is literally the most important reason to have Pro, perhaps second only to getting rid of the Unity splash screen and giving your product that extra professional touch. If you HAVE Unity Pro and you need help interpreting that stuff, feel free to PM me and I'll help where I can.

EDIT: Ninjaaaaed

mattbenic

3. Changed most things from FixedUpdate to Update (there was one or two things I couldn't move because they were game-breaking but I need to fix that eventually)

You want to fix this now, probably before any more performance work. Having your object updates incorrectly split between Update/FixedUpdate can result in artifacts that _look_ like performance issues visually, but actually aren't.

+++ on measuring before "fixing", chances are you're "fixing" the wrong thing. First step here is @angrymoose's suggestion of the text logging profiler, at least you'll get an idea of if CPU or GPU is your bottleneck. It's still not going to be nowhere near as good as having the Pro profiler, but it'll narrow your search down a bit.

2. Pre-create all instances of the blocks (and popping particles?) instead of instantiate/destroying them <-- is this a major thing? It'll be a hectic system to implement

So as much as I agree with measure before you fix, at some point (soon) you should probably look at pooling these objects (have a system that creates the objects if asked for one and it's not available, and then recycles them once they're no longer in use). If for no other reason than these are probably going to lead to nasty occasional hitches even if you do get the rest running smooth as butter. This is an allocation thing, and unlike the CPU/GPU determination, the only way you're really going to get an idea of how bad your per per-frame mem allocations are is the profiler.

Tuism

Thanks for another round of great input! I'm using the built-in profiler for now to see how far I can get. As for getting Pro, I think that I'll eventually have to get it. Eventually... But for now I want to keep my costs down... Is that wise or not so wise? (opinion time!)

On the built-in profiler, I have a question for you guys, this is an example of the output:

iPhone Unity internal profiler stats:

cpu-player>    min: 77.3   max: 86.7   avg: 81.2

cpu-ogles-drv> min:  5.1   max:  8.3   avg:  6.7

cpu-present>   min:  0.7   max:  3.2   avg:  1.5

frametime>     min: 83.6   max: 97.2   avg: 89.8

draw-call #>   min: 142    max: 213    avg: 180     | batched:   245

tris #>        min:  6292  max:  9670  avg:  7032   | batched:  4332

verts #>       min: 11009  max: 17765  avg: 12490   | batched:  7033

player-detail> physx:  6.0 animation: 52.0 culling  0.0 skinning:  0.0 batching:  4.5 render:  9.5 fixed-update-count: 4 .. 5

mono-scripts>  update:  6.5   fixedUpdate:  1.1 coroutines:  0.0 

mono-memory>   used heap: 372736 allocated heap: 524288  max number of collections: 1 collection total duration:  1.6

I checked it against Unity's documentation on it (http://docs.unity3d.com/Manual/iphone-InternalProfiler.html), and I found a few things missing, like cpu-waits-gpu... Which I understand as the prime number to look at while trying to figure out if the bottleneck is with the cpu or gpu? Or does the number's absence mean it's zero and the gpu is always waiting on the cpu?

Or, is there some kind of setting I'm missing that would show that number? I can't find it :/

Chippit

Tuism said:

player-detail> physx: 6.0 animation: 52.0 culling 0.0 skinning: 0.0 batching: 4.5 render: 9.5 fixed-update-count: 4 .. 5

That there is an enormous problem. I can't imagine what it is you're doing that causes this, but 52ms spent updating bones is far, far more than any game can manage. For something so timing-heavy, you're going to want to reduce your ENTIRE frametime to sub 16ms, so that it's as smooth as it can be.

Focus on this. Once you isolate and fix the cause, it will likely affect the profiler in other ways, in which case you can sample again and see where new bottlenecks arise. There are other red flags in the data there, but with optimisation, you should always focus on the biggest hits first, because once they're resolved, some other bottlenecks can fall away, and new ones can appear.

Are you using Unity animations heavily? What for? Could you do whatever it is you're doing here in some other way?

Tuism said:

I checked it against Unity's documentation on it (http://docs.unity3d.com/Manual/iphone-InternalProfiler.html), and I found a few things missing, like cpu-waits-gpu... Which I understand as the prime number to look at while trying to figure out if the bottleneck is with the cpu or gpu? Or does the number's absence mean it's zero and the gpu is always waiting on the cpu?

Or, is there some kind of setting I'm missing that would show that number? I can't find it :/

The lack of the number means the CPU's likely not waiting on the GPU ever. With your 90ms frametime (~11fps), I can't imagine that will ever happen, so that's why you're not seeing it.

mattbenic

Ignore me. @chippit is too fast

Gazza_N

At this point, although I know nothin' 'bout nothin', allow me to reiterate the suggestion I made on Twitter a while ago to use position and rotation lerps to wibble the head models around programmatically, rather than using the bloated animation system. :P

AngryMoose

Tuism said:

cpu-player>    min: 77.3   max: 86.7   avg: 81.2
frametime>     min: 83.6   max: 97.2   avg: 89.8

Woah. Yeah. 12fps be slow for a puzzle game! No reason that you should be able to to 60fps for what you're doing, even on 4 year old hardware. You're 100% definitely CPU bound.

Tuism said:

cpu-ogles-drv> min:  5.1   max:  8.3   avg:  6.7
draw-call #>   min: 142    max: 213    avg: 180     | batched:   245

This is your Drawcalls coming to bite you. iPad2 DCs should be <= 80 for it not to affect the CPU. You're going to need to make sure you're batching properly, which means sharing materials efficiently, and not changing material properies of individual objects which will then break the batching.

BATCHING IS ONE OF THE MOST IMPORTANT REALTIME GRAPHIC CONCEPTS TO UNDERSTAND AND MASTER IF YOU WANT A PERFORMANT GAME ON MOBILE!!!

Tuism said:

player-detail> physx:  6.0 animation: 52.0 culling  0.0 skinning:  0.0 batching:  4.5 render:  9.5 fixed-update-count: 4 .. 5

Physics? What are you doing physics-wise? Ahhhh... I bet you have a lot of Static Colliders being moved around every frame don't you? Make sure that isn't happening! So if you have Colliders on all of your blocks, and you're moving them around all of the time, Unity (Physx) is going to be doing a lot of re-calculations of it's physics system.

Animation? I've never, ever, EVER, EEEEEVVVVEEEERRRRRR!!!! seen 52ms taken up by animation. Ever. Woah. You're doing something fundamentally wrong there for sure... not sure what you're animating... do you have like, 67000 bones in each of your characters?? Does each of your blocks play an animation constantly? Possibly 37 each?

This is your big issue. Fix this before anything. This should be like 1 to 3ms. Tops. For a character game with 6 3000 vertex skinned characters fighting each other.

Tuism said:

mono-scripts>  update:  6.5   fixedUpdate:  1.1 coroutines:  0.0

That's on the high side for the update loop of a puzzle game. You're likely doing some intense math or logic that you don't need to. This shouldn't be more than 2-3ms tops really, unless you're doing something cray cray.

Tuism

"updating bones"... Eh? I'm not sure what that means, what contributes towards that number?
Mecanim animations? Is there a wrong way of doing the animations? Is it wrong to animate each sprite separately in mecanim? Do tweens of big value changes make things slow?
Particles?

I use unity animation (mecanim and the dope sheet things, right?) in these instances:
1. The two heads animating in the background.
2. When a block is lined up to destroy itself, doing that scaling animation.
3. That big diamond in the background animating once per beat

I think that's it for now. I don't know if these count as animation?:
1. Trails?
2. Tweens by maths (lerping and such)

Chippit

So if I understand you correctly, every single block has an animation/animator component on it? If this is the case, and you're not already doing this, make sure you TURN OFF the component when it's not actually playing anything ,and then turn it on just for its destruction animation. I can't say that this is necessarily your problem, but I don't imagine having a huge number of those idling about is a good idea.

petrc

iTween is great form animation tweens

http://itween.pixelplacement.com/

So you can replace the mecanim animations with it

AngryMoose

petrc said:

iTween is great form animation tweens

NNnnnnnnnoooOOOO000oo000oo000ooOOOOO!!!!!!!

Avoid iTween like the plague. There are other, better Tweening libraries that you can use for Unity that don't generate constant garbage like iTween does. If you don't keep tabs on garbage generation early on in your mobile title's life, you're going to have major issues trying to clean it all up when it comes time to ship your game without constant GC hitches.

mattbenic

Why does everyone keep recommending iTween!? It's an absolute performance nightmare (despite the author's claim to the contrary).

Literally second google hit on "unity tweening library performance": http://dentedpixel.com/developer-diary/leantween-speed-comparison-to-itween/

petrc

Calm down guys. I wasn't trying to give you a stroke.

I've used itween before and didn't have any gc issues with it.

But thanks for the shout, I won't use it again. leantween looks like the way to go.

Tuism

Yeah we (me and @loet) used iTween when we were making Dead Run, and it literally was responsible for the game being unplayable on mobile for the first month of testing before we tossed it.

So *that* I get :)

Tuism

Thanks to your guys' insights, amazing people, here are the latest results:

iPhone Unity internal profiler stats:
cpu-player>    min: 26.7   max: 30.2   avg: 28.5
cpu-ogles-drv> min:  7.4   max:  9.1   avg:  8.3
cpu-present>   min:  0.7   max:  3.0   avg:  1.1
frametime>     min: 35.7   max: 42.4   avg: 38.2
draw-call #>   min: 230    max: 265    avg: 248     | batched:   173
tris #>        min:  5192  max:  7206  avg:  5834   | batched:  3175
verts #>       min:  8693  max: 12721  avg:  9977   | batched:  4617
player-detail> physx:  2.2 animation:  0.4 culling  0.0 skinning:  0.0 batching:  3.8 render: 13.5 fixed-update-count: 1 .. 2
mono-scripts>  update:  6.0   fixedUpdate:  0.8 coroutines:  0.0 
mono-memory>   used heap: 430080 allocated heap: 786432  max number of collections: 0 collection total duration:  0.0

animation went to 0.4 because I turned all the animators off, which is amazing. I'll make another build later where I turn them back on and see what happens. Right now the game runs much smoother, BUT, I'm getting quite big swings between lag and non-lag, while the game catches up between dropped frames, feels like it happens more noticeably than before.

So the next project is A) Grids and B ) Pooling :/

mattbenic

Calm down guys. I wasn't trying to give you a stroke.

Can't calm down.. the iTween scars are still just too fresh O_o

Elyaradine

I'd address the draw calls first, since they're around 3x what you'll want them to be. I'd get rid of the light and the shaders that use lighting. (Can add them back to look almost identical, but much cheaper, later.)