🤑 Indie game store🙌 Free games😂 Fun games😨 Horror games
👷 Game development🎨 Assets📚 Comics
🎉 Sales🎁 Bundles

Itooh

7
Posts
4
Topics
4
Followers
22
Following
A member registered 1 year ago · View creator page →

Games

Recent community posts

The Great Escape of Giele the Explorer is a narrative game about journey, fiction and escapism.

Giele has lived many adventures across the world. But has he discovered all of its secrets? Join him in his last journey, where wonders, dangers and friendships await!

Available on Windows, Mac and Linux

This is my first 3D game! It is thus quite short and experimental, but hopefully still enjoyable. Boy, 3D modeling is harder than expected! (I'm still proud of my ridiculous models, they're the best)

Also, it is the first time I write fiction in English, which is not my native language. I hope I haven't make too many mistakes, but if you see anything akward, I'll be glad if you can provide some feedback on that!

Anyway, I hope you'll have a great experience, and maybe even find your own adventure!

Welp, that's it.

As I mentioned before, the game suffer from a bug on Windows. This is actually due to an error in Unity regarding audio that needs to be fixed.

In the meanwhile, I have other projects I want to try. This one's purpose was mostly to learn unity and rhythm in game. This goal is already fulfilled.

So instead of wasting more time on it, I will simply move on. I think it's for the best.

I've made some fixes since last time. The game have now more feedback, and is easier for notes starting measures. To go more into details:

  • Beats length have been increased so that their alignment is more readable
  • Wrong beats don't make sound anymore, and appear red
  • Player can actually play one beat before their measure. This way, they can have a little advance that will still be validated.
Last but not least: due to that bug on Windows, the game is better to play on Linux. Yup, it's kinda unusual, I agree. If you still want to play on Windows, you can. But you will have to cope with the delay, which mean you will have to play beats a bit in advance. It's not that hard (it actually feel like playing some real instruments), but it's less good in term of sensation.
Anyway, I hope you will enjoy the game as it is. If you try it, feel free to let some feed-backs!
If Unity fix the audio error, I might update the Windows build of the game so that it is perfectly playable. But I don't think I will come back to it to finish it. Now, I have other priorities.
Thanks for reading!

Happy New Year everyone! Today, I have some good news, and some bad news.

Let's start with the good one: Bongo Machine is available in open beta!

Bongo Machine

(click to access)

This beta includes the first level, with 3 difficulty modes. I've even been able to put some music for the title screen and menu! Right on time for the end of 2016! However, you won't be able to save your score. If you find any bug (actually you're likely to), please report them to me.


Now for the bad news… Well, it appears that Windows version has some latency! A very little one, but for a rhythm game, it's enough to make it less enjoyable. I've tried several things to fix it with Unity, messing with audio settings and the sound assets properties, but to no avail.

So, unless I succeed to work around this huge performance issue… I think I will simply cancel that project. After a few bug fix, and an implementation of the save system and some bonus content, I will just let it in this beta. I have other projects in mind, I feel they would be more interesting than struggling with a flawed game (that was supposed to be little).

Of course, there is the eventuality that this is just bound to my machine, or that I'm the only one bothered by this latency. Although I seriously doubt it, tell me if you have the same issue.


Last but not least, I would like to talk about the game's timing again. Especially, if you are trying out the game, you can help even further in that aspect if you are motivated! I will explain.

Lastly, I said that 0.056 seconds was an optimal delay. Actually, I was wrong again. During a test, I've been stuck on the same measure for at least two minutes, and trust me it's frustrating! This made me think about the purpose of the game. How it defines rhythm, and why I chose in the first place to repeat each part until the player does the right pattern. And I've come to the conclusion that rhythm is less a matter of precision than it is about understanding patterns. Or at least, in this game. I want to be close to the feeling of a jazz jam: musicians might be slightly off for individuals notes, but that's okay, because the music their play is more about the pattern, and their global understanding of "the flow". Each note don't need to be strictly on the correct micro-seconds, as long as the rhythm is respected on a global scale.

That's why I decided to make the game less difficult! It isn't about being super precise, it's about understanding a rhythm in a song. Thus, I set the delay to 0.07.

However, since there is this latency with Windows… Well, I have to increase that value again. So it is now up to 0.1 seconds. That's right, it's pretty tolerant! But it's the only solution for now.

That's where you can play! On the game's first launch, a configuration file will be created (which path can be found in README). It contains only the mentioned delay. You can try to twitch the value to find the one you feel comfortable with. My preference is 0.07, but maybe this would be too easy for you, and you would like to try 0.06 or lower? Or this is still too punitive, and you want 0.08? You can try different values, and tell me your favorite one! I suggest though that, between each try, you listen to something else, and try a different activity. This way you will come fresh each time, not like me who have done test while I had still the rhythm in mind and, unable to detect the difficulty, concluded that “0.055 is too hard but 0.056 is okay!”.


Anyway, have fun with the game!

Allocating time for this project is harder than I planned. But still, making progress!

Now it only needs some particles, and it should be good.

***

Also, I've come across another issue. It is still related to the game's difficulty, and my attempts to make it the less frustrating. It's simple, look quickly at this screenshot, and guess if the dot are aligned:

<img src="http://pix.toile-libre.org/upload/original/1481393507.png" >="" <="" p="" data-vivaldi-spatnav-clickable="1"> </p>

If you'd have just a quick look, you could think that they are. But…

Problem is, the player doesn't have the time to check the alignment. Once the measure is done, everything is erased. So they have just a fragment of a second to tell if their beats are roughly the same as the ones above. More than often, it appears that yes, they are. But the game quickly remove everything to reveal that no, they weren't. Players don't have any clue about which one was wrong, and if it was too late or too soon.

This is kind of a recent issue, since the game was originally designed with the two lines close to each other. But I then had the idea of a screen split, and moved them on both side. Now that they are far away, they have become less readable!

So far I came with two solution. The first one is to draw a grid on the screen.

This fix the issue, but… It's a grid, and it's ugly. Not only it makes the screen too loaded, but it also make this presentation feels more… "mathematics". It can be improved visually, but it would still result in the beat presented as a grid, and not just an indication relying on the music.

Alternatively, I could add some animated beats that would go to the center:

Again, this could work fine, but… I'm feeling I'm adding complex behaviors to a simple system, just to answer a specific concern. Why would there be additional beats? Why going to the center? Do they disappear then? Or should be they displayed under the textual feedback?

There are other imaginable way. Like instead of making beats appear on the lines, they come from up or down to a central line. This completely change the current look of the game. And again comes the question: where would we display the text? I like the symmetry, and I'm trying to figure out how to keep it while solving this problem.

So for now, I'm going with the grid. I'll try to make it look nice, and not too invasive. Maybe I'll come with another idea latter. Suggestions are welcome!

(Edited 1 time)

Lately I had to make some game-design decisions that are worth sharing.

But first, some fonts:

Main menu

Lovely fonts. Although I'm still not sure about the color for the game screen's text. It has to be blue, but… Meh.

Also, I've discovered that the game is incredibly hard if I let a delay of only 0.55 sec before and after each beats. So I've twitched this value, and found a nice balance with… 0.56 sec. Yep, turns out 1/1000th of a second can really have an impact! Still, I think I'll need to add a "calibration screen" to the game. The comfort zone might vary for each player.

Anyway, let's talk about the main subject! I want to explain how the score system work.

The Score in Bongo Machine

So, here is my initial idea, that was first implemented:

  • Player get a rank at the end of a level. Ranks go from D (lower) to Perfect (higher).
  • When the player finish a level, they unlock the next one. Ranks allow them to unlock some bonus content. There are five bonus to unlock: one for each rank superior to D (C, B, A and Perfect), and one for completing the level in hard mode.
  • Rank is determined from the number of mistakes the player does. The player starts with a perfect score, which is the number of measures (playable parts) in the song. Each time the player fails a measure, their score goes down by 1. As the player plays the same measure again, it keeps decreasing when they fail. At the end of the song, the player gets perfect if they have still all their points, A if their points are higher than 2/3 of the initial score, B if higher than 1/3, C if higher than 0, D for 0 and below.
  • When player fails a measure, the screen gives them a feed-back with a red "FAILED". When they succeed, it gives them a different feed-back according to their number of tries for that measure: "PERFECT" on the first try, then "EXCELLENT", "GREAT", "NICE" and "OKAY".

That's all. Seems pretty simple and fair, right? Well, actually, it is fair! The problem is: it doesn't feel so.

First, feed-backs don't predict correctly player's final score. They seem to correlate to the rank, though. But since we're decreasing for each mistake, and not calculating an average, they don't give any real clue about what the final score will actually be. For example, a player can miss every single measure only once: they will have an entire game of "EXCELLENT". But their score will be 0, and therefore they will have a D! A little bit disconcerting.

There are several possible solutions. One is to compute an average instead. But with that few ranks, players might not see a difference between two different games (say, one consisting of only "EXCELLENT", and one with only "PERFECT" and an "EXCELLENT", would both give an A, although the player improved a lot). It seems coherent to me that a player missing all measures, even if only once, would get a bad grade.

Another solution, more brutal, is to get rid of the nuances in feedback. Since they don't give clues about the player's global performance, they are only confusing. We can just keep "FAILED", "PERFECT", and "OKAY". Player will know that succeeding on the first try is good, and more attempts are just accepted, but will have an impact on their rank.

But there is another issue I didn't mention yet! Well, I did in the introduction actually: the game is hard. Purposely hard. Not because I want it to be "for hardcore player only", but because its goal is to teach player to practice until they get a rhythm perfectly. So when they fail somewhere, they repeat. Again, and again, and again. Until they master it. There is failure, but no fail state: you win the level eventually. And you do because you learned it well. Demanding, but not punitive, is the game's core philosophy.

Except it does feel punitive! That's a big issue I hadn't foreseen. I played with a tight margin delay, and had a lot of failed measures. That was infuriating. I was getting stuck on the same measure, each time making probably a little mistake on only one beat. But that was enough for the game to tell me that I've failed ("all or nothing"), and keep me in the same part. As with every rhythm game, I started to doubt the accuracy of the machine. Sometimes I felt completely offbeat, and it would still accept, and other times I had the impression the game was just not cooperating! But it had been tested, and it works fine (… I think). It's just the difficulty was too high for me. This is why I decreased it a little by according an additional 1/1000th sec before and after a beat. However, it is still likely that some players will get stuck like me, and it won't be fun at all.

So, how to change that? I still want the game to be difficult, but I don't want it to feel punitive. And after some thoughts, I think I nailed one important mistake I've made: when the player does a mistake, the only answer they get from the game is a big red "FAILED". And this plays a lot in exasperating the player, and making them feel like the game is too hard for them and doesn't want them to succeed.

So I've made a simple, but quite important change. When the player misses a measure, the first two times, they gets a "FAILED". But after the third failure, the message becomes "YOU CAN DO IT". And let's be even more encouraging: if they do two more mistakes, the game will display "DON'T GIVE UP"!

Also, remember how I explained why I gave up the nuances in positive feed-backs? Well, I've came back on it (again). Because actually, diversifying messages creates a dialog between the game and the player. It's not just a cold "GOOD/BAD" indicator, but a more precise acknowledgement of how the player is playing. It is actually pleasant so see the game reacting differently for each one of your success, and in a quickly understandable way: the less you fail, the more positive the game is. But when you fail too much, instead of being neutral about it, the game becomes more patient and encouraging. Therefore, we changed "If you play bad, you will have a bad remark" into "If you keep getting better, I'll will applaud even louder". Oh, "EXCELLENT" also became "GREAT" (and "GREAT", "GOOD") because it feels less judgmental, and not linked to the rank.

Lastly, I decided to stop decreasing the score if the player does more than 4 mistakes in a measure. Getting stuck on a particular segment will still be really bad for the score, but not as much as initially. The game should let you learn without necessarily giving you a D.


I'm quite happy with those decisions, and how the game feels now. It was a great learning by experience!

Coming next: some animated backgrounds!

Bongo Machine is a a two-buttons rhythm game based on a mechanic that everyone knows: a rhythmic pattern is played, the player has to repeat it. Actually, it can be summarized better in a gif:

The game is composed of several songs, each with their own time signature and patterns. Songs are divided into several measures. that loop until the player play the correct pattern. Which means that to proceed through the song, players have to play correctly every single segments!

The game is thus mostly about learning (and rehearsing) different rhythms. Score are calculated by the number of repeated segments. Play all the song correctly in a row, and you get a perfect! If you have to do some parts several times, your grade won't be that good. But in the end, everyone will reach the end of the song, there's no fail state. And songs are designed to sound great even when looping!

***

I've been working on this project since mid-September. Its purpose is for me to learn how to use Unity, and to use music dynamically in games. My main inspiration here is Rhythm Heaven, a very basic rhythm game that can be really challenging, and actually teach some musical concepts!

I'm also learning music composing, which sure will be really handful!

So far I've been able to create a prototype that can track the rhythm of any song, as long as it knows its time signature. Then it can play a partition on it, and expect the player to play it back. There is even three difficulty modes

I've also very recently been working on the game's look! Previously, it was just an ugly prototype, and it is only since this month that I made my decision about how the art should be. I opted for a minimalist design, inspired by 140 and Jazzpunk's intro.

Finally, I've spent most of October composing the first song of the game! Here is a little preview:

***

What's next then?

First, it would be great if a level could actually be finished. Currently it just loops on itself. So next thing for me will be to give a score to the player, and redirect them to the track selection menu. Also, I need to save player's score, and lock/unlock levels, as well as some other unlockable bonus (more on that later).

The art is not done either! This needs some background, with a music visualiser and a fake scrolling to make it dynamic. Colors must also be configurable by song, so that each level has a different color set. Finally, I need to find a nice font to use in menus, and of course for the title.

The last big part is… Well, the songs. I have one so far, but I plan to have three levels. So I will probably spend most of my work on those last two songs! I already have some ideas for them. Oh, and let's not forget a little music for the game's menu.

***

My goal is to release an alpha version before the end of the year, with a single level. Then I hope being able to release the full game early in 2017.

Thanks for reading! Your thoughts on this are welcome.

I like the trailer's atmosphere! The sound-design does a very good job.

I'm wondering: does it have jump-scares?

(Edited 4 times)

CodeMirror is used? I guess that's good to learn. :)

I've just made some experiments with it, and it turns out it already has such a functionality! There are two commands for searching : "find", and "findPersistent". The second one isn't bound to any keys by default, but it is used in the search interface demo. It quite does the job: searching is immediate, and requires only to press one key.

All there is to do to integrate it is to add the command in extraKeys in the options on CodeMirror instantiation:

var editor = CodeMirror.fromTextArea(document.getElementById("code"), {
  mode: "text/html",
  lineNumbers: true,
  extraKeys: {"Alt-F": "findPersistent"}
});

I also tested it with the Sublime keyMap, and it works as well. The keys can overwrite an existing command by the way.

Maybe the best choice should be to keep the Find command as it is now, and bind this one to another key combination. Maybe "Shift-Ctrl-F", or "Alt-F" as in the demo (though it's not the most intuitive, but eh, that's mostly my opinion). That's up to you to decide.

Now that I'm thinking of it: are there any plans for a keys/shortcuts personal configurations?


Update: After exploring Superpower's source code, it seems to me this should be done in the textEditorWidget plugin. Should I create a pull request?

Hello! I've been using Superpowers since January, and I'm really enjoying it. I especially appreciate the integration of some Sublime's shortcuts (multiple cursors, YES!), and the recent adding of darker themes.

There's just a very small annoyance I still have: the search function in script editor. It certainly do its job, but it requires first pressing Ctrl+F, then Enter (after typing something of course), and finally F3 to browse results. And… Apparently that's too many steps for my little brain. I keep pressing F3 just after Ctrl+F, or using Enter to browse (which doesn't wok). Most editors I know has only to steps for searching (Ctrl+F, Enter, Ctrl+F F3, Ctrl-F arrows…).

It's a minor issue, yes. But it happens almost systematically, and keep breaking the flow. So I would like to suggest: after typing, could "F3" validate the search just like "Enter"? This way the GUI behavior doesn't change much, but searching require less moves.

If it's more complicated, I hope this remark has been useful anyway! :)

I like the minimalist design! :) The core concept has also a nice rhythm and puzzle vibe.

I had some difficulties to manage jumps correctly. But overall it's responsive enough.

Nice job!

(Edited 1 time)

Hello everyone!

I've just released my first game. It's called Deep Sea School, and it's about being a shark in a sea full of various living creatures.

shark eating lil fishes shark talking to fish

It's a game of little discoveries and secrets. Kind of a toy-box with the “more than meet the eye" idea.

You can play it right here! Feedback are appreciated.

***

The game was made with Superpowers. I must say, so far, it has been a great tool to learn game development (also Typescript and ES6, by the same occasion)! I highly recommend it.

I intend to make it open-source. I will first do a quick clean-up in the code before putting it on github. I'll update the game page then.