I don't think you'll gain much from pooling at all. They're not necessarily going to make any of your update times any shorter. Pooling will reduce your GCs, but it looks like that's not even a big problem for you (sub 2ms GCs are pretty fast), probably given the relative flatness of your heap. Using Grids might not help you much either, unless its flexibility allows you to perform new optimisations that are not trivial to do with your current architecture (whatever that is).
Next I suggest that you want to look into what @Elyaradine is saying. If you ARE using realtime lighting, that practically doubles your draw calls (or worse). You can very easily replicate the 2D lighting look without that cost, and it should help bring your render time down a LOT. Make sure you have things like shadows disabled everywhere too.
Once that's been taken care of, the biggest thing remaining is the comparatively high 6ms script update, which suggests your scripts are probably doing a whole lot more work than they should. Optimising this without the Unity profiler will be VERY difficult, though. This is also the part where optimisation quickly becomes VERY technical and complicated.
Just wanna confirm something with you, you said that pooling and grids won't gain me much benefit, but you then also said that the 6ms script updates are doing a lot more work than they should, to me, that seems contradictory, or am I missing some vital bit of understanding on this?
I'll give dismantling my lighting a shot and see what benefit that gives. I keep hearing about baked lighting but I'll leave that kind of stuff till later. Alternative ways of simulating 3D would be A) Using UV textures to paint darker/lighter shades in B) Using some kind of shader magic to calculate a colour according to angle of a face's normal to the camera - would these be a lot faster than running lighting, basically speaking?
@Tuism: Speaking as sort of a non-programmer here, so I may be wrong, but there are countless dumb things you can do in your scripts that make them slow. Using pooling or Grids may or may not help for the reasons @Chippit mentioned above, but it's possible (and pretty likely) that there's something silly that you're doing elsewhere in your code.
Check if there are things that you're doing in your Update() that don't have to happen every frame, and add conditions so that large blocks of more expensive code only run if that really have to.
But definitely do the draw call thing first, because that's probably still the biggest bottleneck.
And yeah, you'd either texture your model to have those different planes of colour, or you'd write a shader that just brightens/darkens a surface depending on where it's facing. I imagine you'd rather go for the latter, because that'd change the brightness as your models move, as opposed to the texture where it stays the same no matter how your model rotates. I'd also probably rather have the shader use the angle between the normal and the world-up direction rather than the camera (because that's closer to what you've got right now), but I guess that's more of an artistic/stylistic decision. And yeah, the Unity shaders do a bunch of extra stuff when they're doing lighting, and you're not really in control of what those are. They may or may not be taking a light colour, or be catering for different types of lights, or be doing light attenuation, or be checking for lightmaps or light probes, or be doing shadow calculations and rendering to a shadow map, or a bunch of other things... where your custom shader could just checking for one dot product.
Just wanna confirm something with you, you said that pooling and grids won't gain me much benefit, but you then also said that the 6ms script updates are doing a lot more work than they should, to me, that seems contradictory, or am I missing some vital bit of understanding on this?
So neither pooling nor using the grids API are magic bullets that are going to make your game run faster. Chances are very likely that both of them will INCREASE your code overhead, in fact.
Pooling is generally a more complicated manner of managing objects that are created frequently. This isn't going to make your scripts execute much faster (if at all faster). What it really achieves is minimizing allocations, which means the garbage collector is going to run less frequently, meaning you're going to get fewer GC hitches when it has to collect. Judging by your previous few pastes (which aren't authoritative by any means, mind you) your GCs are already fairly infrequent, and they're also executing (fairly) quickly. GCs will cause frame time spikes, but they might not even be noticeable. Pooling will only really help with these, nothing else.
As for Grids, this is a remarkably advanced and complex API we're talking about. It's incredibly flexible, it'll potentially make some of your tasks easier to manage and more elegant to handle, but it's almost certainly more likely to make your script execution time SLOWER rather than faster, simply by virtue of bringing in and interfacing with far more complicated systems than the ones you're likely to have written. Perhaps Herman might be a bit upset at me for saying that, because using it will almost certainly make your life easier (and his life happier!), but it's probably way too late to make use of it anyway, since your game is already working. You'd have to restructure quite a lot of things to make use of it, and technology like this isn't something you want to bring in once you already have the mechanic working. It's something you want to use to facilitate the creation of that mechanic, not necessarily to refactor an existing mechanic into.
I should also disclaim at this point that I use Grids in two separate projects, and it's certainly saved ME from having to write a whole load of stuff myself, but in both of those cases, the technology was there from the start.
I've taken away all lights and materials that use lighting (and found a 2-line shader that's "No Texture"... Works pretty well, obviously loses all shading.), and here are the latest results:
The draw calls seems to have about halved from the previous one, and the scripts also seems shorter by about 1 (I checked against outputs throughout runtime and it seems to be consistently around this value).
I'm pretty sure there are some particles and things I can still simplify further... Time to delve into my code to optimise like a good little dev, though it's already running a hundred times better now than before :D Thanks guys!
And further down the line I'll look into the faking the lighting according to global up shader... I tried to do something according to ye olde shader tutorial thread but I couldn't get my head around it right now...
Oh, the base shader I found, in case anyone's interested:
Would be nice to halve them draw calls again, but I'm not sure where I'd look next without playing around with your scene.
-- Could try something like this shader for your 3D geometry. If you keep your models pretty blocky, this should be fine I think. There are a bunch of things that are exposed there to help with customising to get the look you want, but if you're not using them, you can take them out.
Just watch that Fallback... it's going to go to a (relatively) expensive lit shader, instead of say, Mobile/Unlit which is probably better... though, even more likely in this scenario would be to kill that Fallback line entirely; you don't really need to 'fall back' to a cheaper version of this shader in reality :)
Also, have I taught you nothing @Elyaradine!?!?! In vert(), you can get away with fixed3 for the 2 normalized normals used for the lighting dot product :P
Also, have I taught you nothing @Elyaradine!?!?! In vert(), you can get away with fixed3 for the 2 normalized normals used for the lighting dot product :P
Gah, they weren't normalized until later, and and and and
I don't think you'll gain much from pooling at all. They're not necessarily going to make any of your update times any shorter. Pooling will reduce your GCs, but it looks like that's not even a big problem for you (sub 2ms GCs are pretty fast), probably given the relative flatness of your heap. Using Grids might not help you much either, unless its flexibility allows you to perform new optimisations that are not trivial to do with your current architecture (whatever that is).
Yup, definitely not something that'll make an epic difference. Like you say, the only reason is GC. And yeah until you're actually seeing those jerks and concerned about them, focus on other things first.
Once that's been taken care of, the biggest thing remaining is the comparatively high 6ms script update, which suggests your scripts are probably doing a whole lot more work than they should. Optimising this without the Unity profiler will be VERY difficult, though. This is also the part where optimisation quickly becomes VERY technical and complicated.
+++ You really, really want to be using the profiler by the time you're doing this. The profiler can actually connect to versions of the app built with the "development" flag set and the "connect to profiler" flag set (both in File->Build Settings). If you make your next downloadable PC build with those settings, maybe you'll be lucky and someone charitable with a Pro license will take a peek ;)
Slight (ok major) update, I can almost use fancy words like "vertical slice" here :)
Featuring: - JUICE. So much juice. - You can now turn your ship/cursor. - Power bar for attacks - ATTACKS. Not only attacks... They're asymmetrical! - A count-in to ease first time players in. - Expressions - Screenshake
Build will be at the meetup tomorrow, and I'll upload to playable too. Been thinking of getting onto Gamejolt. Will probably do that.
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):
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
I'd like to ask... Why is feedback on Beat Attack so thin? I've worked hard to make sure that it's accessible and playable and has pretty pictures and animated gifs and (now) a video...
Is it because it looks like a game you don't understand? Is it because it looks like a game you're not interested in? Is it because it looks like you can't play it single player? (you can!) Is it because it doesn't look like there's been much updated since the beginning? Is it because it's not controversial? :P Or anything? Just tell me anything at all! XD
Just really want to get a handle on the whys so I can work on it and make it better, otherwise I can only take the lack of feedback as this isn't something I should put further effort into and work on something else...
----------------------
New: Gameplay video of the game in Turbo Mode, so you can hear Tim's awesome thumping track in action (and the chaos at 170bpm)
@Tuism: I think that there's a lot going on in those screens and it's probably not a game type that many people have played before... Puzzle attack games need a lot of visual training to understand at a glance, so it's not even obvious what the player is actually DOING in your gameplay gifs.
I'd suggest making a slowed down step-by-step gif that makes what the player is doing waaaay more obvious. Like: Point at the ufo, tell players that this moves with the beat; Freeze game, point at a piece, tell players they can pick that thing up when a UFO is over it, watch it getting picked up; UFO moves, freeze game, tell players they can make MATCHES with other pieces of the same colour, point to an upcoming match; Let the UFO move to above the match, freeze game, make it obvious the player pushed something; Watch the piece fly down, see the match happen, emphasise the crap out of the consequences, etc.
I guess the game just looks really, really busy but also looks really, really GOOD. It's a pretty game! I think maybe people aren't sure how to comment on it without investing lots of play-time and if they can't imagine that play, then that's harder? I dunno. ... I will say that the block throwing and missile attacks don't seem to be too telegraphed though - 5 missiles flew over, but only 3 cross blocks appeared? I can't even read what's going on with the block flinging attack :(
There are two things about that: 1) I've been trying to reduce the learning curve in the game itself 2) If I had to explain everything verbatim (either in the game or outside the game), doesn't that already mean the game is probably not going to work? If people don't or can't "get" the game, isn't it a good yardstick that it won't work?
Expanding on point 1 - I had been worried about that for a while... One of the things I tried hard to achieve is to try and introduce the player into the concept of the game. For that, I have ideas for the main menu - so when the player selects an option, a ufo picks it up, but that'll take some time to implement, and also I'm worried that it might give the wrong impression to the player for the game play (I tap on the menu item, the ufo comes to it and picks it up. In game - I want to tap on a block to pick it up... Why can't I?).
So now I have, before each round, a "ready?" screen where both players have to pick up a block before the game starts - the idea is that starting the game outright is confusing and waiting for a player input, they'll see the interaction.
The missiles - what happened is that they turn an opponent's block into X on impact, when only 3 blocks appeared it's because some of the missiles impacted blocks that were already Xs. So no effect. The missiles used to go through other Xs so that you'll always have an X if they didn't fly off the screen, but I changed that due to balance reasons - too many Xs made the ability too strong. I can understand the confusion, though. Maybe I'll make the missiles spawn an X instead, but again, the balance will be off.
The toss attack currently throws random blocks towards the opponent's side, I tried various combinations of selecting which blocks to throw and found random was the easiest, as the power is to throw X blocks over, depending on the level of attack. Is it confusing because one of the trails messed up? (That's a bug and I shouldn't have gif'd a bug...)
Attacks do generally need better telegraphing - between the chains generating power to an attack taking place, I still need to put in juice to emphasis them. But then that's more visual noise XD
----------------------
Your idea of explaining each bit of the game sounds great, and I do think I should do that - but again, does that not defeat the point of trying to communicate the game *in* the game? And is it worth pursuing this game if it's not something easily understandable?
Trying to get a balance of level-headedness and pure enthusiasm :/
Okay, so I was mostly talking about things OUTSIDE the game to help players understand it when they see promo material, or this thread, or whatever. Ingame tutorials are a completely different beast and there are a few things that I'd do there to push stuff into "Oh, I understand this!" territory.
1. Make the player play alone first, then bring the enemy AI in once they've managed to create a few combos... Or once they do a successful attack: Blocks fly offscreen and then this angry shark rocks up going "WTF?!" and starts fighting back.
2. When playing in single player mode, have the player's block area be more visible: Bigger, not all the way to the left of the screen (and certainly not UNDER the UI buttons there); de-emphasise the AI's space by moving it more left and making it smaller, etc.
3. I think the real problem is communicating goals to the player. Once the player knows what their goals are, they'll start forumlating HOW to get there. A lot of puzzle-fighter players will understand the implicit goal here, fill the other player's side with blocks. But I honestly can't tell if you make this goal explicit to players in any way, it feels like a tacit assumption that they'll want to do this. Also, make sure that once they realise this is what they need to do, only then should you start showing them how they can do it with direct block pickups, etc. An experienced puzzle-fighter player isn't going to get annoyed by any of this, but a new player is going to get onboarded way faster.
From my side, I'm blaming Eskom for not trying the new build yet. Have had no electricity every evening after work this whole week and my phone is super crap. Pretty sure others have had similar experiences this week. Will def give this a try as soon as I can, and give proper feedback then. From the gifs I can say that the amount of visual feedback on screen is quite intimidating and makes they game seem difficult. Also sound is a big part of this experience and not everyone has speakers or headphones on all the time.
So after trying this at the last meet, I really, really think it's worth continuing. I'm not going to re-state my comments from the meetup, but I have been thinking about one major thing: your plan to aim primarily at mobile. A few things stand out to me: -I would think punting a mostly multiplayer game is going to be even harder than an SP one, and we already know how hard it is to get users on mobile. I know you're working on the AI, but the real attraction of a puzzle fighter is always the multiplayer. -This game is busy, VERY busy, and that's on a PC monitor. On a phone screen, that's going to be compounded. -Adding to that busyness: fat fingers on screen!
Hitting steam seems like a no-brainer, but I wonder if you shouldn't be aiming for one of the consoles as well, maybe even as primary? How are their indie marketplaces working out? Perhaps @DaveRussellSA can weigh in on the Xbox side of that? It just seems to me like the most fun I've ever had with those kinds of games were in an arcade or on a console, where two players sat together in the same space.
Thanks for everyone's input! It's all super valuable to me! Now that #LDJAM is done for now, let me get back to this discussion:
@dislekcia - Thanks for the suggestions about presentation to first-time players, tutorialising the presentation, if you will.
What I'm most concerned about is "is this game attractive enough to chase into a full game?", which means, to me, that it should be attractive to people who see it without tutorials, without having to be taught how it works (of course teaching helps, but I can't have every piece of promo material being "how to play Beat Attack"). To that end, is it, as a core? I'm concerned that the lack of uptake here is a good indication of the lack of uptake "out there".
I'm not convinced that's something that can be fixed by tutorialising or creating teaching material. Is it? I guess I should just try it anyway?
-------------------
@mattbenic - Thanks!! Yeah I think I find Beat Attack in a bit of dilemma. The core of it came from the desire to play a puzzle battle game on a mobile format - the controls and such are designed that way. Is it worth re-engineering the pitch from "mobile-perfect puzzle battler game" to "one button puzzle battler game" and shift the focus to PC and such?
Otherwise, should I just dump the one-button control mechanic and go for a more conventional left and right and action button control scheme? It will completely lose the "rhythm game" angle - the music still plays, the game works as before, but the player will have complete freedom to move as they want to. It's not *bad* per se, it's just what it started out as, and can be seen as very similar to existing games, if it wasn't very derivative already.
If we think targeting PC/console first as a one-button game, going to mobile could be a bonus, anyway.
I totally believe that the most fun with this kind of game is to be had with two people in the same space, which was where the original concept came from... Wanting to play it with friends anywhere on the most portable gaming device I have (with the biggest screen)... On my tablet :)
Thanks again all!
--------------------------------
@FanieG - yeah I'll try to reduce the visual clutter. I wonder if that's got to do with the buttons being big and there being text on the screen (numbers and such). Does the animated background make it feel more cluttered?
Why are your one button games always actually two button games? :P
So when you say you originally targeting mobile, it sounds like you actually mean tablet? Or am I misunderstanding you. To me, Mobile is a phone, tablet doesn't fall into that category. They have some similar challenges (touchscreen, typically single-user, limited hardware) but each has unique aspects as well (how and when they're used, screen size-even if top end phones all seem to be phablets these days).
Have you tried having two players on the same phone or tablet? Whichever of those devices you're trying for, I'd say playtesting on a PC with a keyboard will really only get you so far-and IMO you've past that point.
As for repositioning/rebranding it for PC and console, I don't really see that as being necessary. It's a rhythm puzzle combat game, simple as that. Sure it happens to be 2 button rather than full directional control (no, I don't think that needs to change), but that's not really relevant to how you present it.
Yeah... because they start as one button, and eventually I find the *need* for a second control... le sigh.
And you're right, I realise that it doesn't work very well on phones. So yes, for tablets, not phones. The single-player aspect could fit the phone, but not the duelling side of the game.
If I continue with this I will definitely create a single-player-centric version of the game that's focused more on the rhythm and speed aspect over the versus aspect. In fact I could make that game first before doing the two-player one, that could be the easier way of going about it.
I have tried it with a tablet, I got it running on my iPad after that meetup. I'd say it works better than keyboard because the controls respond even faster than keys (no "travel" time between pressing and getting a reaction, but that's subjective). I still need to figure out/implement how to distinguish between a swipe and a tap though.
If this is for tabs the animated background is fine. My concern was also that it would be too busy for mobile/phones. It would be really cool if you could do an android build for this. Then I would be able to test the crap out of this for you :) I get really bored in my lunch time.
My 5 cents for what it's worth (taken from watching the video): I found that either the music track or the sound effects were off beat and when the game speeds up its sounds like it gets worse. For a game based on beats shouldn't all the sounds line up on the same beats? Do the game sounds differ from the music track in regards to tempo? Also a bit tricky to distinguish what is a game sound and what is the music track. If the sounds lined up with the song then they could in a sense add to the music track itself. You could have the music be mostly bass and drumbeat while the game sounds could be the hihats etc.
From playing the game itself....I have no idea what i'm suppose to do...Did I miss a play guide or an instruction screen? Sorry for my noob feedback
@kidult That's interesting, how did you find it off-beat? Did the movement seem off beat versus the music, or were the notes in the music off-beat from another? The movement of the cursor cannot be "on beat" because what's "on-beat" should be the user's input, which means the movements happen at half-beat, so that they're finished by the time the beat drops, and the user should input at the beat... Hope that makes sense.
Imagine if you're supposed to punch something once a beat, but the thing moved ON the beat. Then you could very easily miss it by punching just before or just after the beat. The way it is now, the beat happens when the thing is still.
And yeah, the game lacks tutorial right now - all my effort at making the giant button obvious and adding trails haven't actually amended that. I'm building a single player mode that'll hopefully address that.
Also a bit tricky to distinguish what is a game sound and what is the music track.
As for the "game sounds", they occur at the speed of the music, as intended. Effects that happen on pick up or drop doesn't happen when the action occurs but when the beat drops, or else it felt really discordant and messy. Did you feel like you were confused because of the sound effect not happening when you pressed the button?
Do you feel it matter if you can distinguish "sound effects" from "backing track" easily? Why? How did it make you feel?
Mmmm.... so having played a few rounds and figuring out what to do (hey simply pair 4 of the same colours, got it!) I will say that maybe the sound isnt that much of an issue. Perhaps the youtube clip got the sound slightly wonky. Sorry if I'm throwing you off here.
I understand the concept of anticipating the beat for the player to select stuff on the beat . In fact I think that part works very well. I straight away realized I was hitting things on a beat. So this is more related to the video you have here, I couldnt get to 170 bpm (either won or lost before it came around) It just feels that later at the higher bpm's it becomes very noisy and hard to hear the beats well. This may actually not be a big problem as at 170 bpm you arent really needing to anticipate beats. It does also sound as if a series of hihat sounds are completely out of sync with the track at the higher rate. I re-listened a few times and at 2:32 in your video, one of the track channels gets dropped and the track is more simplistic, here it doesn't sound out of sync anymore but as soon as that sound returns to the track it sounds off again so it may just be the music that is off (or its a youtube thing). I feel at the 2"32 part it sounds cleaner in general (music track) but I also realize that changes in the track help to set the atmosphere. The busier it gets the more hectic the game starts to feel. Perhaps the closer to "death" a player is the more sounds could be added to the track?
I should also point out that having a girlfriend who plays piano,a close friend who is a DJ (the kind that uses actual records and matches bpm by ear.) and another friend who is a drummer does make me more aware of beats matching up. Doesn't seem as if anyone else is bothered by the sound.
Also would totally play again and I'm not a big puzzle fan
It seems a common thread with my games, my attempt at "radically simplifying" "traditional controls" (all the air-quotes) has made Beat Attack stupendously confusing for people to understand from the get-go. So I've tried to address that problem with a single player mode that's less daunting than introducing people straight into the overwhelming two-player mode.
Disclaimer: this is all stupendously rough!
Gameplay video:
I'll post later about the changes I've made and why, but for now PLEASE PLEASE give it a blind playtest and see if you understand it without too much trouble.
All you should need to know: SPACE = tapping Z = tappon on the left side (turning around) (later this will be replaced by a swipe left/right gesture) Navigation is via mouse for now, sorry!
@Tuism - has anyone else reported an error with the web build on Gamejolt. It takes forever to load and then gives me a failed to initialize error when it's finished loading?
Argh, I don't know what's going on, whether it's Unity's fault or Gamejolt's fault or all browsers in the world's fault :/ I just tried it myself and it threw the same error... Guess we all have to live with standalone builds until Unity and browsers kiss and make up :/ Sorry for the inconvenience!
Same unity error on my side "Failed to load 3D settings" or something similar.
I've watched the video and I have to say that in it the music really doesn't feel tied to the way things are moving. It's almost like the beat (which is a bit tricky to follow, but that might just be because I've been playing Necrodancer so much) is happening and then the ship moves, which takes a bit of time. What I'd expect would be for the ship's new position (and thus my player button push) to line up with the beat happening, so that if I predict the beat I'm going to be rewarded with crisp gameplay and the piece will zip down in the lane and I'll feel awesome.
Something that doesn't help with the beat feeling delayed is the slow movement of the piece when the ship is holding it. That should really just teleport with the ship instead of moving over to it after the ship's already moved. The piece's trail doesn't help with this because it accentuates how the piece seems to slide around in an uncertain way instead of zipping directly up or down.
The decision to make the ship lerp instead of instant-jump was an aesthetic one, and the piece's lerping behind the ship was... A prototying issue that I hadn't really fixed yet. Mechanically, it works precisely - the piece lands and gets picked up on the lane it's supposed to without problem, but I see what you mean with the trail making it feel wrong.
I could: 1. Snap and force the movements of the piece to start AT the exact top of each lane. 2. Snap the ship and piece movement completely so that there's no lerping between beats... Do you think this is necessary?
I'll give those changes a try. Thanks @dislekcia :)
-------------------------------
Really not sure what to do with Unity now. Don't even want to try WebGL build... If you can I'd really appreciate downloading the windows/osx build to give the build a try! Thaaaaanks!
Comments
I don't think you'll gain much from pooling at all. They're not necessarily going to make any of your update times any shorter. Pooling will reduce your GCs, but it looks like that's not even a big problem for you (sub 2ms GCs are pretty fast), probably given the relative flatness of your heap. Using Grids might not help you much either, unless its flexibility allows you to perform new optimisations that are not trivial to do with your current architecture (whatever that is).
Next I suggest that you want to look into what @Elyaradine is saying. If you ARE using realtime lighting, that practically doubles your draw calls (or worse). You can very easily replicate the 2D lighting look without that cost, and it should help bring your render time down a LOT. Make sure you have things like shadows disabled everywhere too.
Once that's been taken care of, the biggest thing remaining is the comparatively high 6ms script update, which suggests your scripts are probably doing a whole lot more work than they should. Optimising this without the Unity profiler will be VERY difficult, though. This is also the part where optimisation quickly becomes VERY technical and complicated.
Just wanna confirm something with you, you said that pooling and grids won't gain me much benefit, but you then also said that the 6ms script updates are doing a lot more work than they should, to me, that seems contradictory, or am I missing some vital bit of understanding on this?
I'll give dismantling my lighting a shot and see what benefit that gives. I keep hearing about baked lighting but I'll leave that kind of stuff till later. Alternative ways of simulating 3D would be A) Using UV textures to paint darker/lighter shades in B) Using some kind of shader magic to calculate a colour according to angle of a face's normal to the camera - would these be a lot faster than running lighting, basically speaking?
Check if there are things that you're doing in your Update() that don't have to happen every frame, and add conditions so that large blocks of more expensive code only run if that really have to.
But definitely do the draw call thing first, because that's probably still the biggest bottleneck.
And yeah, you'd either texture your model to have those different planes of colour, or you'd write a shader that just brightens/darkens a surface depending on where it's facing. I imagine you'd rather go for the latter, because that'd change the brightness as your models move, as opposed to the texture where it stays the same no matter how your model rotates. I'd also probably rather have the shader use the angle between the normal and the world-up direction rather than the camera (because that's closer to what you've got right now), but I guess that's more of an artistic/stylistic decision. And yeah, the Unity shaders do a bunch of extra stuff when they're doing lighting, and you're not really in control of what those are. They may or may not be taking a light colour, or be catering for different types of lights, or be doing light attenuation, or be checking for lightmaps or light probes, or be doing shadow calculations and rendering to a shadow map, or a bunch of other things... where your custom shader could just checking for one dot product.
Pooling is generally a more complicated manner of managing objects that are created frequently. This isn't going to make your scripts execute much faster (if at all faster). What it really achieves is minimizing allocations, which means the garbage collector is going to run less frequently, meaning you're going to get fewer GC hitches when it has to collect. Judging by your previous few pastes (which aren't authoritative by any means, mind you) your GCs are already fairly infrequent, and they're also executing (fairly) quickly. GCs will cause frame time spikes, but they might not even be noticeable. Pooling will only really help with these, nothing else.
As for Grids, this is a remarkably advanced and complex API we're talking about. It's incredibly flexible, it'll potentially make some of your tasks easier to manage and more elegant to handle, but it's almost certainly more likely to make your script execution time SLOWER rather than faster, simply by virtue of bringing in and interfacing with far more complicated systems than the ones you're likely to have written. Perhaps Herman might be a bit upset at me for saying that, because using it will almost certainly make your life easier (and his life happier!), but it's probably way too late to make use of it anyway, since your game is already working. You'd have to restructure quite a lot of things to make use of it, and technology like this isn't something you want to bring in once you already have the mechanic working. It's something you want to use to facilitate the creation of that mechanic, not necessarily to refactor an existing mechanic into.
I should also disclaim at this point that I use Grids in two separate projects, and it's certainly saved ME from having to write a whole load of stuff myself, but in both of those cases, the technology was there from the start.
The draw calls seems to have about halved from the previous one, and the scripts also seems shorter by about 1 (I checked against outputs throughout runtime and it seems to be consistently around this value).
I'm pretty sure there are some particles and things I can still simplify further... Time to delve into my code to optimise like a good little dev, though it's already running a hundred times better now than before :D Thanks guys!
And further down the line I'll look into the faking the lighting according to global up shader... I tried to do something according to ye olde shader tutorial thread but I couldn't get my head around it right now...
Oh, the base shader I found, in case anyone's interested:
Shader "Texture Only" { Properties { _Color ("Base Color", Color) = (1,1,1) _MainTex ("Texture", 2D) = "" } SubShader { Color[_Color] Pass{ SetTexture[_MainTex] {Combine texture * primary} } } }--
Could try something like this shader for your 3D geometry. If you keep your models pretty blocky, this should be fine I think. There are a bunch of things that are exposed there to help with customising to get the look you want, but if you're not using them, you can take them out.
Shader "Custom/FakeLight" { Properties { _MainTex ("Base (RGB)", 2D) = "white" {} _Color ("Base colour", Color) = (1,1,1,1) _LightCol ("Light colour", Color) = (1,1,1,1) _ShadowCol ("Shadow colour", Color) = (0,0,0,1) _LightDir ("Light direction", Vector) = (0,1,0,0) } CGINCLUDE #include "UnityCG.cginc" sampler2D _MainTex; fixed4 _Color; fixed4 _LightCol; fixed4 _ShadowCol; half3 _LightDir; struct v2f { half4 pos: SV_POSITION; half2 uv: TEXCOORD0; fixed4 tint: TEXCOORD1; }; v2f vert(appdata_base v) { v2f o; o.pos = mul(UNITY_MATRIX_MVP, v.vertex); o.uv = v.texcoord.xy; half3 norm = normalize(mul((half3x3)_Object2World, v.normal)); half3 up = normalize(_LightDir); half lookup = saturate(dot(norm, up)); o.tint = lerp(_ShadowCol, _LightCol, lookup) * _Color; return o; } fixed4 frag(v2f i):COLOR0 { fixed4 tex = tex2D(_MainTex, i.uv); return tex * i.tint; } ENDCG SubShader { Tags { "RenderType"="Opaque" } LOD 200 Pass { CGPROGRAM #pragma vertex vert #pragma fragment frag #pragma glsl_no_auto_normalization #pragma fragmentoption ARB_precision_hint_fastest ENDCG } } FallBack "VertexLit" }Also, have I taught you nothing @Elyaradine!?!?! In vert(), you can get away with fixed3 for the 2 normalized normals used for the lighting dot product :P
*control+F*
*vert()*
*replaces half3 with fixed3*
*runs*
STILL WORKS OMG
*feeling of accomplishment*
Thanks a mill guys, you guys are just too awesome for words ^^
T_T
You really, really want to be using the profiler by the time you're doing this. The profiler can actually connect to versions of the app built with the "development" flag set and the "connect to profiler" flag set (both in File->Build Settings). If you make your next downloadable PC build with those settings, maybe you'll be lucky and someone charitable with a Pro license will take a peek ;)
Featuring:
- JUICE. So much juice.
- You can now turn your ship/cursor.
- Power bar for attacks
- ATTACKS. Not only attacks... They're asymmetrical!
- A count-in to ease first time players in.
- Expressions
- Screenshake
Build will be at the meetup tomorrow, and I'll upload to playable too. Been thinking of getting onto Gamejolt. Will probably do that.
A little video:
https://instagram.com/p/1bv0g8N1eM/
(Are we getting our instagram integration back anytime soon?)
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
Thanks so much guys :)
Is it because it looks like a game you don't understand?
Is it because it looks like a game you're not interested in?
Is it because it looks like you can't play it single player? (you can!)
Is it because it doesn't look like there's been much updated since the beginning?
Is it because it's not controversial? :P
Or anything? Just tell me anything at all! XD
Just really want to get a handle on the whys so I can work on it and make it better, otherwise I can only take the lack of feedback as this isn't something I should put further effort into and work on something else...
----------------------
New: Gameplay video of the game in Turbo Mode, so you can hear Tim's awesome thumping track in action (and the chaos at 170bpm)
I'd suggest making a slowed down step-by-step gif that makes what the player is doing waaaay more obvious. Like: Point at the ufo, tell players that this moves with the beat; Freeze game, point at a piece, tell players they can pick that thing up when a UFO is over it, watch it getting picked up; UFO moves, freeze game, tell players they can make MATCHES with other pieces of the same colour, point to an upcoming match; Let the UFO move to above the match, freeze game, make it obvious the player pushed something; Watch the piece fly down, see the match happen, emphasise the crap out of the consequences, etc.
I guess the game just looks really, really busy but also looks really, really GOOD. It's a pretty game! I think maybe people aren't sure how to comment on it without investing lots of play-time and if they can't imagine that play, then that's harder? I dunno. ... I will say that the block throwing and missile attacks don't seem to be too telegraphed though - 5 missiles flew over, but only 3 cross blocks appeared? I can't even read what's going on with the block flinging attack :(
There are two things about that:
1) I've been trying to reduce the learning curve in the game itself
2) If I had to explain everything verbatim (either in the game or outside the game), doesn't that already mean the game is probably not going to work? If people don't or can't "get" the game, isn't it a good yardstick that it won't work?
Expanding on point 1 - I had been worried about that for a while... One of the things I tried hard to achieve is to try and introduce the player into the concept of the game. For that, I have ideas for the main menu - so when the player selects an option, a ufo picks it up, but that'll take some time to implement, and also I'm worried that it might give the wrong impression to the player for the game play (I tap on the menu item, the ufo comes to it and picks it up. In game - I want to tap on a block to pick it up... Why can't I?).
So now I have, before each round, a "ready?" screen where both players have to pick up a block before the game starts - the idea is that starting the game outright is confusing and waiting for a player input, they'll see the interaction.
The missiles - what happened is that they turn an opponent's block into X on impact, when only 3 blocks appeared it's because some of the missiles impacted blocks that were already Xs. So no effect. The missiles used to go through other Xs so that you'll always have an X if they didn't fly off the screen, but I changed that due to balance reasons - too many Xs made the ability too strong. I can understand the confusion, though. Maybe I'll make the missiles spawn an X instead, but again, the balance will be off.
The toss attack currently throws random blocks towards the opponent's side, I tried various combinations of selecting which blocks to throw and found random was the easiest, as the power is to throw X blocks over, depending on the level of attack. Is it confusing because one of the trails messed up? (That's a bug and I shouldn't have gif'd a bug...)
Attacks do generally need better telegraphing - between the chains generating power to an attack taking place, I still need to put in juice to emphasis them. But then that's more visual noise XD
----------------------
Your idea of explaining each bit of the game sounds great, and I do think I should do that - but again, does that not defeat the point of trying to communicate the game *in* the game? And is it worth pursuing this game if it's not something easily understandable?
Trying to get a balance of level-headedness and pure enthusiasm :/
1. Make the player play alone first, then bring the enemy AI in once they've managed to create a few combos... Or once they do a successful attack: Blocks fly offscreen and then this angry shark rocks up going "WTF?!" and starts fighting back.
2. When playing in single player mode, have the player's block area be more visible: Bigger, not all the way to the left of the screen (and certainly not UNDER the UI buttons there); de-emphasise the AI's space by moving it more left and making it smaller, etc.
3. I think the real problem is communicating goals to the player. Once the player knows what their goals are, they'll start forumlating HOW to get there. A lot of puzzle-fighter players will understand the implicit goal here, fill the other player's side with blocks. But I honestly can't tell if you make this goal explicit to players in any way, it feels like a tacit assumption that they'll want to do this. Also, make sure that once they realise this is what they need to do, only then should you start showing them how they can do it with direct block pickups, etc. An experienced puzzle-fighter player isn't going to get annoyed by any of this, but a new player is going to get onboarded way faster.
-I would think punting a mostly multiplayer game is going to be even harder than an SP one, and we already know how hard it is to get users on mobile. I know you're working on the AI, but the real attraction of a puzzle fighter is always the multiplayer.
-This game is busy, VERY busy, and that's on a PC monitor. On a phone screen, that's going to be compounded.
-Adding to that busyness: fat fingers on screen!
Hitting steam seems like a no-brainer, but I wonder if you shouldn't be aiming for one of the consoles as well, maybe even as primary? How are their indie marketplaces working out? Perhaps @DaveRussellSA can weigh in on the Xbox side of that? It just seems to me like the most fun I've ever had with those kinds of games were in an arcade or on a console, where two players sat together in the same space.
@dislekcia - Thanks for the suggestions about presentation to first-time players, tutorialising the presentation, if you will.
What I'm most concerned about is "is this game attractive enough to chase into a full game?", which means, to me, that it should be attractive to people who see it without tutorials, without having to be taught how it works (of course teaching helps, but I can't have every piece of promo material being "how to play Beat Attack"). To that end, is it, as a core? I'm concerned that the lack of uptake here is a good indication of the lack of uptake "out there".
I'm not convinced that's something that can be fixed by tutorialising or creating teaching material. Is it? I guess I should just try it anyway?
-------------------
@mattbenic - Thanks!! Yeah I think I find Beat Attack in a bit of dilemma. The core of it came from the desire to play a puzzle battle game on a mobile format - the controls and such are designed that way. Is it worth re-engineering the pitch from "mobile-perfect puzzle battler game" to "one button puzzle battler game" and shift the focus to PC and such?
Otherwise, should I just dump the one-button control mechanic and go for a more conventional left and right and action button control scheme? It will completely lose the "rhythm game" angle - the music still plays, the game works as before, but the player will have complete freedom to move as they want to. It's not *bad* per se, it's just what it started out as, and can be seen as very similar to existing games, if it wasn't very derivative already.
If we think targeting PC/console first as a one-button game, going to mobile could be a bonus, anyway.
I totally believe that the most fun with this kind of game is to be had with two people in the same space, which was where the original concept came from... Wanting to play it with friends anywhere on the most portable gaming device I have (with the biggest screen)... On my tablet :)
Thanks again all!
--------------------------------
@FanieG - yeah I'll try to reduce the visual clutter. I wonder if that's got to do with the buttons being big and there being text on the screen (numbers and such). Does the animated background make it feel more cluttered?
So when you say you originally targeting mobile, it sounds like you actually mean tablet? Or am I misunderstanding you. To me, Mobile is a phone, tablet doesn't fall into that category. They have some similar challenges (touchscreen, typically single-user, limited hardware) but each has unique aspects as well (how and when they're used, screen size-even if top end phones all seem to be phablets these days).
Have you tried having two players on the same phone or tablet? Whichever of those devices you're trying for, I'd say playtesting on a PC with a keyboard will really only get you so far-and IMO you've past that point.
As for repositioning/rebranding it for PC and console, I don't really see that as being necessary. It's a rhythm puzzle combat game, simple as that. Sure it happens to be 2 button rather than full directional control (no, I don't think that needs to change), but that's not really relevant to how you present it.
And you're right, I realise that it doesn't work very well on phones. So yes, for tablets, not phones. The single-player aspect could fit the phone, but not the duelling side of the game.
If I continue with this I will definitely create a single-player-centric version of the game that's focused more on the rhythm and speed aspect over the versus aspect. In fact I could make that game first before doing the two-player one, that could be the easier way of going about it.
I have tried it with a tablet, I got it running on my iPad after that meetup. I'd say it works better than keyboard because the controls respond even faster than keys (no "travel" time between pressing and getting a reaction, but that's subjective). I still need to figure out/implement how to distinguish between a swipe and a tap though.
If the sounds lined up with the song then they could in a sense add to the music track itself. You could have the music be mostly bass and drumbeat while the game sounds could be the hihats etc.
From playing the game itself....I have no idea what i'm suppose to do...Did I miss a play guide or an instruction screen? Sorry for my noob feedback
Imagine if you're supposed to punch something once a beat, but the thing moved ON the beat. Then you could very easily miss it by punching just before or just after the beat. The way it is now, the beat happens when the thing is still.
And yeah, the game lacks tutorial right now - all my effort at making the giant button obvious and adding trails haven't actually amended that. I'm building a single player mode that'll hopefully address that. As for the "game sounds", they occur at the speed of the music, as intended. Effects that happen on pick up or drop doesn't happen when the action occurs but when the beat drops, or else it felt really discordant and messy. Did you feel like you were confused because of the sound effect not happening when you pressed the button?
Do you feel it matter if you can distinguish "sound effects" from "backing track" easily? Why? How did it make you feel?
Thanks for your feedback :)
I understand the concept of anticipating the beat for the player to select stuff on the beat . In fact I think that part works very well. I straight away realized I was hitting things on a beat. So this is more related to the video you have here, I couldnt get to 170 bpm (either won or lost before it came around) It just feels that later at the higher bpm's it becomes very noisy and hard to hear the beats well. This may actually not be a big problem as at 170 bpm you arent really needing to anticipate beats.
It does also sound as if a series of hihat sounds are completely out of sync with the track at the higher rate. I re-listened a few times and at 2:32 in your video, one of the track channels gets dropped and the track is more simplistic, here it doesn't sound out of sync anymore but as soon as that sound returns to the track it sounds off again so it may just be the music that is off (or its a youtube thing). I feel at the 2"32 part it sounds cleaner in general (music track) but I also realize that changes in the track help to set the atmosphere. The busier it gets the more hectic the game starts to feel. Perhaps the closer to "death" a player is the more sounds could be added to the track?
I should also point out that having a girlfriend who plays piano,a close friend who is a DJ (the kind that uses actual records and matches bpm by ear.) and another friend who is a drummer does make me more aware of beats matching up. Doesn't seem as if anyone else is bothered by the sound.
Also would totally play again and I'm not a big puzzle fan
Result:
spoilers tags only work for text...
It seems a common thread with my games, my attempt at "radically simplifying" "traditional controls" (all the air-quotes) has made Beat Attack stupendously confusing for people to understand from the get-go. So I've tried to address that problem with a single player mode that's less daunting than introducing people straight into the overwhelming two-player mode.
Disclaimer: this is all stupendously rough!
Gameplay video:
I'll post later about the changes I've made and why, but for now
PLEASE PLEASE give it a blind playtest and see if you understand it without too much trouble.
**PLAY NOW on Web, OSX and Windows build:**
http://gamejolt.com/games/arcade/beat-attack/60411/
All you should need to know:
SPACE = tapping
Z = tappon on the left side (turning around) (later this will be replaced by a swipe left/right gesture)
Navigation is via mouse for now, sorry!
Thanks all!! :D
I've watched the video and I have to say that in it the music really doesn't feel tied to the way things are moving. It's almost like the beat (which is a bit tricky to follow, but that might just be because I've been playing Necrodancer so much) is happening and then the ship moves, which takes a bit of time. What I'd expect would be for the ship's new position (and thus my player button push) to line up with the beat happening, so that if I predict the beat I'm going to be rewarded with crisp gameplay and the piece will zip down in the lane and I'll feel awesome.
Something that doesn't help with the beat feeling delayed is the slow movement of the piece when the ship is holding it. That should really just teleport with the ship instead of moving over to it after the ship's already moved. The piece's trail doesn't help with this because it accentuates how the piece seems to slide around in an uncertain way instead of zipping directly up or down.
I could:
1. Snap and force the movements of the piece to start AT the exact top of each lane.
2. Snap the ship and piece movement completely so that there's no lerping between beats... Do you think this is necessary?
I'll give those changes a try. Thanks @dislekcia :)
-------------------------------
Really not sure what to do with Unity now. Don't even want to try WebGL build... If you can I'd really appreciate downloading the windows/osx build to give the build a try! Thaaaaanks!