[Artificial Intelligence.]

It may be painfully silly, but at least it shows that I finally have the cutscene architecture up and running! Took me a little bit longer than I would have liked but at least now I have a system where I can add new functions to the cutscenes very easily!

Anyway, now that I've gotten that out of the way, it's finally time to move onto the next section of development and let me tell you, this next thing I'm going to be working has had me nervous for a really long time. I've actually spent much of today researching it but to little avail, it seems a lot of the examples online for it are rather specific.

Simply put, next up on my plate: Artificial Intelligence.

For the longest time, I've had absolutely no idea how I wanted to pull this off. I've been looking around everywhere for the different AI design patterns but they've been deceptively difficult to find! Right now, the only ones I've really been able to find/remember are Decision Trees, State Machines and Goal Oriented Something or Other. I think with the architecture that I have right now, I'm probably going to be leading towards decision trees, but how to pull it off, I'm still considering.

Regardless, I'm extremely excited to get started on it once I have it figured out. Having AI in the game will be the biggest jump GODHOOD has taken to being an actual game in months, at least since I implemented the rhythm mechanic. On top of that, I only have basically two more features (one small and one big) before the engine is considered complete and I can move onto the game phase!

Anyway, wish me luck! I'm going in...

Got an episode up today on the progress I made with the menu elements as well as the stage editor!



Also, I've been getting some work done on Cutscenes. It took me a while to decide what I should do to test them out, as in, should I make a cutscene about Riff and Avadra like in the final game, should I make a cutscene about Waki and Smunch or should I just go full deadpan and have a cutscene with pure test elements, ie "this is a quad", "this is a sound", "this is a subtitle", etc. The latter was way too boring, and while it would be fun to do some art of Riff and Avadra, it would unfortunately take too long at this point and it also wouldn't fit with what I've got, so in the end, I decided I would make a cutscene about Waki and Smunch. This unfortunately means I have to construct possibly one of the silliest, somewhat ham handed cutscenes known to man.

With that said, I have the cutscene all storyboarded out with some even sillier art:



With that done, I went ahead and drew up all of the individual assets, which in short, is basically all of the Waki frames, the pieces of his """""house""""" and the accents/exclamation marks. Before I got started on the cutscene architecture though, I wanted to dress up what I already had!

First off, I decided to give the loading screen a little bit more flare by adding the ability for fade in and out different images. Here's a quick example complete with tiny mouse pointer.



Right now it's literally screenshots of the game, but come time for the game phase, the loading screen will basically show artsy previews of what's going to happen in the level. Or they'll still be screenshots, depends how fast I am at drawing.

After that, I decided to test out one other plan I had for the main menu; having the very first scene of the level in the background! Since this involves sound, I decided I would record a quick sample of how it looks



The idea here is the entire level is front loaded, and since the main menu is a part of the level, as soon as you hit start, it transitions right into the cutscene. I'll admit, I drew inspiration for this from the first Infamous game where the first time you push start, the second you push it, a giant explosion happens in the background, effectively kicking off the story (which is, more or less, pretty much the same way my game is going to start too coincidentally).

Anyway, regarding cutscenes, I found myself really stuck for a while on how I was actually going to construct them. As I thought about it, I slowly came to the horrible realization that I was going to get stuck in XML hell if I were to just script entire cutscenes that way. It's a terrifying idea to watch a cutscene, find out there's a slightly misplaced prop, fix it in XML, than rewatch the entire cutscene hoping it looks better. As I thought about this, I was thinking to myself, "If only I had some sort of editor in which I could load objects, orient and place them in a scene and then save it to a file..."

And then it hit me.



I already have exactly that! The stage editor! While it's not a full blown cutscene editor, it does present itself as a great way to neatly place objects. I just need to design Cutscene such that you can additively render stages on top of each other in such a way that one stage is the background, while another stage is simply the character frame!

Anyway, I still have quite a bit of work to go on cutscenes yet and I haven't even started the gameplay cutscene yet. I'll probably give a more indepth explanation of that next post.

p.s. for those of who are still reading,

.

[no undo]

Leaps and bounds have been taken in the stage editor! Fortunate for me, basically all of the changes as well as the stage I designed can be summarized easily in one screenshot:



To keep things short, I have:

• Implemented Text Lists, which is basically a list of selectable strings
• Implemented an asset list (on the lower right) from which you can select stage objects to spawn
• Implemented a scene object list (on the left) which is literally just that, a list of all the objects in the scene which can be used to select, go to, or delete specific objects in the scene
• Added the ability to load graphics resources from other locations (Set RSD + Set Pack Root)
• Added the ability to actually save the stage!

Of all the things I added, just creating the Text List took a crazy amount of effort. Just getting a scrollbar that behaves like a typical scrollbar was by far the hardest part and the math it uses to calculate what part of the list it should show when you scroll is not very pretty. It probably didn't help that I started it during my catsitting escapades and on the morning I started the scroll bar, I had gotten 2 hours of sleep. What matters now is that it's done and working!... for the most part!

With the stage editor ready to go, it was high time that I started actually developing a stage with it. Rather then creating something extremely simple, I thought, why not create something a little more close to the final game? With that in mind, I decided to create a stage very loosely based on where the first level of the game is going to take place!

Now before I talk about the stage itself, I have to say, something I sort of knew but very much learned when I started working on the stage; the best way to bug test your software is to use it like a normal person. In short, I ran into a lot of bugs creating that stage, and I even thought of a few features to add in the process (like a copy paste button which very much came in handy for spamming road sections and sidewalks. Unfortunately, the major downside to the stage editor at the moment: no undo. I figured that an undo button would be an extremely difficult thing to add because I'd basically need to create an opposite action for every action you could take, so I thought I would just omit it and deal without it for now. Still sad when you hit ctrl+z though and nothing happens.

Anyway, after only about 1.5 hours of work, including the amount of time it took to create the stage objects in XML + texture drawing, I got the stage to the point it's at now. Here's how it looks in game:



A little (extremely) cartoony, I'll admit, and there are certainly a number of scaling issues, namely in the width of the road as well as the size of the actual city block, but seeing as this is all placeholder, it serves the purpose of giving me a really good idea of how big the stage will need to be once I get to the game phase!

The big unfortunate thing about the stage now is that there is currently NO batching (that I've coded in the last year and half) in Fire2D, so while the game is fine in release mode, having 150+ drawcalls on debug mode is really taking a toll on the FPS. I don't know if it's clogging the graphics pipeline or if there's something in the standard library that I'm doing that just chunks the FPS on debug, but either way, eventually, I'm going to need to scrounge up some sort of dynamic batching.

Anyway, now that I have stage behind me, it's time to move onto the next part of our engine: Cutscenes! This one, I'm fairly confident, will be a pretty quick task as half of it will be simply making a class that accepts an XML depicting "Show quad here, play this sound, show this subtitle, now show this quad" and so on. I have a very set plan on how I want to do the cutscenes, but I think I will go more in depth on them on my next update, once I have a little something to show.

[same]

So, I gave this game a quick jaunt, and by quick, I mean I accidentally ended up playing it for a whole hour. Definitely a fun game once you internalize how it works! Here's what I thought:

1) Are the instructions clear

• The rules, seeing as they are pretty simple, are definitely easy to understand! The only issue I had with them (which might just be an error on my part) is the fact that the first time I looked at them, I completely flew past the "next page" button and ended up missing four pages of instructions on my very very first play. Fortunately, I could very easily tell that I was missing something so I checked back again. I don't know why, but usually, I expect there to be BIG next/prev page buttons on the bottom center of the screen. Up to you though, as I'm basically saying they weren't fully obvious for people who try to speed through the instructions.
• Thanks to the fact that the game is centered around colors, it does end up playing somewhat intuitively as well, although I can't deny that when I first started playing, I certainly had a few mismatches from bad memory.
• One issue that I think probably goes without saying is that this game probably presents a problem for colorblind people. I know that's pretty much an obvious statement but I only bring it up because I myself am actually mildly colorblind. It's mild enough that I didn't have any trouble differentiating squares from each other, although the extremely tiny color palette guide in the bottom left corner did give me a bit of trouble, particularly in discerning the green/yellow/red area. You might want to consider either making it bigger, clearer or just separating each of the color combinations in such a way that they don't merge together.

2) Is there anything that needs to be clarified or explained better?

• Very minor thing, but you might want to consider putting a little more emphasis on what the limits are for primary and secondary colors. Seems like they get a very tiny footnote despite being an extremely important pivot point of the game itself.
• Moving away from the instructions and into the game itself, it might help to have a visual clarification in game regarding the limits as well. Right now, when you try to combine something past its limit, your feedback is basically a buzzer that basically tells you you're doing it wrong. I nice touch might be to make the numbers flash red quickly in case you're trying to combine something past its limit. I know they number is dimmed if they are capped out but as you can see, people like me are still going to try and merge them, haha.
• This might be a stretch as it kind of makes the game slightly easier, but also for people like me who think they're making one color combo and end up making another, a really nice feature would be some sort of indicator that shows what color the player is going to get when they combine two certain blocks, maybe something like a colored outline that surrounds the block being changed(ie, select a red block, then mousing over a blue block shows a magenta outline around the blue block). I realize this takes some of the challenge out of it but the way I see it, it only removes the memory game where people are punished because they forgot what color they're going to get and instead, it lets people focus more on the planning aspect of the game in terms of properly arranging the pieces.
• A quick thing to add on the previous note. I'm assuming from the game's aspect ratio that there might be a plan to port the game over to mobile eventually and with that, there would be no mouse to hover over blocks, therefore the highlighting thing wouldn't work out. On that note though, I was planning to save this note for the gameplay but I nice feature that you could add next to the two click system(click first block, click second block) would be just a simple dragging system where you could drag the first block onto the second.
• A tiny suggestion, it might be nice to have the click events based on mouse released rather then mouse pressed. That way, if someone clicks on something but then decides against it, they can drag the mouse away and not commit an action they didn't want.
• Last tiniest note. it might be nice to add a footnote to the instructions that you cannot combine two capped squares of the same secondary color. I know it's pretty much implicit in the instructions but it might be nice for people like me who made an entire attempt around combining two and then being like "oh".

3) Is it fun?

• Well, after playing it for pretty much an hour, I can't deny that it was actually quite a bit of fun! In the end, my favorite mode ended up being 100 turn mode, as it was the most easily achievable goal within a reasonable amount of time.
• The first mode I tried was normal free play mode. While it was definitely a good sandbox introduction to the game, I find with the way the white blocks work (which I will get into in a moment), free play has the potential to stretch onto a ridiculous eternity if you're good enough at the game.
• It was kind of funny with arcade mode actually. I had no idea what to expect when I walked in, but as soon as it started, my first reaction was "OH MY GOD, IT'S TIMED!?" This was a reasonable reaction because no matter what, I am getting absolutely destroyed at arcade mode. I can barely get anything done because I either fumble the blocks around like a crazy person, or I combine two blocks expecting one color, but instead I get another, or I just end up white blocking myself and everything snowballs downhill from there. Perhaps I didn't allocate enough time to getting good at it but I feel like the arcade mode is maybe just a little bit too fast. Maybe a nice change to it would be to have it start slow and then speed up ever so slightly with each block you combine
• Again, 100 move mode is probably the mode that best suits the game as it allows for the player a reasonable amount of time to think while ending the game also in a reasonable amount of time. It was actually the mode that gave me the best sense on how to approach the game in such a way that I get the most points possible!
• After a little while, I found that the best strategy was to basically line the bottom row with each of the secondary colors and then try your best to funnel all of the primary colors into each appropriate column. Fortunately, this isn't a dominant strategy because sometimes you can get in a bad situation where there is no good outcome except for starting a new row of secondaries, which is definitely a good design aspect!
• One aspect I found interesting about the combining mechanic was the fact that the most combining a 10-10 gives you 5000 points and that combining a 15-15 gives you... 5000 points. With that in mind, the most optimized way to get points would be to always match secondaries to exactly their cap which I guess is a valid way to make it challenging but I just find it odd considering there are so many games where the objective is to make the biggest combination possible as opposed to the most exact combination possible.
• One aspect I found a little weird was the white block system. I can totally understand why it's in place as it makes a lot of sense for a game about combining colors but the way it's implemented is a little weird. I'm more or less referring to the fact that white blocks only come into play on the account of player error. While I can see why this has its place for something like arcade mode, I find that it was always just a huge punch in the gut to get nailed with one simply because I misclicked or miscalculated a combination. The thing is, once you get one, they have such a huge impact on the gameplay that I found whenever I got one, I would just restart the game instead of trying to play it through because any chance I have at a highscore is basically out the window once I get one.
• A quick side note, due to the transition animations for starting a level and quitting a level, I found that a faster way to get back into levels was to literally just quit the entire game and relaunch it. Kind of counter intuitive if you ask me, you guys could use a restart button in your menu.
• Back on the white blocks, another weird aspect about them was the fact that in 100 move mode, I got to a point where I basically had no moves I could make, there was basically nothing I could combine without getting a white block. Now I don't know why I expected the game to just end at that point, I guess I'm, once again, too used to other games that just show a stop game over and boot you out, but with the white block mechanic in place, you're only option is to basically shoot yourself in the foot to get the ball rolling again and again, I find myself just restarting rather then letting a white block sit in.
• If you're taking suggestions, one thought I had about the white blocks is that maybe they could basically disappear on a timer who's length is determined by the numbers on the blocks you combined? Like, combining a 2 block with a 4 block would make a 6 white block that would disappear after 6 turns.
• To end on a positive note, I will say that I had a lot of fun with one moment where I could have sworn that I was going to have to white block myself with only 3 spaces left at the top, but I ended up resolving the whole situation back to a clean board. Definitely a moment that feels good!

Anyway, that's every aspect of the game that I can recall at the moment. I do find the actual puzzle elements of the game very fun and rather relaxing, I'm just a little befuddled by the punishment systems.

By the way, my highscore for 100 move mode is 36800! :D

After a surprising amount of abject laziness, I finally got around to uploading that development episode about Meter and Stage which can be seen here:



In other news, I've made pretty good headway on the menu elements, I've already gotten sliders and checkboxes implemented into the game! However, since I've discovered that there isn't much configurable with the game quite yet, it's sort of hard to design an options menu and the like so I decided I might wait until I get to the game phase to figure out what should all go there.

Anyway, here's a quick view of how the different menu elements look at the moment:



I have to say, while designing a UI system is fascinating in how perfectly it fits with polymorphism, I have to say it is also one of the more tedious sections of game development solely because of the sheer amount of configuration you can implement into each UI element. Each element already has a pretty decent amount of parameters to change and I haven't even touched stuff like font/fontsize or button/pressed/hover colors.

Now, you may be wondering what's up with those options as "x y z" doesn't seem very elaborate. Well, to put it simply, I'm already half done creating a basic stage editor!



It's VERY basic and again, only half done as it still lacks the ability to spawn/delete objects or even save the scene. The rotation aspect also suffers from Gimble Lock because I'm a grumpy old man who shakes his cane at the quaternions on his lawn but apart from that, it is actually quite amusing to have such a thing at my disposal! I always thought that if I ever created an editor, I would have to invest weeks upon weeks into it (and for the more advanced aspects of my engine, that might still be the case) but no, I got this thing to where it is in only about 2.5 days of work. I'd say that it should be done in another day and half assuming the next UI element I implement doesn't go haywire on me.

I've gotten started on the main menu! I've spent a surprising (though not really if you think about it) amount of time implementing it because A) I decided I would do it right from the start and implement a fully polymorphic menu system and B) I actually realized that I haven't fully decided on some of the design aspects of the menu! I had an idea in mind but it turns out there was a few things I left unaccounted.

Eventually, I felt that if I was going to make a final decision, I should sketch up a few concepts of how I wanted the menus to look. In the end, I came up with two different designs that I was stuck on for a little while:





Before I go into detail on these menus, I'll say that I forgot to include a mockup of a crucial factor, the fact that the first scene of each level will display in the background, so the less space the menus take, the better!

Anyway, on the top, we have the easier to program and navigate linear menus and on the bottom, we have the more compact and customizable menus. The top design was what I originally had in mind for the game, but I found for certain menus I want to implement in the future, such as one to customize the rhythm bar, I wanted to have a system where I could have every option on the same screen in a grid. While this does make things slightly more complicated (sliders would need to be selected before adjusting, otherwise you would just highlight a different option if you hit left or right), I found that I liked it better layout wise as well because it takes up much less of the screen and it allows for more intuitive layouts. You could argue that I could just shrink all of the menus in the upper concept but then I feel like it would make things somewhat lopsided.

Anyway, that's enough of my reasoning. If anyway has any input on what they think would be better, I'd like to know! For now though, I've decided that I'm going to go with the lower concept for the better customizability. I've even already gotten started on it! I have to say, programming menus is oddly satisfying, it just fits into polymorphism like a glove. Here's what I got so far:



Definitely a ton of work to go, but at least the buttons work! My only gripe now is that it seems like Paint.Net has a different way of rendering text because the font looks more spindly in game if that makes any sense. Ah well, I'm sure that there's either some tiny shader trick or a way I can render out the text to buff it up a little bit!

I was intending to get this written this past weekend but recently, I've entered the cat-sitting business and while Fluffy is cute, he has also been waking me up at night so I have been so tired lately ._.

Anyway, last week, I finally got around to implementing Meter into character, which is basically a class that encompasses any sort of internal counter inside of a character, ie, a character's health or, in fighting game terms, a character's super meter. I've also set up a system to render a character's meter either in the game world relative to their position, or render it orthographically as a UI element.



To test if Meter is working properly, I implemented death animations into Waki and Smunch which are procced when they are hit and their health is zero.



Not the fanciest death animation but it's all placeholder anyway so it doesn't matter for now. Smunch's death anim is even less spectacular. Since Waki's attacks have no upward momentum, Smunch just immediately falls over and dies.

In addition to completing Meter, I also got started on implementing something a little more on the graphical side: backgrounds! Since I have a habit of referring to everything in fighting game terms, I've instead been referring to them as Stages.

Again, with everything being placeholder, I just wanted to get some basic assets rendering, so I quickly made some cubes and threw them around. Here's how it looks (at double speed, for brevity):



Currently, all of these items are placed with raw XML (including the cross which was previously just hard coded), which is fine for now, but down the line, when I start working on final game art, things will become much more tedious if I try to place every single element precisely with XML. So, for that reason, I've decided that I'm going to create for myself a very VEEERY basic editor.

All the stage editor is going to need is the ability to:

• Spawn objects from a list of stage objects
• Select objects from a mouse click
• Drag objects around to place them, scroll to move them in the Z
• Options to rotate/scale them
• Delete objects

The only thing I'm really nervous about on that list is implementing raycasting and mouse picking, and making the menu elements. For the former, I guess I'm just going to have to follow some tutorials. For the latter however, I've decided that if I'm going to need menu elements, then the next thing I'm going to need to implement into GODHOOD will be...

Menu support! It's time to take a small break from gameplay programming and move onto a little bit of interface! I'm going to need to implement a main menu, pause menu, options menu and a level select. The options menu in particular should require some interesting things, such as the good old fashioned sliders, check boxes and drop down menus. Once I have those all done, there shouldn't be any problem at all implementing them into a stage editor (assuming I program them right)!

On a final note, I have an episode for meter and stages already recorded but I feel like programming right now, so I'll probably just get started on all the menu stuff today and then edit the episode tonight. Probably for the better as editing and posting those videos eats up a surprising amount of time! You could argue that I shouldn't be doing them in the first place, especially with the low viewer count, but I can't help but feel that whether or not the game succeeds, it'll be fun to retroactively observe all the work that I put into it!

Finished implementing slow motion today! It turned out to be way harder to implement then I thought it would be but in turn, it’s resulted in a much more flexible system!

Originally, my plan was to implement a system where the game would only have slow motion settings for half speed, third speed or quarter speed and for each setting, update the characters every 2nd, 3rd or 4th frame respectively, but still simulate their movement so that they move at 60 fps. This turned out to have quite a few complications centered around what order each component of the characters was being updated in.

In the end, I managed to completely decouple the physics from the characters, allowing the two different aspects to operate independently of each other. On top of that, I’ve implemented a system where the game just reads the deltaTime and accurately keeps track of when it should simulate a tick instead of just updating every 2nd/3rd/4th tick. Here’s an example of the game running at 0.4096 speed:



Because the game now relies only on the deltaTime for updating the characters, that means I can not only slow the game down but speed it up too:



While the above feature is essentially useless for normal gameplay, the important thing to note about it is the fact that it’s using deltaTime! This is very important because it means that not only can this be used to simulate “fast motion”, but it can also be used on computers that have longer frame lengths, ie, lower frame rates! In other words, the game is no longer frame dependent and can now run at any fps, not just 60! This is good for me too because that thing I mentioned in my last post about needing to record with OBS and then Gifcamming the resulting video is no longer relevant!

A small thing that I'll need to account for with this new feature will be what happens if someone has a low frame rate causing them to simulate more ticks, which lowers their framerate, causing them to simulate MORE ticks. I think simply clamping the max deltaTime down to a certain value should do the trick!

Anyway, everything that I've mentioned above and in the last post as well is covered in today's episode of GODHOOD's development!

Alright, I'm about half way through my odds and ends list right now, basically tackling things that are too small to call a features but are still very important mechanics.

On the coding front, I've whipped myself up a quick config class! Instead of having raw tinyxml2 calls all over the place, now I have a class that conveniently takes care of all the loading, element access and saving. It has some nice perks too like only saving a config if changes were made it and above all, there's also the ability to add new parameters or even entire new config files from code. Seeing as it only relies on tinyxml2, I almost felt like I could upload the source except it's pretty (extremely) simple and I'm terrible for proper const correctness.

It's nice though, because it's allowed me to quickly whip up configs for multiple parts of the game without having to actually write the XML. Here's what it generated for the BeatMaster:

Code:

<Config>
    <AudioLag value="160"/>
    <RhythmBar speed="1.0" height="0.200000" width="0.80000" yPos="0.0400000"/>
</Config>

Gonna have to do something about those trailing zeros...

Also, if you can't tell, I'm kind of a sucker for XML. I realize that this would probably be much more efficient if I just did the ol' plain text file sort of config, but I just find this way much prettier!

After that, I (very nervously) added some new features to the collision manager. I've added protection for cases where characters spawn inside of each other to make sure they don't spawn stuck inside of each other. I also added support for phasing in such a way that characters can move through each other! Basically, dodge rolls or dashes like in the example below.

(ignore the dots)


Thankfully the additions only took about a day to implement which is a MUCH better track record then how updating the collision manager has gone previously!

Finally, I ended off today by getting the very (very very very) first implementation of an actual automatic camera!



Fun fact, now that Gifcam kind of causes the game to lag a little bit (a lot), I've resorted to recording the game using OBS and then recording the resulting video with Gifcam. At least this way, I'm guaranteed to get full 33fps on all my gifs! Kind of annoying though >:C

Anyway, as you can see, the camera is currently not a really good working order. It's extremely slow and even has trouble keeping up with the character when ever they're falling. I figured that the best way to fix this would be to increase the speed it moves at as well as the distance it tries to lead the character.

Unfortunately, if you like turning...



I can't say it's worked out the best. Definitely, this is something I'm going to need to put a little time into just trying things. Should be an interesting learning experience none the less!

[The rhythm mechanic is complete!]

The rhythm mechanic is complete!

Fortunately this time, basically everything that I had left to do with the rhythm mechanic can be easily summarized by one screenshot!



Simply put, over the past week, I:

• Created a new beat set using this sample (visible on the right side of the rhythm bar)
• Implemented variable beat lengths (quarter notes, eighth notes, sixteenth notes, etc) represented by the bars being different sizes.
• Most importantly, implemented the ability to transition from one beat set to another!

Of course, the rhythm mechanic will never truly be 100% done. There are still a few very tiny bugs in it and there will always be improvements, but at this current moment in time, the rhythm mechanic is game ready!

I go over all of the changes I mentioned above in more detail in the following devlog!



Finally, while just browsing tumblr, I came across a post that seemed all too relevant to GODHOOD, so I decided that I would reblog and doodle something up for it:

New development episode up!



Simply put, this episode basically covers the implementation of the rhythm bar that I discussed in the last few posts! Now, onto adding stuff to that todo list!

The rhythm bar is complete!



I'm feeling really good to finally have a nearly finalized asset in the game. I'm so used to working with just placeholder art that it feels strange just to have something final. Who knows though, there will probably be some small changes that I make to it here and there in the future!

Anyway, this was the last thing I wanted to do for this episode of development so all I have to do now is edit the footage together and then I'll be good to go.

Now that I have the rhythm bar done, it's time to start implementing a bunch of really quick small systems that the game doesn't have yet. I'm not 100% sure what all that is yet, but there's definitely a few things so I'll probably be compiling a todo list soon.

For now though, I might just quickly unwind with some drawing and then get back to business tomorrow!

p.s. I love particles effects <3

Ah damnit, I knew that there was some sort of proper route to 2-1. Now that I applied the route shown in your picture there, I was able to get the star and beat the level in 40 seconds on my first attempt. Don't I feel foolish!

For reference, here's a rough sketch of the route that I took:



Also, as I've just learned, I'm no expert on the whole slingshot effect myself! I actually didn't know it took into account the movement of planets as well, that's pretty neat so I guess you can just ignore that note as well haha

On the note of me not knowing how to pause, it was, embarrassingly, a small combination of both to be honest. Another part of it is my fault too because at one point, I thought I hit the back button when I actually hit the home button instead which brought me out of the game so for a while, I thought the back button did nothing. In other words, for the third time, my bad, haha. Although, I will admit, when I was going in, I was expecting something like this (the upper left corner):



It wouldn't need to go specifically there. Anywhere would do as long as it was in plain sight!

On the note of my suggestion regarding how you could change gravity, that's cool. I kinda figured my idea would be a bit too heavy a change to really work.

In lieu of that, however, now that I know that every puzzle was basically designed with an optimized path in mind, it might be nice for people like me who cannot for the life them figure out what that path is to have a hint system. Maybe if the player fails a level five times in a row or is just taking an exorbitant amount of time just to complete it, you could provide the player with a hint button that shows maybe either the start of or the entire path that the player is intended to take, sort of like a cleaner version of the image you sent me. That would definitely cut out a good deal of the frustrating aspects if you ask me!

ALRIGHT, now we're getting somewhere!



The sound clip once again, for reference!

Right now, every beat is the same size, as in there's no distinction between sixteenth notes, eighth notes and quarter note. In the future, I'll have programmed in the actual 'strength' of each beat and the rhythm bar will generate different sized bars depending on how long the beat is.

Another thing that's missing right now is the rhythm highlighting which will be the system which, when the game figures out what rhythm you're following, darkens the other ones so that the rhythm you're playing to stands out!

Also, those of who are familiar with Guitar Hero and DDR may be a little intimidated by the fact that everything is so squished together. Fortunately, the speed is very much adjustable, as shown with the faster speed below:



Also, something else that's been implemented into the bar is the 'consumption' (as I've been calling it) of beats which basically shows which beats you've hit when you hit them. Here's yet another gif in action of me alternating back and forth between the two rhythms (at a lower FPS because at recording at max fps with gifcam caused the game to lag a bit and eat inputs (which might need looking into)):



It's not a perfect science yet because as you can see, sometimes it will randomly grab notes from both bars instead of the same one over and over. The system I have for figuring out which rhythm the player is following is pretty loosey goosey at the moment so I might need to tighten it up a little bit. Once I get the highlighting implemented, it should be much easier to test which rhythm selection style is ideal!

Also, on a slightly different note, I did some very lazy, quick doodles of Avadra!



She's literally so magical that she looks slightly different ever time I draw her!

:C

No but really, it's good to get some quick practice with her! I really do need to sit down and draw Avadra and Riff more often otherwise when it comes time to do the actual game art for them, they'll be nothing more than stick figures. With Avadra, I have some issues figuring out the shape of her maw and I also feel like her eyes move around just a bit every time I draw her.

With Riff, I have a ton more drawing to do because I basically never draw humans 8S

Also, this was my first time giving the Binary Pen a spin in SAI. I learned that downscaling the binary pen pretty much removes the entire effect so after I scaled it down, I redrew over it all over again. Feels weird to have the pixely effect actually, I've never gone for it before!

[20 minutes]

I can't say I'm the target audience for this game as I'm fairly new to the android gaming market and I'm not particularly good at these skill based puzzlers, but I've always had an interest in these gravity style games so I thought that I would give this one a go! I was only able to play through a few of the early levels (I'll explain why later) but here's what I thought:

• I find it humorous that the first level requires absolutely no action whatsoever. I can't deny that it gives the player a good introduction to how the game is going to work!
• I like the fact that (in the levels I played at least) there are buttons along the bottom for the planets in addition to being able to press the planets themselves to increase their gravity. I say this because actually pressing the planets themselves proved to be rather difficult! In the earlier levels, the planets are so small enough that I couldn't see them under my finger, therefore I was never able to tell if I was actually pressing them or not.
• On that note, actually pressing the planets seemed pretty difficult to do because A) Their 'clickbox' was so small that I'd find that I had actually missed clicking on them and B) They need to be pressed and not held, as in, if I did actually miss them when I initially pressed, I couldn't just slide my finger over them to compensate. I was thinking it would be good if you could increase the gravity on planets merely by having your finger on them instead of having to explicitly press them. In that sense, I could basically play the game without ever having to take my finger off the screen (sort of a weird example but it's the best way I could explain it haha)
• Once I had gotten to 1-3, I had come to notice that the game moves very very slowly. I think the time I beat the level with was something upwards of 20-25 seconds or something, and that was just one planet and one star. Initially, I thought an easy solution to this would be to speed the game up by quite a bit but as I learned in my next point, that isn't really viable.
• One thing I will say, I can't remember if it was 1-4 or 1-5, but the level that first introduced the ability to control two planets felt pretty cool actually. I liked the feeling of being able to fine tune the ship's trajectory!
• Now, I said I was only able to play the earlier levels for the game and here's the reason; this game is hard, holy moly. I had reached level 2-1 and it took me upwards of 20 minutes just to beat it. I'm going to say this right now, the next few notes are extremely 2-1 centric and I don't know if there are many other levels like this in the game but good lord.
• Once I had actually beat it, I'm pretty sure my time came in at almost 3 minutes. It wasn't 3 minutes of elaborate alley-ooping my way around planets. It was basically 10 seconds of getting the star and then another 150 seconds of me doing laps around all three planets just trying to reach the portal but juuuuust missing it.
• One of my issues came from the fact that I was kind of expecting some sort of propulsion mechanic. I think back to the NASA missions in which they apparently used the gravity of other planets to 'slingshot' their satellites by building up as much speed as they could by swinging just within a planet's gravitational pull before activating thrusters and boosting out with all of the speed they built up. That's the thing though, as far as I can tell, there is no propulsion mechanic in this game, you're basically at the whim of the planets' mercy.
• And on that note, those planets are merciless. Part of the reason I had so much trouble on those levels was because either I couldn't increase the gravity on a planet fast enough which would cause the avatar to go completely off course or I had held the gravity on for just a half second too long which would either result in again, going way off course, or just straight up dying. This goes hand in hand with the point I made earlier about why speeding up the game wouldn't be good and why the planet gravity needs to be so slow is because even an inaccuracy of a quarter of a second would mean another either another 30-40 seconds invested in lining yourself up again, or it would just result in certain death. The worst is when you get a combination of both where you can see that you're going to die after about 20 seconds and no matter what you do, there's nothing you can do to change it because of how slow your impact is on increasing gravity (and letting it decrease as well).
• Of course, if I knew I was going to die in 20 seconds, I realize I could have very well just restart the level. Unfortunately, as I said earlier, I'm pretty new to Android gaming so it took me quite a while to figure out how to actually pause the game. Maybe I'm just spoiled by games with in-game pause buttons but I think it would be nice to have one here just to make easier to pause->restart whenever I need to.
• Lining things up proved extremely difficult too because as I mentioned earlier, the stars and portal are so tiny! I had great many instances of just missing a star or portal resulting in a lot of "OH COME ON" moments. It might not hurt to make them just a little bit bigger. You could possibly even introduce their current size as a hard mode or something!
• Last note about 2-1, my final solution, as I stated earlier, was doing huge range revolutions around the entire trio of planets which often had my ship going way offscreen. At one point, the ship was completely gone for 10 seconds. I had literally no idea where it went! Maybe for those cases, it might be nice to have a little arrow that points to where your ship is offscreen.
• Humorously enough, 2-2 took me only two attempts to beat and I beat it with a much more reasonable time, but after a few attempts at 2-3, I felt like I was just going to be stuck all over again, so unfortunately that's where I stopped playing.
• I hope you guys don't mind suggestions, but I feel like the gravity changing aspect would be much more intuitive if you could explicitly control how much gravity the planets had instead of just being able to very slowly increase it. As an example, you could press the outer edge of a gravity circle around a planet and drag it around to increase and decrease the gravity. For the bars you could press on the bottom, they could be similar to progress bars that you can fill or empty by moving your finger left or right. How full the bar is corresponds with how strong the planet's gravity is. I have no idea if this would break any puzzles in your game, but I feel like having more control would be a good thing as the current system feels unfortunately frustrating in some aspects.

While the game struck me as quite frustrating in some aspects, I can't deny that this game does have the potential for some neat puzzles. I did actually quite enjoy puzzles like in 2-2 that require navigating an obstacle course of sorts. It's just that the puzzles centered around building up speed to reach the portal came off as super difficult for me :C

I wish you guys the best on the Google Play!

Awesome, I will keep this advice in mind for my language speaking endeavors


I got the first half of the rhythm bar done!



A quick explanation, the red line is the current time the music is at, and thus, is the point where you would make your inputs. The line dividing the center is the division between the two rhythms (the cymbals and the melody), and the line that's moving is the point where the music loops. Once I implement the ability to transition from one music clip to another into the BeatMaster (lame name I know but I couldn't resist calling it that when I thought of it), the Rhythm Bar is already outfitted to handle that too!

It doesn't look like much right now because it's sort of missing the most important half; the actual beats that you're supposed to be trying to follow. I already have it half coded at this point so I should have a basic but functional rhythm bar up and running either tomorrow or tonight if I feel like it.

I'm happy this just popped up now as I meant to reply on this the last time I saw it because I gotta say, so many of these designs are so absolutely up my alley. As some have said before, it's almost a shame that the behemoths need to be killed because they look so absolutely divine. From their (mostly) benevolent appearance and the halo like apparel, I sort of get the sense that the behemoths are like wise, old guardians. Call me odd, but I feel like it would be fun to strike up a conversation with these behemoths if they could talk, they look like they'd have some neat stories to tell :D

Also want to say that I really dig your dragon designs too, although, I have to admit, I'm not exactly sure which ones are your dragon companion and which ones are actual behemoths! Either way, I do quite like them, especially the draconic fellow in the sketch you just posted!

I also really like your chimera-esque tree archer and your owl behemoth and your wolf behemoth. I like A LOT of your behemoths it what I'm getting at haha.

One big question that I find myself wondering as I was reading this, it may be a somewhat odd question but if I may ask, what inspired a game like this? I realize there's quite a bit of discussion about SotC, but I can't help but feel like there's something else behind this game too. Just a random feeling, I guess, haha.

Lastly, I'll close out with some quick notes. First of all, great find with the fur rendering, hopefully the tool for sculpting it improves over time! Secondly, I saw your note from a few posts prior about making the character not human, I am very very okay with this and I'm curious to see what you come up with. Lastly...

Do you have a gallery somewhere I can watch? I'm curious to see what else you have!

In case you're still looking, an alternative to LICEcap that I actually saw mentioned here when I first joined would be GifCam! It lets you edit your gif after you record it,  save it in a variety of color formats and even add text!

Above all, it lets you specify the FPS all the way up to 33 fps!

It's worked wonders for me so far. The only issue that I've ran into with it so far is, very rarely (only once for me so far but I've seen it with other people too), gifs will come out kind of corrupted at the end and you'll need to re-record them. Also, recording at 33 fps can be pretty cpu heavy if your game is cpu heavy as well. Apart from that, I highly recommend it!

[Bugs:]

So, I gave this game a quick whirl! I got stuck on one of the later levels so I ate supper and came back to it later. Was able to beat the demo afterwards! The mechanic was pretty cute and I like how pretty much all of the game's menus were world elements rather then screen elements! Anyway, here's what I've got for your two categories:

This is on the Windows build! I, unfortunately, do not own a oculus rift, so I played with the keyboard and mouse.

Bugs:

• Any sort of fast mouse movement causes the camera to lock up and freeze. Basically the whole time I was playing, I had to turn around slowly otherwise the camera would stutter heavily. I recorded a gif of this:
  
  
  
  Here I'm making really big sweeping movements with the camera. The game isn't freezing, it's actually running at a full 60 fps.
• This isn't really a bad bug since you can still interact with the menu, but I think instances like in the following situation might be confusing for players who aren't really familiar with the menu.
  
  
  This bug wouldn't be as bad if you could just reopen the menu somewhere else, but it seems like the only way to close the menu is to hit the resume button. I thought that just hitting escape would close the pause menu, but instead, it quits the level which feels odd to me. Edit: I just figured out that you can just click away from it. Still, some of your user base is probably going to try escape before they try clicking.
• Last bug, I think you guys might have some issues with draw order:
  
  
  
  Above is an example I found on the maze level in the medium difficulty pack. The maze was pretty hard to navigate actually since a lot of the walls behind other walls were disappearing and appearing somewhat randomly.

Not-sure-if-bugs:

• Mashing the shoot button causes no balls to come out because the character just interrupts the animation.
• Shooting a ball does reset the score multiplier but it seems like every ball that is going fast enough still generates multiplier, thus, a viable strategy is to just shoot balls in every odd direction as fast as you can. Since so many balls are moving all over the place, you instantly build a x9 multiplier and one of the balls is probably going to hit the boxes. I can understand if this isn't a bug, it just seems rather void of strategy.
• Another strategy I found, easily doable in levels with two walls facing each other and boxes nearby on the ground: Throw the ball so that it bounces back and forth between the two walls and then just nudge the ball with your body so that it rolls into the boxes. Much harder then the last bug to do but it felt very... "unintended" if that's a proper way to put it?

Features:

• In levels that do actually require a skillful ricochet, I found it really really hard to line up the proper shot. I also found it really hard to read my previous attempts to see how things went wrong. For this, I really wished I could see the trajectory  of the balls I shot as well as the ones I'm about to shoot. In other words, it would be cool if your shots left a longer trail that didn't fade away so that you could examine where your shot went and how close it missed your target. For balls you're about to shoot, it would be cool to see a guide that basically draws a line which shows where the ball will go. I realize this feature might get super flashy and hard to see if your throwing balls everywhere, so one idea might be to make it something you activate, similar to the half speed feature that you can turn on and off.
• Speaking of the half speed feature, I did indeed find it somewhat useful on one occasion. Once I had beaten the level, I was wondering why I was moving so incredibly slow. It was because I had left the slow-mo on and I had completely forgot. It might be nice if there was some visual indication other then the slow-mo itself to show that your in slow-mo!
• Sometimes when I messed up a level and needed to start over, I found myself pressing R to reset the level only to find out that R just toggles rift vision. I have no idea if I missed it on the tutorial level (which, by the way, that picture had a LOT of stuff on it. I dig the simplistic aesthetic but it might be nice to just have a written list of the controls somewhere) but it would be cool if there was some sort of keybind that just resets the level for you instead of needing to navigate to the menu!
• I was hoping that this game would have some sort of windowed mode available in the options, but alas, it does not. Some resolution options might be ideal for those who wish to change it.

All in all, the game is a pretty cute concept, and I feel with a little more time invested into level design, the game could have some very interesting, thought provoking puzzles! I also like the main character and the actual platforming feels oddly soothing with the character being able to just gently float down onto platforms!

I wish you guys good luck with Desura :D

To be honest, I never actually played it. I remember it popping up when I was searching up this name though and I thought it would be obscure enough that not many people would make an association. Guess I know why it's obscure now, haha

Only reason I have this name is because I was looking for a name for a character of mine so I was just punching words into google translate and Gekido came up for "rage" in Japanese.

P.s. thanks!