That's really cool, you clearly have thought and decided on these principles! Just to share: from my perspective I dont actually feel much difference between the dialogue of 'maybe check your settings' (i think that was the line in the game) and having the button tooltip visible while playing, they both refer to something outside the game already, to me.

I had a similar type of principle in our game Rhythm Doctor, at first I really wanted it to be immersive (as if you are really helping a hospital somewhere else in the world). So i wanted a real-time clock, and the time of day in the game will match the players own time of day. And the story would never jump forward in time.

But later, we got looser on those principles because the day/night shift concept was too intuitive as a way to to show easy/hard levels. In the end it didn't really matter that much to the story, because players could suspend their belief for these little things easily.

Anyhow, just a random story haha, it's an interesting to see you stick to the principles as hard as you can and make it free instead. Best of luck with the release, I'll be waiting to play!

Great devlog, and had a lot of fun with the demo! I didn't feel like its too simple, actually quite a lot already to keep track of with reloading and dashing and different enemies and bombs. I actually felt it to be more engaging compared to Hades.

I recorded a playthrough here in case its useful:




The thing that made me most confused was the upgrade system with the modes, bash mode deflect mode etc.

At first I thought that these are the same thing as the different weapons. Like different weapon = different mode. So when i choose to upgrade 'deflect mode' i thought it means that theres one mode if i'm in it will deflect bullets. So I keep checking controls to see if i missed a key to switch modes? Or maybe the shotgun weapon type is actually called 'bash mode', and I can bash when i equipped that weapon?

But actually these are not modes the way I understood it (exclusively different modes that dont work all the time), but more like modules.

I died at the basher boss twice, it felt quite unforgiving. And a bit annoying for me that it relies on watching the meter for the enemy too much on when its going to dash at me. (instead of an audio feedback or a consistent timing that makes it easier to learn)

But the dialogue after losing made me laugh haha, its nice for my character to acknowledge that its difficult. I'm definitely going to play more to try to beat this.

(Also i was surprised that for such quality you are planning to release this for free, it looks so cool and polished it feels like it can sell easily for a cheap price (I dont know how much content there is but even what I played I already would have paid $2+ and not feel cheated))

Finished our trailer!





Getting really smooth footage was a headache, but it was done. Change the resolution to 1080p60 for some silky smooth 60 fps action.

This is looking great. It is nice to get some insight into rhythm game mechanics. The giant controller sounds fun too I hope you find time to make one for this game!

Thanks! The drum controller is indeed working!!!

Great read fizzd. Hope you have a blast writing these & looking forward to more. Definitely an interesting insight into the insides of rythm games. (The thing about frame rate is super cool!)

Hey, nice to talk to you again! Glad you enjoyed the post, and sorry for the lack of updates recently, we're entering final crunch to really get the game polished haha. Hope to have something nice for you to stream again soon!

[Devlog #2: It Ain't the Speakers That Bump Hearts It's Our Hearts That Make the Beat]

Devlog #2: It Ain't the Speakers That Bump Hearts It's Our Hearts That Make the Beat
(Building a Snare Drum Controller)

Today is gonna be a little different: it's all about real life. Physically I mean, not like, student loans and society pressures. We made a snare drum controller for our exhibition!



(click for vid)



If you're interested, in how to do it: I bought a piezo transducer, which is this metal ring that comes enclosed in a black plastic. Wired it to an Arduino Leonardo (The Uno doesn't have keyboard input capabilities, beware, I had to go back to change it!). And the following was the code I ended up with, including a delay to avoid debouncing:

Code:

==
const int threshold = 600;
const int delaytime = 160;

void setup()
{
pinMode(A0,INPUT_PULLUP);
Keyboard.begin();
}

void loop()
{
//if the button is pressed

if (analogRead(A0) Less Than threshold) Keyboard.write(65); delay(delaytime);
}

===

Had a good friend help me with placements. The arduino was stuck to the side of the snare, and the piezo duct taped to the top. We tried several configurations including having it at the bottom of the snare, but it resonated even more down there causing multiple inputs per hit. So the top of the snare it is.

And best part is that it feels realllly good, especially with fast rhythms! If you're in Dundee on the 13th to 16th come try it!


(today's headline is brought to you by Twenty One Pilots - Holding On To You.)

[Devlog #1: It Feels Like There's Oceans, Between You and Me, Once Again.]

Devlog #1: It Feels Like There's Oceans, Between You and Me, Once Again.
(Breaking Apart Levels into Individual Scenes)

First, a little bonus I wrote: an analysis of Rhythm Game Design in Orbit Or-Beat!

So, a lot of the past week has been implementing Kyle's assets. We've gone from this:



To this:



Quite an improvement! With a rhythm game though the most important thing is how it looks in movement (note how screens for 140 look absolutely mspaint but the videos are positively

).

I wish I could capture the movement at something above 5fps but my laptop can't handle it One day we will find a solution! (..i.e. begging youtubers who've recorded footage of our games in the past, to record new builds for us.. hey if it works it works ok shh)
---

So let's talk Unity. From what I've learned, there are two ways to make a multi level game.

1) Have one scene per level.
2) Have one scene for all the levels, and every time you load that one scene, also pass in an argument that gives a level layout in a string, like "RRRUDDDLLLLLDLL".

Before all this, i was using method (2), i.e., every level in my game was shared in a single Scene. And I made a little interpreter that could read a string and convert it to a level. And all the levels were just hardcoded in the main Controller class. Prepare your eyes.

Code:

string[] leveldata = new string[]{"RRRRRRRRR",
     "RRRRRRRDRRRRRRRRR",
     "RRRRRRRURRRRRRRRR",
     "RRRRRRRURRRRRRRDR",
     "RRRRRURURRRRRURUR",
     "RRRRRDRDRRRRRDRDR",
     "RRRRRRRRRRRRRRRR" +
     "RRRRRRRRRRRRRRRD" +
     "RRRRRRRRRRRRRRRD" +
     "RRRRRRRRRRRRRRRD" +
     "RRRRRRRRRRRRRRRU" +
     "RRRRRRRRRRRRRRRU"..

So what would happen when the player won a level, is a currentlevel variable would increase, and the Scene would be loaded again. Nice.

The problem with this

..is that everything unique to a level now has to be done in code. The scene itself in Unity's editor is just completely blank. And so when Kyle gave me a layout like this:



..well, I wasn't sure how to even begin doing individual assets and placing stuff per level. One way would be to have assets be represented in that string as well, like

"RRRRDDDLLLL//ASSETS//CHAIN1/(230,300)/3.2x"

..yeah oh my god tweaking that stuff would be a nightmare. I could code up something that lets you take assets, alter them, and export results to XML or something but ohhh goddd noo think of all the numbers. Colors, position, scale, attaching individual scripts, the parameters of those scripts, nononono

Change

Sure, if I could switch to a scene-by-scene layout that would be cool because placing Kyle's assets would be a lot easier, BUT, the actual tiles themselves are a lot easier to write out in "RRLDLLD" form, than to painstakingly place in Unity's editor.

I just happened to be meeting up with a fellow gamedev in Cambridge, just after graduation (whoop whoop MEng Cantab!!) and two days before going back home to Malaysia. I told this little thing to him and he said

"Yeah why not just break it into individual scenes?"
"But I can't just place my tiles everywhere!"
"Then why not just extend the editor?"
"What like NGUI does? Isn't that like ridiculously complicated to do?!"
"Not really.."

And so..



Woohoo!!

Yeah, turns out extending the editor is actually pretty simple and well documented! Actually that's a lie. There were a few catches. But I had it up and running in a day or two, thanks to some great online tutorials. Now we get the benefit of

• Visually placing assets using the editor, and
• Still creating the level with strings.

Of course, the one problem with this is that now, instead of one instance of a GUI, a Controller, etc etc, now every single scene has their own instances of these things. And I think this multi-scene setup might actually cause some problems in the future. What if I added a new Menu object? Would I have to go to every single scene and add it 30 times? Can we not have like Master Slides the way they do in Powerpoint? Is there anything like this?!

If you have answers please let me know. Otherwise hope you enjoyed reading this and till next time.

Final reflections: writing one of these posts seems to take about an hour, including recording gifs and uploading them and all. Is it worth it? Is this time better spent working on current problems? Who knows! I think one mistake I did during my degree was spending too long trying to make perfect notes, when I should've done more practice questions. Maybe that applies here too.

(today's headline is brought to you by Seafret - Oceans.)

Really, really nice to see a Dare participant in the devlog thread. Good luck! The game looks visually stunning certainly. I have been at the past few Dare events to play the games made by students and I have to say my favourites are almost always local multiplayer, everyone is there with friends and it sucks to have to watch someone else play a cool, innovative game. Still rhythm games need to be revamped and this seems like a genuinely fun approach! Looking forward to the devlog.

p.s. I agree that Dance of Fire and Ice is eerily similar to the Game of Thrones series/book title. Maybe something like Visions of Flame and Frost? If you really want to stick with that theme.

Oh cool, and thanks! Haha there's no reason you can't split up with your friends though, and besides sessions in this game are ideal for hotseat play because turns are very short, at most 60 seconds. Hopefully we can get some peripherals for true crowd-drawing arcade style action. For Rhythm Doctor at the IGFs we made a giant controller and just the sound of it clacking attracted a huge crowd!

The name is most likely gonna stick though, seeing it's already out there in the market now.

[Devlog #0 - How to Dismantle an Atomic Bomb]

So let's start from the very beginning. How do you make a rhythm game? Well..

Devlog #0 - How to Dismantle an Atomic Bomb
(Breaking down the Rhythm Game)

I've done rhythm games a few times, and in fact they're the only kinds of games I've seriously worked on and ever want to do. And when I first started I found there wasn't much documentation around for the general architecture of rhythm games. So, this is meant to be a quick and dirty technical guide to how I approach my game architecture.

First, you might want to see this video for an explanation of the main mechanic of this game.

--

1. In a rhythm game, have a class that is used solely for keeping the beat.

In my games I call it the Conductor.

It should have an easy function/variable that gives the song position, to be used by everything that needs to be synced to the beat. In this game for example,  the Conductor has a variable called songposition which is pretty much the cornerstone of everything in the game.



The above are the variables in the Conductor class. Some are specific to my game, but the general ones that I always have are

• bpm, which gives the bpm of the song
• crotchet, which gives the time duration of a beat, calculated from the bpm
• offset, always important due to the fact that MP3s always have a teeny gap at the very beginning, no matter what you do, which is used for metadata (artist name, song name, etc)
• songposition, a variable that should be set directly from the corresponding variable on the Audio object. This varies from engine to engine, but in Unity for example, the variable to use is AudioSettings.dspTime. What I do is, in the same frame that I play the song, I record the dspTime at that moment, so then my song position variable is set on every frame as follows:

Code:

    songposition = (float)(AudioSettings.dspTime – dsptimesong) * song.pitch – offset;

Aside: the song.pitch is an inbuilt variable in Unity that gives the speed the song is playing at. By incorporating it into my song position variable, I can change the playback speed and still keep everything in sync. This was used in my game to slow all the songs down 20% because I only realised after composing the music that it was too difficult.

Anyway, now that we have set up our Conductor, time to take care of the objects that need to sync to it!

--

2. Every object that needs to be in sync should do so using only the song position, and NOT anything else.

This means, NO timers, NO tweens. It won’t work consistently!

If you use a timer that increments every frame (e.g. in the Update function), an inconsistent FPS is gonna throw the whole thing off.

If you use some sort of elapsed-time function, it’s still not going to be accurate enough, and if the song skips for whatever reason everything will get thrown off.

So, use only the song position. NO timers.

(Game design tip: have as many things respond to the beat as possible! Preferably everything!)

—

But even then, there is something more subtle that you need to pay attention to – and this is what I struggled with at first.

You see, even when using the song position variable for all things that sync, there still needs to be a reference point that you want to check the song position with. In the most basic case, all you would check it with would be ground zero: the start of the song.

Say for example you had four lights that you wanted to flash on the first four beats of the song. You’d write, in the Spotlight class script:

—

Code:

    int beatnumber = 1; //or 2 or 3 or 4

    bool islitup = false;

    float bpm = 140;

    float crotchet;  //the duration of a crotchet

    void Start(){

    crotchet = 60 / bpm;

    }

    void Update(){

    if (Conductor.songposition > crotchet * beatnumber)

    islitup = true;

    }

—

But other times you might want an action that happens periodically instead of only once. When implementing something like this it can be easy to have a system that makes things inaccurate without you realising it. And so the most important yet simple rule I’ve learnt from this jam is:

 

3. Never update your reference point arbitrarily. Only increment it.

This might be a little subtle so let’s do this by example. Say you want to have a light that Flashes on every beat, instead of once. Here’s a simple way to do it which is… wrong! Can you see why?

—

Code:

    float lastbeat; //this is the ‘moving reference point’

    float bpm = 140;

    void Start(){

    lastbeat = 0;

    crotchet = 60 / bpm;

    }

    void Update(){

    if (Conductor.songposition > lastbeat + crotchet) {

    Flash();

    lastbeat = Conductor.songposition;

    }

    }

—

Literally five lines of code. Seems like it would work, right? Every time we move on to the next beat, we set the reference to the current time, and wait until another beat has passed.

BUT NO! All you will get is tears. And a flashing light that gets more and more out of sync with the music. Specifically, up to an additional 1/60th of a second more out of sync with each beat. (There’s a hint for you!)

The problem is exactly the rule I wrote above:  Never update your reference point arbitrarily. Only increment it by set amounts.

When we set lastbeat to the current song position, that’s what I mean by arbitrarily updating the reference point. The problem lies in the fact that your game can only work at a specific fps. 60 frames a second, say. So you can only perform a check 60 times a second. And so by the time the if statement returns true, you have already passed the time by up to a 60th of a second. And so what you are setting the lastbeat to is not the actual last beat, but a fraction after!

IMPORTANT ILLUSTRATION:


—

So, what’s the right way to do this? By incrementing, not setting:

Code:

    float lastbeat; //this is the ‘moving reference point’

    float bpm = 140;

    void Start(){

    lastbeat = 0;

    crotchet = 60 / bpm;

    }

    void Update(){

    if (Conductor.songposition > lastbeat + crotchet) {

    Flash();

    lastbeat += crotchet;

    }

    }

—

Simple but important!


Applying These Rules To My Game

To be honest, though, I already knew this from developing my first rhythm game last year. But what caught me was a more complex manifestation of this scenario.

You see, in my game the planets orbit around each other following the speed of the song: a half revolution is exactly one beat. When the player presses a button, the orbiting planet and the stationary planet switch roles. Thus if the player presses a button every beat, the planets dance elegantly across the screen in a straight line.

The angle of the planet at any one frame would be given by the following reasoning. If song position is lastbeat at 0 degrees, and it should be lastbeat plus crotchet at 180 degrees, then the angle should be incremented by

Code:

(deltaTime / crotchet) * 180 degrees

so that by the time a crotchet had passed, we would have moved 180 degrees. Simple!

The problem is when the player doesn’t press EXACTLY on the beat (and to be fair, that’s pretty much impossible). The game had to be grid-based – it sure wouldn’t make for a very fun rhythm game if you had to compensate for a slightly early tap on one beat with a slightly late tap on the next. And so the problem I faced was snapping the planets to a grid while not making the snapping cause everything to be offset.

The first approach which at the time I thought was very clever was, at the time of the key press, to do several things.

• Record the angle difference between the moving planet’s position and where it should snap to (i.e. 180 degrees in the case of the straight line)
• Snap the moving planet to the grid, and make it the anchor
• For the planet that was previously the anchor, offset it by that angle recorded earlier, and make it the moving planet now.

One frame before key press:



One frame after:


I thought at the time it was genius – the fact that you pressed it early is now balanced out by the previous planet moving back a bit, so that the next beat would still happen at 180 degrees!

And how did this strategy work out? Terribly!
--


Everything but the Kitchen Sync


At first it seemed all in sync and dandy, but as the song progressed the syncing got worse and worse. If you’ve been reading so far, you should already know why the game slowly went out of sync.

Yep, it’s because I broke the rule of never using anything other than song position for my calculations. In this case, I compared deltaTime to the song position when updating the angle of the planets. Don’t do this!

But – and yeah it gets a little complicated – even when I replaced deltaTime with a custom timeDifference variable calculated directly from the change in song position between frames, it still didn’t work!

And here’s where the subtlety lies: by incrementing the angle each frame, I was implicitly using the song position at the previous frame as a ‘reference’. Each time I was incrementing this reference by an amount that depended on how much time had passed between frames. And the result of all these calculations, small errors built up that contributed to the game going out of sync.

(Yeah, rhythm games can be tough. In making a rhythm game, it’s absolutely vital that your engine works millisecond-precise, so don’t worry if you take a lot of time making it work perfect, it’s worth it.)

In the end, I fixed everything by going back to the golden rule: only incrementing the reference point by a set amount, an amount that did not depend on frames. Here was the very final solution, which comprised of a few sub solutions working together:

• Get rid of the incrementing angle by time difference every frame. Instead, interpolate! Record the song position at the last time the planets switched, call it last hit say. Also record the angle your planet was at, at the time of the last hit. Now, your angle at any frame is just something like this:
  
  
• To solve the player-not-hitting-exactly-on-beat problem: instead of lasthit being the time at which the key was pressed, it’s the time at which the key would have been pressed, if it was pressed exactly on time. In other words, this last hit variable is ALWAYS only incremented by multiples of the beat! This was what completely eliminated any arbitrary reference points in the calculation, just like the problem of flashing a light on every beat that was discussed earlier. In other words, we are taking away the exact time a player presses the key as a factor in our calculation, and that tidies things up a great deal.

(Exactly how to calculate the time the key would have been pressed if it was on time was a mathsy and not particularly interesting problem involving angles and geometry, but you can ask me if you're interested.)

--

Conclusion

And that, ladies and gentlemen, is how to make a rhythm game. Hope it illuminates how seemingly small time differences are actually the most important things when developing one.

Special thanks: Tom Voros, creator of http://microngame.com, who helped me loads along the way with hints on getting the rhythm synced in AS3.

[(2nd August) Check our new trailer for next weeks Dare build !]

Hi guys,




(2nd August) Check our new trailer for next weeks Dare build

!

Play original version here!
Or here on Kongregate.
Or here on mobile for $1, with free updates as this game progresses!

A Dance of Fire and Ice is a tough one-button rhythm game about turning geometry into music.

You might know me from Rhythm Doctor, which won an IGF Student award last year. This is the second project I'm working on, which is also a tough-as-nails one-button rhythm game, and this time I'm working on it in a team. Our artist Kyle is an artist behind webcomic Soul Symphony, and our composer Jade is a music student at Berklee College of Music.

We recently got selected for the Dare to be Digital 2015 competition, which is a student competition for game developers. We're representing the University of Cambridge, California Institute of the Arts, and Berklee College of Music. And we have five weeks from today to get a revamped, high quality version of this game out for the Dare exhibition in Dundee, Scotland. We're competing with 15 other student teams in this competition, who are all probably spending their limited time more wisely than writing a devlog heh. But anyways..

This devlog serves to chart my struggles and lessons learnt from the programming side of things. We have a tumblr that serves more of a visual progress indicator with concept art and so on, but this will be a more thorough writeup. Willy Chyr's Relativity devlog has been a joy to read, and served as the main inspiration in deciding to do this. Hopefully you will find this devlog interesting too!

I'll start with going into detail about rhythm game design and the programming challenges in going from prototype art to full blown HD. Stay tuned!

[Summary]

Hi guys,



>>PLAY<<
(also on Android for 99 cents)

Summary
A Dance of Fire and Ice is a one-button rhythm game (just like my other game Rhythm Doctor) originally made for the last Ludum Dare, in which the theme was 'Connected Worlds'. It did pretty okay, scoring #6 in audio! Since then I've been working on this for a month and a bit, and am proud to show you the first version I'm quite happy with. Let me know what you think!

BONUS: How To Make a Rhythm Game

This may sound strange but.. I really like the bilingual UI! Especially how the japanese characters have no fill, just like the structures in the game. I almost want to recommend that you keep the bilingual UI for the official version just cause it gives a nice flavour to the game. Congrats on achieving such a nice cohesiveness in everything. thanks also for posting the feedback notes, they were interesting to read.

Ah I realise now why I thought there were way more patterns: cause a lot of your patterns are quite long, like the S shaped one being two simple S shapes then two harder ones. I initially thought they were two separate ones. And now I realise why there's such a huge variation in difficulty, because at most you only get one or two patterns per level, per playthrough, and they vary quite a lot in difficulty imo. The harder S right after the easy S is the one that was quite overwhelming at first. Maybe space that one out a little?

I feel the fact that you never experience all of the patterns in one round is why each individual run feels more luck based than in Hexagon, and why my scores can fluctuate greatly . Just now I managed to get to level 4 and then grab a few more cubes there, but that was entirely cause the level 3 patterns I got were just the slalom ones which I find easier than the twisty / linearly moving ones. (Total playtime now 58 minutes btw) In Hexagon winning a level pretty much guarantees that you have mastered all the patterns, cause in the 60 seconds you have to survive you see every pattern at least once.

Every level was designed to force players to twitch left and right more frequently rather than waiting and anticipating for a flip in the distance.

Yup, I get that! But I still think it can be offputting for newbies if they keep dying, especially since learning a pattern doesn't really help at first because of the 5-6 different patterns. The tutorial is very nicely done and great for newbies, but the sudden spike is, well, really sudden. That said I think the collecting cubes is a very clever mechanic cause it ensures if you're good at the game you can finish a level in just seconds, whereas if you aren't you can choose not to take more risky cubes and stay in the level longer. I suggest maybe take advantage of this and have an even simpler level before the current level 1, with easier obstacles , higher cube rate, but only needing three cubes to advance for example? Would allow newbies to not feel too overwhelmed, but still allow pros to finish it in under like three seconds.

I struggle with this wanna-be-hardcore-and-don't-wanna-bore-pros thing in my own game too - some love it some dont. One of the feedbacks I got from the IGF judges was a one-line "too hard" (in which it was obvious they never got past the first stage :/) but the other one applauded the "surprising depth" of the game. So yea it's quite variable. Maybe get statistics to see how many percent of people quit before finishing the first level and see if that changes your mind? It's your decision in the end of course, if you feel it will compromise on your vision then don't feel pressured to change it. Something I'm personally guilty of is sometimes defending my decisions to playtesters, which is unproductive as all it changes is one individual's perception - I found this to be a good wake-me-up.

Finally I take back what I said in the last post. For some reason trying the game today after a good night's sleep, the camera is not disorienting any more! Psychology heh. And I don't mind being a tester, I am not that good at the game though! I'm in KL for the summer.

Wow. Turns out I've played for half an hour already according to the statistics screen. It definitely didn't feel like it.. Great job! I managed to get to level three, at which what was to be expected of me with the moving walls was so ridiculous it made me laugh.

The game is very polished, everything is very slick, all the motion in the menu screens and the screen effects. You've definitely taken a lot from the Super Hexagon design, the whole techno music + voiceovers, but it's done so well I have no problem with it.

At first I found the flipping was always disorienting. I was wondering if I would be able to play better if the camera stayed static when flipping so that the block was on the ceiling; that or if the entire level was mirrored instead of rotated, so there wasn't a left/right reversal. But I've gotten used to it after half an hour now. The other thing it took a while to get used to was to flip earlier than I thought. Usually games like this are in first person mode, so you generally take when a barrier disappears offscreen to be the point where you can safely flip - in this game you have to flip a lot earlier due to the 3rd person camera.

I, like the poster before me, also feel the set-pieces in the first level vary too much in difficulty. The S-shape one felt particularly out of place for a first level. In fact I think you almost have too many variations in each level! It's funny, because I play Super Hexagon a lot (I was in the world top 10 at one point on the PC version heh) and even that game has at most 4 or 5 kinds of obstacles, which you play for up to 120 seconds each before it changes level. Here it's 10 variations in the span of like 15 seconds. I almost feel like you could stretch each individual level out into two stages, splitting the obstacle variations into early and late stages, and it would feel better paced.

Anyway that's just my two cents, I'll definitely be playing more of this later. Good job!

I'd say try to come up with a revive mechanic simply because the core gameplay is hard enough as it is, but it's your call. That said, I'm not sure exactly sure how that revive mechanic would work.

Anyway, I played the 2P versions [by myself because I don't have anyone here with me, hahaha] and I think you pulled it off well! My only feedback would be that sometimes the Red and Blue bars switch and there's barely time to re-orient yourself before the notes start up again. That's not your fault, since these songs probably weren't composed with the co-op in mind, but going forward you might wanna think about having a measure of rest for when that switch can happen less stressfully.

OHHHH you're the guy behind soulsymphonycomic.com ! Duhh i don't know why I didn't make the connection until now haha. It's an honour! Anyway thanks for the feedback. Yeah at first I was thinking the characters would stay in their place but their strips would just change colour, but I changed it cause I thought it would be hard to keep track of some rows on top and some rows on the bottom. Yeah a bar of rest would be a good idea for the big switches, I'll see if I can program the 2p mode to not play certain beats that would usually be played in the 1p mode. Thanks!

nice, like it!

thank you :D

2P functionality added to the main game now over at rhythmdr.com !
Caps lock to enable/disable, and the L key controls p2. Still experimental, and the mechanics of it still need to be fine tuned for the boss level - I'm trying to figure out what a good way to do his would be. Hits that are in sync (not only both hitting correctly, but also within 0.02s of each other say) get extra damage or mend both patients hearts? After one patient faints, it sort of spreads so the other one goes down to one life? Just cause it's boring if you can't play and just have to watch the other player. So either make the player revivable, or make the other player have a higher chance of losing quicker. Hmmmmm

Updated the full build with experimental 2-player mode. Press CapsLock during the game to toggle. P2 uses the L key! Thank you so much for all the feedback so far.

This really needs to become an iOS game. That would be so awesome!

However, both games have one minor mistake: it takes too long to restart, since you have to watch all the "cutscene" stuff (like in your boss level). I would prefer to be able to jump straight to the level (or skip, like in tutorials).

On the first point: we have found a guy who's going to help us port the game to iOS! We'll be working on it this summer

On the second point: initally i was going to say the engine isn't robust enough to alter music as it's being played (it can only prepare songs ahead of time to put into the timeline, once it's put in there it can't skip around). However a good alternative is to ask when you begin the level whether you would like to skip all cutscenes in the level. I think that could work!

Feedback about two player mode would be nice, if anyone has a friend handy, particularly on the multirow stages like Tier 3 and the secret level. Enjoy!

Post GDC - we added two-player functionality for the exhibition, it turned out pretty great

Every row in the game now has a 'single player' property and a 'multiplayer' property. Essentially the end effect is that the second player can drop in and out of the game at any time and not have the rows mess up or anything. Try it! Press CAPS LOCK to drop in or drop out the second player.

Here is the Booth version (the menu's are kinda scrummy, and I added the two-player mode for the boss level post GDC -- essentially the thing I added post GDC was for one row to split into two in two-player mode, needed for the boss level)

RHYTHM DOCTOR GDC VERSION

enjoy! P2 uses the L key. What I did for the booth was to carpenter (can it be used as a verb? hmm it sounds wonderfully spicy like that) a separate arcade controller controlled by an Arduino. It looks like this. Winston then took over with the decoration!

I'll add the 2P functionality into the main game soon ish. exams exams exams for now. Someone explain to me lagrangian mechanics pls

Woah this was surprisingly fun! At first I was all 'oh not this whole control multiple people with each key press thing', but after I realised every character had a special power it become really engaging, because situations would always come up where I had to choose which characters to kill off by pressing either of the key strokes. Also I actually liked how the powers weren't explained and it was up to us to figure out how each guy worked. I'd say please omit a tutorial it is way more fun discovering things for myself. Nice touch on the lack of text too, it says something about how clear your sprites convey their functions.

That was a nice ten minutes Thanks for making it open source too, have always wanted to learn the basics of 2D in Unity and this is a great way to start.

@Fervir Thank you!
--

Hey! Huge fan of the game so far, have been for the past few months. I literally registered this account just so I can follow this thread and give my feedback!

First of all, I just wanted you to know I absolutely love Rhythm Doctor so far. I love rhythm games and I have so much fun with it. I love the music, the visuals, the gameplay, everything. To be completely honest I'll load up Rhythm Doctor just to play it when I'm having a bad day. It always cheers me up. So thank you so much for making this. I think a lot of people will love it when it's done.

As for feedback on the latest demo:

1. First, I'm not a piano player [though I did play brass instruments for 8 years]. It was clear to me that the first four lines were bass and the last line was treble, especially because you used the different characters. Having the last line be the girl instead of the samurai helped, plus I usually associate the Samurai character with bass/bass drum in general.

2. Yeah, I thought the swing beats were inuitive enough to figure out, even probably for non-musicians. Especially if this level goes AFTER all the other ones so far.

3. Yes, I completed the previous demo, even unlocking the secret song via getting S rank on Tier 3 Hard. I loved the difficulty on this latest song, I thought it was really really fun and it really put me to the test after how much I've improved doing the other songs. I do think that this song should go AFTER Tier 3, because I think it takes for granted that you're a pro at multi-tasking the different lines. But I think it's a nice challenge and I don't think it's "too hard", not even the Hard mode version. I think it'd be perfect for halfway through the game, or the beginning of the second half.


Also, one more piece of small feedback: I like how you made it easier to understand which lines you didn't have to worry about. However......I just wonder if the average player will know what the word "desaturated" means intuitively. Not sure if you wanna use "gray", "grayed-out", or say to just handle the "bright lines" or something.

Hey, thanks so much for sharing your experience, you don't know how much it means to us. It's really incredible to find out that there are some people out there who have enjoyed the game enough to perfect the levels. I mean, really, reading that made my day, just to know that what we're doing is being followed by at least one person out there!

Thanks for the feedback too, it's really encouraging that you 'get' everything I was going for. Although of course as much as I would love it if everyone was at your skill level, you seem a bit unrepresentative of the player base, haha.

New level YESSS KEEP IT UP

1. I don't think I'll be able to play this level without looking at the screen since most, if not all of the switching doesn't have some sort of an audio cue.. maybe play a few bass notes while on the bottom row when switching from that to the first four or something like that? Oh, and I don't play piano.

2. The swing beats are fine with me, I got them on my first try.

3. I finished the previous demo, and I think this level's as fun as that. The double speed version's SO HARD though, the girl's just too damn fast! (this sounded weird in my head but whatever)

HELLO THREE MONTH OLD ONIONBLAZE, how's it going in December?!! hehe thanks for the feedback as I think I tweeted awhile ago.

--

General update: yeah releasing one level every week or so my foot. We won the IGF Student Showcase thingy (thank you for your support!), since then it's been about visa visa visa and trying to get a build suitable for the exhibition. With physical buttons! And drop in two player mode for all the levels!

..But yeah that's not going especially well, seriously this degree is absolutely killing me, I mean it was before but now it's slaughtering me, deadline to deadline like really I would be a zombie if not for certain people, its just asdgasgdasgsfdgdsf KIDS DONT GO TO A PLACE LIKE CAMBRZZZ IF YOU WANT THE LUXURY OF SLEEP!! lab-report-latex time bye

[Builds]

Hi guys,




Builds
>>PLAY LATEST BUILD<<
Play prototype of latest level.

Current WIP level in second link: "Steinway" prototype 19/12/2013, an acoustic piano song recorded in the studio of Churchill College, Cambridge.

Fun stuff
Kanye - Power

Press & Feedback
Eurogamer
"a rad Rhythm Paradise-esque browser game (...) sadistically difficult."

Indiegames.com
"The base mechanic and premise of Rhythm Doctor are gold for me. (...) Rhythm is in everything, and I'm glad the developers found it in medicine."

Reddit thread
"You've really nailed that quirky Japanese game sort of personality, that often really quirky and surreal sense of humor with a gentle sort of grounding to it. It has a resonance to it that most flash games don't." - Clumpy



that brilliantly shows off the game. Made me smile all the way through! Thanks BluBerryGamer

Summary
Rhythm Doctor is a tough ONE-BUTTON rhythm game heavily inspired by Rhythm Heaven!

For those who haven't played Rhythm Heaven, the defining feature of the series is the extremely strict margin of error, compared to any other music game out there. This means many people don't even realise their rhythm is a little off until they play Rhythm Heaven. My game seeks to emulate that feeling

I've been working on this on and off for two summers now. Most of the work believe it or not was making the engine precise enough to be playable. Many, many hours were spent making the engine accurate (Flash is not a good choice for millisecond accuracy.. but hey it was the most popular thing), testing it in different browsers and Flash versions, and I have come to the conclusion that the following is what you need so that the game registers a hit only when you are PRECISELY on time (within 0.02s):

Browser: Anything but Chrome
Flash Player: 11.4 or above

A lot of thought went on whether I should just make the margins wider to compensate for lag, but then that would just turn this game into just a typical Guitar Hero / Rock Band game which I don't want.

This DevLog
There is a topic in the Playtesting section already, but I thought it would be better to post the minor updates over here, and also we'd like to hopefully update more frequently on a weekly-ish basis. We'll also update the WIP link above with recent prototypes of gameplay ideas. You'll only get to play the level that is currently being worked on of course, so keep checking back here for new levels lest you miss out Come hang out!


And finally, Update Number One
This latest level serves to introduce swing beats. For those who play it, feedback on the following would be much appreciated!

1. are you a piano player, and as a player / non-player, do you feel the changing focus of rows managed to emphasise the dichotomy of treble and bass? when switching from the bottom row to playing the first four for example was it obvious that you were now following the bass melody?

2. were the swing rhythms (DUM daDUM daDUM daDUM) and inverse swing rhythms (daDUM daDUM daDUM da) intuitive enough to not require explanation?

3. difficulty: have you completed the previous demo, and how enjoyable was the difficulty on this one?

Thanks!