New episode up!



This shorter episode is a quick overview of the implementation of the BPM synchronization system, which syncs character's animations up with the beat of the song allowing me to port over the same character to different songs and still have all of their animations line up! Unfortunately, I run into a few optimization problems along the way so that kind of throws a wrench into progression. Near the end, there's also a quick time lapse of the concept art I drew in the last post for the Ways. I also spend an inordinate amount of time this episode talking about how I'm spending too much time drawing!

Next up, I'll be working on the rhythm bar! Here it is again from a link a few posts ago:



Similar to what you would find in DDR or Guitar Hero, I plan to implement a rhythm bar which basically provides a visual guide to players in case they don't know the song! The rhythm the player is currently following (based on their button presses) is highlighted so that the player can more easily see. As there is no system which FORCES the player to perform attacks to the beat, this feature is more of a visual aide then it is a written-in-stone set of button inputs and thus, it can be turned off if you know the song that's playing!

[(Click for dA)]

Hey, thanks Chris! On the note of varying song genres, I think it would be cool if the soundtrack explored various styles as well, but at this moment in time, I can't really say I have a soundtrack plan set in stone! How I'm going to acquire the music assets is actually something I've been meaning to discuss in this log, but I think I might just wait until a later post when I have things a little more figured out!


I've been progressing with the rhythm mechanic at an okay pace, I've got a mechanic implemented that syncs all character's animations with the bpm of the song so that all movements (idle bopping up and down, footsteps) take place to the beat! Here's a somewhat slapped together GIF of it:



I would have recorded it so you can see them moving to the music but unfortunately, the system is not perfect yet. One weakness of my engine at the moment is that it is completely frame dependent and as soon as the game stops running at 60fps, the animations desync which may cause problems down the road because attacks currently use the same bpm length adjustment system. I may just have to switch over to a frame independent setup in the future which may have a few oddities of its own but I'm sure it would be safer then my current system.

Despite that, I have somewhat had a dip lately in my programming productivity in favor of having a huge boost in drawing productivity. Unfortunately, I have a very bad habit of using my drawing time to draw basically whatever I feel like, regardless of its relevance to the game. I always told me self that even if I wasn't directly contributing to the game though, no matter what I'm drawing, it will always be good practice in the end!

And surprisingly enough, it actually was good practice! Recently, I decided that I had done enough leisure drawing as I call it, and that it was time to actually do some concept art! So, I decided that after having drawn Riff and Avadra, it was time to move onto the next most prominently featured characters, The Wills!


(Click for dA)

All in all, these five doodles came out much quicker then Avadra and Riff's references! You could argue that their design is also much simpler, I suppose, but even then, I had enough time to do soft shading on two of the Ways and still be quicker!

The moral of the story I'm getting at here is if there's anyone reading this who feels that drawing irrelevant fun stuff isn't productive, I'm here to say that it most certainly is!

ANYWAY, The Wills and Ways! To copy paste from dA:

The Ways are the most basic form of Wills, which are a large variety of beings that can be summoned by Avadra! Simply put, Wills are short term summons created for the sole purpose of fulfilling a duty specified by the summoner. While they can be created as deep, complex creatures, Ways are much simpler then that. Often summoned for either simple tasks or purposes that require numbers, Ways are not very intelligent or sophisticated wills...

but they get the job done!

p.s. I didn't originally mean for the Ways to be adorable but they turned out adorable and I like them that way and I want one :C

New GODHOOD development episode is up!



In this episode, we go over several excerpts of the development of the rhythm mechanic including the development of The Beat Master, the creation of the beat file as well as basic prototype of how rhythm mechanics work with characters.

I know it may seem extremely dorky how excited I am by the end, but it genuinely feels so good to finally be able to play my game in a small sense! Again, I'm aware that I probably should have had a prototype for this a long time ago, but hey, what can you do?

Also, I've decided that I indeed still want to do these videos as, even for myself, it's fun to just look back and see the bugs I encountered and stuff, BUT I'm still definitely looking into doing recap/highlight videos! I'm not sure if the quick videos I've posted so far are sufficient or if I should be doing quick post commentary videos akin to the Wolfire Overgrowth updates, or perhaps I could do live commentary demonstrations. Either way, I'll figure out something eventually. Perhaps switching it up every so often might work too!

Anyway, I digress. Next up on the menu is (probably) implementing the rest of the rhythm character into the mechanic, plus doing a little bit of concept art in the way since I'm in a huge drawing mood right now too!

It's not something I had considered that a game with a low poly aesthetic might feel at odds with a smooth experience. You've given me something to think about for sure! The camera lock and camera location transitions are very smooth/linear at the moment once I have all the functionality I want from the camera I'm going to look at making the transitions feel snappier which might improve this disconnect somewhat.

Oh no, I don't mean to say that the a game being low poly and a smooth experience were two factors that conflicted with each other! I just thought it was a humorous comparison from the fact that low polygon models are typically less smooth and more blocky (though my expertise in 3D modeling is literally nothing so what do I know haha). I don't mean to say that it subtracted from the experience. Quite the contrary, the two aspects blend together nicely. I very much enjoy the smooth nature of the game, it looks rather satisfying to drive over the rolling hills :D

Also, I found that gorillaz game I was talking about earlier. In retrospect, this is also a pretty silly comparison to make. Looks like they removed the music from it too for copyright reasons. Also, hope your computer has shockwave on it lol

I gotta say, from the gameplay video you provided, I'm really digging the aesthetic of what you've got so far! The desert ambiance, the visuals and the gameplay itself really have a very smooth feel to them, which, if you think about it, is kind of ironic considering the low poly style you're using, but I'm not complaining.

I hope you don't mind the comparisons, but in it's current state, this game actually very slightly brings me back to this old flash game I played a long time ago. This is sort of an obscure reference but it was this 3D driving game made for Gorillaz actually where you're basically just driving around a neat environment. I remember it because I remember it being fun to just drive around and explore the different parts, which is very much a vibe I'm getting from this! From your video, it looks kinda fun just driving around that environment. I can see myself making a little game for myself of trying to find the biggest dune jump on the map. I can kind of see other people having fun trying to draw stuff in the sand haha

Also, I like the sound of your gameplay description. Vehicular platforming sounds like it could be quite a bit of fun although I can't deny I can see it being slightly frustrating in particularly tight areas or in places that take a large amount of time to reach. Although, as far as I know, the point of Shadow of the Colossus was the fact that if you fall, you had to start from the bottom, so really, I suppose it's all a matter of how enjoyable it is to recover!

I can see the influence from Interstate 76 which, by the way, I had almost completely forgotten about until this point! It's funny, I DID actually remember the game once a few weeks ago and I was going to look up vids for it, but I completely forgot to! I'm going to do that right now, because I think I was actually a little too young for the game when my parents got it for me because I remember completely foregoing the main story and even the challenge missions (if I remember correctly) and just going into the sandbox mode and just messing around the random maps in there (much like how I talked about a few paragraphs up actually).

I DIGRESS! Overall, I look forward to seeing where this goes!

Well, I had an interesting morning! I got the rhythm mechanic implemented into the character so that their attacks are now bound to the beat! Here's a quick demonstration:



It was actually very interesting to finally have the rhythm mechanic in place as I came to some interesting realizations. The biggest finding I came across was the fact that this mechanic was NOT easy to play with at first. Right now I have it so that you can only attack if you're (kind of) close to the beat which is not the same as how it's going to work in the final product, but regardless, I had a lot of trouble getting out more then a few hits, let alone following a rhythm, but only at first! After I got some practice playing with the mechanic, plus after making a few adjustments to the volume of other sounds, I was able to get into a groove and I'm now able to reliably follow either of the rhythms!

It feels really cool that not only do I have something I can play, but I actually already managed to have something I can LEARN to play too! It is actually quite the cool feeling! :D

I also learned that using the space bar on a mechanical keyboard for attacking in a game where you need to be tight with the rhythm is a very noisy endeavor!

Anyway, I also finished off the next episode and all I need to do now is edit it and then post it to youtube! I think I might just do that later though, and instead, work on doing some drawing practice and concepts for now C:

The left square is indeed flashing with the cymbal beat! I'm not actually pushing any buttons in the video.

Earlier, I did have it with pushing buttons and just had it print "PERFECT" or "good" or whatever to the in game console, but I didn't think it would convey rhythm so well into gif form haha

So, after distracting myself with doing a bit of drawing, I managed to get a pretty basic implementation of the game's rhythm mechanic up and running. Here's a quick demonstration:



Now obviously, for a rhythm game, a gif doesn't really cut it so heres a Quick video with sound!

Also, here's the sound itself

Essentially, when the square turns green, a beat occurs. Each square is bound by a different rhythm. The first square is bound to the underlying beat which is just straight 8th notes, while the second square is bound to the melody which is the heavier drum beat. The third square is both of the first and second square combined and is basically representative of how often the player has an opportunity to perform an attack with perfect timing (although it is very unlikely that a player can simultaneously follow every single rhythm in the song at the same time)

Also, perfect isn't the only timing the player can get when they're trying to line up attacks with beats. Right now, I have it set up in a DDR style where you can get Perfect, Great, Good, Bad and just straight up MISS (not even gonna bother with MARVELOUS). I'm not entirely sure if I'm going to use all five of those, but I thought it would be nice to at least give myself a lot of options starting out. It's pretty cool though, originally, I had the squares light up a different color depending on how close its timing was to the beat and it came out like this:



The purpose of these squares was less to be a final feature in the game and more just a generic test to see if the rhythm worked at all. For the future, I have different, much more scribbly plans. For now though, I'm happy that everything lines up!

Next up on the menu is quickly prototyping the rhythm mechanic with Waki to see how it feels to actually attack an enemy to the rhythm! I'm really looking forward to finally testing it out!

I gave this game a try just a little bit ago! I've always had a good appreciation for Nonogram/Picross style games so I had to give it go! Here's what I thought:

• To put it in possibly the nerdiest way possible, I was somewhat caught off guard by the difficulty to board size ratio. I mean that in the sense that once I got to the 5x5 boards, I was already running into some trouble! I probably shouldn't be comparing this game so closely to picross seeing as there are two different rule sets at play here, but I think most of the game's difficulty come from A) the deeper logical inference required to solve puzzles(which I'll get to) and B) The fact the game doesn't tell you when you when you messed up (which I'll also get to)
• On the deeper logical inference thing, what I'm referring to is the fact that a lot of the puzzles, especially later on, require a lot of recursive guessing, which is to say, moments where you go, "Okay, I don't know if this is guaranteed the correct spot for this four block figure but I'm going to try it since there's no way I can prove otherwise. Okay, now let's make a guess based on that previous guess. Okay one more guess aaaaand it doesn't work, clear the board and start over." Subjectively, I find myself more partial to the style of game that lets you make small incremental proofs where you can say "I have proved that these two blocks are indeed filled, so let's progress through the puzzle based on that knowledge."
• It could very well be that I'm missing a piece of knowledge required to make super simple logical inferences with this game, but as far as I could tell, examining the puzzles by isolating individual rows and columns, there are so little ways to prove which blocks are filled or empty due to how varied the possible layouts are. Once you get to the 5x5 puzzles, the only row/column number you can confirm is 0 (all empty) because even with getting a 4, it still means that any of the blocks could still be filled or empty.
• With the two previous points though, don't get me wrong, I'm not saying that it's a negative aspect of the game. I'm sure there are lots of people who are not me who have a mind much more suited for solving those types of problems, I'm just not one of them haha
• On my second note up there regarding the game not telling you when you mess up, there's a good half to this and a not so good half. The half I like is that if you try and place a filled block where there isn't supposed to be one, the game doesn't YELL at you and play a BUZZER sound and give you a big STRIKE, the game lets you experiment with different layouts which absolutely goes hand in hand with what I was saying above. I quite liked that aspect!
• The part that I was not so fond of is if you place a filled block or an empty block in a place that the game can recognize as invalid from the user's input (5 filled blocks touching each other, 2x2 of the same block, ect), the game doesn't make it apparent why your solution is incorrect. I'm not saying the game should do the "BZZZT YOU'RE WRONG" kind of thing, but rather, it would be really nice if we just had some sort of indicator, like highlighting invalid blocks red, or drawing a red square around 2x2 figures. I say this because on level #2, I thought I had found a perfectly good solution that the game didn't recognize and I had actually taken screenshots of it so I could show up here all Zoolander like "WHAT IS THIS!?" but it turns out when I later double checked the rules to see if diagonals were valid, it turns out I had actually completely missed the 2x2 rule and had no idea it existed until I rechecked the rules!
• To quickly elaborate on several other aspects, I have to say, I reeaally quite liked how the game controlled actually. It because apparent to me very quickly how the fill or empty specific blocks, and soon after, that I could convert whole sections to a single color by dragging. Really intuitive and nice, so I dig that!
• The layout of the undo, clear and level select buttons took a little getting used to. I'm pretty new to the Android scene so I have no idea if these buttons are laid out differently on other phones, but in reference to the back, home and process(running apps? I have no idea what it's called) list, I thought it would make more sense for the in game buttons to line up with the android buttons they're most similar to, ie, Undo button with the Back button, Clear button with the Home button and the Level Select button with the Process list button! Right now, the layout is Level Select over Back, Undo over Home and Clear over Process list.
• Speaking of the android back button, I found myself repeatedly pressing it to try and go back to the level select screen, but to no avail. Same goes for the rules screen.
• Last note, might be nice to put the rules button somewhere other then the top of the level select screen as in, maybe have it scroll with the list or something so I don't need to lose my spot and then find what level I was on again (which really isn't THAT big a deal since it's so easy to find what level you were on haha)

Overall, the game was fun. The game has a surprising amount of draw, I find myself compelled to open it back up again and give a few more goes at the level I was on since I sort of got lazy and gave up on it before I gave it a valid try, plus I wanted to get this review written anyway.

Oh yeah, I should probably specify that a minimum of OpenGL 3.2 is required. Sorry, my mistake!

It would be cool to go back and see what happens but I'm actually making use of the OpenGL contexts and GLFW 3 can't go below OpenGL 3.2 anyway.

[Edit:]

That's actually also a good question, considering the fact that I don't really have anything present on my first post at the moment that describes the actual engine itself apart from my videos. With that in mind, I've gone ahead and updated the OP with several gifs to show what I've recently added.

Seeing as I'm most likely going to be updating the OP with new gifs as I program the engine, I'll mirror what I've posted above right here for future reference!


Edit:
Hey, it's me from five months in the future. Since I've removed the message from the original post now that I'm phasing out all the placeholder art, I'll post it here instead. During the development of the game engine for this game, I wanted to focus on coding, so I decided to forego drawing the main characters and instead, opted to draw extremely simple placeholder characters instead.

Their names are Waki and Smunch.



Hit detection:


Pretty much one of the very first things I implemented into the engine once I got started on it apart from the characters themselves. A staple of any hack'n'slash!


Collision:


With hit detection down, I felt it was time to move onto collision. I had a simple rule set for it:

A)I should be able to specify which characters collide with which based on team (Player, Enemy, Neutral, etc).
B)Characters should collide at the sides and push each other based on their weight
C)Characters cannot stand on other characters and are shifted to the side, akin to how most fighting games handle it.

To get the system where I have it now took a loooooot of work. I knew collision was going to be bad going in but damn, there were some absolute monster bugs making this work. Even when I thought I had it finished, I had cases where characters would intersect with each other or the level and explode out of each other, sending the whole environment into chaos as characters bounce off each other and push each other around.

After about a month of work, I finally got it to where it is now where the only bugs are characters bouncing off each other a bit (or occasionally phasing through each other if you turn the physics accuracy down) if you smoosh them into a multi layered sandwich against a wall which is a small price to pay if you ask me! Overall, I'm proud of where I've gotten it and I fear the day that I have to change it because I know it's coming.


Asynchrounous Loading (loading 100 Wakis and 100 Smunches):


This is what I spent the past few weeks working and is the most recently completed feature! I'm pretty sure I talked about this only a few posts ago, but in short, I'm using threading in combination with multiple shared OpenGL contexts in order to load all of my assets on a separate thread. This way, I get to have a loading bar which I've always wanted!

My roommate's occasionally pointed out to me that loading bars seem to have gone out of style and I find this prospect rather strange but still true. Even then, I still wanted one for my game, because I'm always fascinated to see where the load times choke at!


If anyone is curious to try out these changes(except for the loading bar) then I'd like to direct you to The FIRE2D Tech Demo which also features a quick demo of the engine itself!

FIRE2D itself is pretty standard seeing as I was the sole developer of it. I'd say my proudest features of it would have to be the recursive particle effects, the data driven post processing and my personal favorite:

The Alpha Based Particle Emission:

Oooooooh, okay, I know what you mean now. Yes, the two effects are indeed two different effects and holy moly, they are indeed very different speeds as well as very different emission rates (the post processing effect fire is 5x faster and emits twice as many particles). On top of that, it seems I set the flame size to min="6" max="2"

I just spent a little while toiling with it and it looks a little bit calmer now. I'll have it in next time I update tech demo since it isn't really engine critical!



As for the error log, it should be in the same folder as the exe. If there's nothing there then cool!

Oh wonderful! What a relief haha! That's somewhat puzzling though as I didn't actually change any OpenGL stuff, I only changed the order they were loaded in. Chances are you might still have an errorLog.txt generated with the game, but if not, then that is very weird but hey, I'll take it!

As for the post processing, if you're referring to the bloom, I'm pretty sure my bloom calculation is just straight up wrong. It doesn't look nearly the same as it does in that one tutorial I followed so in the future, I'm gonna have to put some research in a proper bloom effect. For now though, I'll just refer to it as my weird glowy effect, haha.

Happy that you're getting 60fps on all accounts! As for the walk speed thing, I agree, lol. I probably should beef them up a bit so I could at least speed up testing!

All in all, thanks for your patience with this, the help is really appreciated!

Just a heads up, thank you so much for doing the research on this because it being a stack overflow error actually really narrows it down! Fortunate for me, 95% of all of the stack overflow errors come from the same method in my engine, so it was super easy to track down the issue!

The bad news is, the method that's causing these stack overflows is ironically the error reporter I made for my engine, haha. What's happening is something engine critical breaks, so it reports an error but in attempting to create a textbox, an error occurs so it tries to report that error, create a text box, breaks, reports error, breaks, reports error, breaks, ect ect ect until the engine dies.

Seems like it was high time to change that so I changed my error reporting system to not just infinitely report errors that IT generated. Unfortunately, this doesn't mean the issue is fixed as, it being the error reporter, it means it died trying to report an error in OpenGL instead. So for that, I implemented error logging so that it just outputs errors into a file instead of trying to convey them through the game which is dying before that ever gets to happen!

No obligations but if you're up for still helping out, I updated the link with my changes in the OP and added some instructions for the error logging. Either way, thanks a lot for your patience and help with this, Quicksand :D

That's cool! As I was writing out that post, I was considering whether or not I should be doing a highlight reel sort of thing on the side. This is a good confirmation of that lol

Seeing as time is short at the moment, it would be a little tough to retroactively create an abridged version of everything I've done so far, but it does indeed seem silly that I'm completely relying on my Lets Program to convey all of the updates I've done. During it's production, I was also wondering if I should just be posting frequent but very quick posts about what I've changed as I'm changing them so now is as good a time as ever to start I suppose!

In other words, thanks Marc, I needed that, haha.

[New video!]

New video!


This episode came out a little longer then I was expecting, but today, we do some ultra meta discussion about announcing the game which has become even more meta now that I'm mentioning this video which mentions this thread which mentions other videos. We also discuss some unposted concept art and small changes that were made to the engine in the mean time.

After that, we get started on a feature that I've always wanted to try and implement; a loading bar(and the associated asynchronous loading)!


Man, I gotta say, OpenGL contexts are probably one of the biggest carrots-on-a-stick that I've ever seen in the sense that you're always one bug away from having a good implementation and fixing that bug requires you to completely change that implementation. I got it working in the end though and I almost feel the need to make a tutorial on it seeing as all the solutions I found for each of the bugs I had were pretty much completely separate from each other.

That said, I'm happy that I have my cute little loading bar now and I can't help but feel that it'll come in handy at some point in the future, but what I'm really looking forward to is the next mechanic I add to the game.

Up until this point, I have been working on pretty general things that are mostly in common in all 2D games, but now that I have my game announced and out there, it's finally time to get started on the core mechanic of the game!

It is finally time to get our rhythm on!

Next episode will document the implementation of what I'm referring to as The Beat Master (somewhat humorously) which will accept the player's input and return a value based on how close they were to a beat and what kind of beat they pressed their input on (quarter note, half note, eighth note, etc). Before we get knee deep in it though, I have to sort out some music to actually code the beat master too. To keep things neutral, I may just grab some drum sound effects and arrange something super quick in audacity as I am, unfortunately, no musician. If I can find something completely royalty free online though, I might use that.

While I'm looking for/creating music, I'll probably dabble a little bit more into concept art which could be another thing I feature in the next episode as well!

Hmm, good to know. Anyway, thanks for the effort! I'll probably just be reusing this thread in the future any time I update the demo, so hopefully I can either find a system that has the same issue as yours or the issue will get resolved over time as I learn more about C++!

Thanks for the help!

Hmm, the ms-something dll might have to do with the msvcp110.dll which I mentioned in the known issues, but if that's the case, it would have said that the DLL is missing and not that it's a fault module (unless it being a fault module actually means that the dll was missing).

As for ntdll.dll being the fault module instead, after doing a bit of research, this looks a lot more terrifying to figure out what could be causing this error as it seems like it could be caused by a whole host of things. There is a small chance though that this error is popping up BECAUSE the ms-something dll error popped up before. I'm not entirely sure.

Thanks for the reply though! It's awesome to get this caught now and not a few months down the line when I'm already in too deep.

[Short version:]

Short version:

I made a 2D graphics engine and I have barely any idea how well it runs on other computers. It would be super awesome if you could download it (link below), run it, then tell me if it launched or died.

Description:

Hi there! I've been working on a custom graphics engine for my game for about 8 months called FIRE2D. It is programmed in C++ using GLFW 3, GLM, tinyxml2, dirent, stbimage and FMOD. I've gotten it to a state where it's pretty much as complete as it's going to get seeing as I've shifted all of my focus towards the game engine itself. That isn't to say that I've completely dropped FIRE2D though, but rather, I'll only be making additions to it based on what the game requires instead of just going willy nilly over features.

Seeing as I'm still relatively new to this with only 4 years C++ experience and next to no experience in the industry itself, I'm really just curious if the program launches at all. That said, I've tested this on a few of my friend's computers with varying results. Recently, they have been more promising seeing as before, the engine almost never launched on other computers, but that was because of some bad shader variable names which for some reason, worked perfectly fine on only this computer, and I'm pretty sure I've fixed those by now.

So, if you could download the demo, run it and then tell me what happened, I would be perfectly fine with just that. I also included a few demonstrations of the more advanced features of the engine as well as a quick demo of how the game engine looks so far so if you want, you can take a look at those too, but mostly, I'm just curious whether the engine runs at all!

Changes:

v1.00:
-Initial release

v1.01:
-Added error logging for crashes on startup
-Fixed stack overflow crashes (which are, unfortunately, indicative of other crashes)
-Increased the likelihood of the game launching

Known issues:

msvcp110.dll is missing!
Your need the C++ 2012 VS redistributable to run the engine. You can download it here.

Particle effects don't render
I'm the one who caught this error when someone at an indie get together I went to let me run the demo on their computer. I have to admit, I'm not sure what's up with this one but I didn't get the chance to ask him what specs he was running on his laptop. If anything, this is probably indicative of the fact that I should really implement some glGetError logging.

Just give me the demo:

Requirements:

• The Visual Studio 2012 C++ Redistributable Update 4 (download here).
• An OpenGL 3.2 compatible graphics card

Download here: https://dl.dropboxusercontent.com/u/21521620/FIRE2D%20Demo%20v1.01.zip

Instructions:

1)Extract folder anywhere
2)Go into Release folder
3)Run Epicenter.exe

3a) It crashed!
4)Darn! Oh well, part of the fun I guess! In the same folder as the exe, there should be a errorLog.txt. Send me the contents either here or in a PM if you don't mind.

3b) It launched!
4)Cool! :D

Stats:

Number of computers:
Successfully launched on: 4
Launched with bugs: 1
Instant crash: 1

Screenshots:





Thanks:

While I technically have been a member for a few months now, I am still a relatively new poster. I've been a bit shy for posting lately as I've been trying a little too hard to think of ultra meaningful posts, but I really do have the intention to be more active in conversations around here. What I'm getting at is, I really do appreciate your time quite a lot especially because I have not much contributed much in return!

Ah well, perhaps now is a good opportunity to change that!

Again, thank you very much!

[EDIT:]

Thanks, Plaguebringer! It certainly does feel a lot more stylish being able to time your actions in accordance to a fun beat instead of just desperately mashing attacks. This sort of stylishness is exactly the essence I'm trying to go for!


EDIT:
Hey, it's Nick from the future! It's been one year since I've drawn the references below, and since I only have four years of drawing experience(at the time of writing), it makes a pretty significant difference! I'm writing this edit to say that exactly one year later, I've done brand new references and the following two are now outdated.

You can view the brand new references right here!

Continue on to the old ones if you dare!

Character Refs

Riff

• 22 years old
• Inexperienced writer/cosplayer
• Mostly keeps to himself
• Lives in a single bedroom apartment by himself
• Works in a fabric store, from which he gets his supplies to support his cosplaying hobby
• Is writing a book about a realm of gods, starring Avadra, a rebellious deity
• Doesn't really think things all the way through
• Can't really lie very well

Avadra

• Explosive both behaviorally and physically
• Can summon shadowy monsters called Wills
• Has a great dislike for anyone more powerful then her
• Believes that a proper god show live among their people instead of staying hidden
• Reciprocates the behavior of those less powerful then her (Hates those who hate her, loves those who love her)

It's worth noting that while most aspects of the characters are pretty set, pretty much everything here is subject to change, be it description, design and (hopefully) quality of art!

On a quick note about that, while I have been drawing for about three years, Riff is the first human I've ever tried to draw properly (as, up until this point, I've pretty much only drawn monsters) so I really only have two weeks experience with drawing humans which is why he may come off as a little wonky. Even then, Avadra may look a little off in spots too, but now that I have visual refs for both characters, I should be much more able to draw them consistently in the coming months as I work on the game!

Speaking of which, now that I have finally done up full references for both of these characters, it means that I can finally return to the game engine! Despite the fact that I said that I can get started on game specific mechanics now, I decided that, due to the recent implementation of being able to load large amounts of characters, it's time that I implement:

Levels and Level Loading!
Simply put, levels would encapsulate everything that you would want to load for a given level, be it characters, stages, cutscenes as well as rules for each level. It's immediate implementation (for next episode) will feature converting the initialization of the game from hard code to a file that's loaded on a thread, allowing for a loading bar(with debug information too)!

It being Friday, and being rather burnt out from the 13 hour day I put in yesterday, I'm ready to kick back a bit for the weekend, but I look forward to getting started on the engine again this Monday! C: