2018/06/28

Beatmap editor in Unreal 4!

Hey there! This is Lussy.

We've been hard at work on our rhythm game projects, and we've managed to create a feature we've never thought we could do with Blueprints only, coupled with our current experience. But alas, it has happened.

We've created a beatmap editor inside Unreal 4 using only Blueprints and Rama's Victory Blueprint plugin (it's a godsend, check it out if you're using UE4!).

For the editor, we used osu!'s editor as a reference, and for now it can only create and edit Taiko type beatmaps. We plan to overhaul it almost completely for our own game, but first we had to try if it was even possible to create.

The editor uses .ogg files as music, and creates a text file with a matching name for each new .ogg file. The file contains BPM and title information, as well as all the beat objects or notes in the song - similar to how osu!'s .osz files work. We dubbed ours as .beatmap files though.


Once the file is created, the user can enter a BPM calibrator that lets them tap a button in time with the music. The editor then calculates based on those clicks the BPM of the song, or alternatively, the BPM can be input manually.


After this is done, the actual editor lets users put notes down on each beat of the song, change their colors around and then save the beatmap. The beatmap can then be played in play mode.

The whole thing is very raw right now, because we haven't had as much time to work on it as we wanted to, but it's getting there. This tool will be very useful for developing our rhythm games, and we plan to include it in the game too, so users can create custom content with songs they like.

At this point we're starting to feel like anything is possible in Blueprints with the right nodes and tools. Of course knowing C++ would help greatly, so we're going to get on that, too, but there's no rush.

2018/05/26

Unreal Game Jam!

Hi! It's Lussy.

This month was... hectic, to say the least.

We're still getting settled into our new home, but we did have some time for our personal projects. So we decided to enter the Unreal spring game jam.

At first, we started making a turn-based RPG for the theme 'Transformation'. It featured a bug of some sort that could take the defeated bugs' and insects' limbs and use them as its own. We got quite far with the development, the combat system was mostly finished, it had a basic interface, experience points, 15 levels with new abilities unlocked at various levels. The whole thing was inspired by observing a dead mosquito in our bathtub that fell apart with all of its legs detached. (Why does that happen, by the way?)

...Aaand then we realized that we couldn't finish it in time, so we abandoned it and started developing a much simpler game. We managed to make it in just about one day. It featured a sphere shape that could transform into a variety of other shapes at the press of a button, and the player had to control this shape and guide it through a series of holes in walls that were coming towards it.
We called it 'Andy and the Wallhole'.


Just as we were about to upload the finished project (which was very much not finished, we wanted to include a lot more features and even a soundtrack, but oh well, game jams), we noticed that it was half hour past the deadline. I made a mistake in converting the deadline from New York's time zone to our own. Sooooo... that was that. We uploaded the project to itch.io nonetheless, but it was not accepted. I'm including the link, so if you want to try out this earsore of a project, go ahead.

The whole thing left a very bitter taste, but we do plan on going ahead with the shapes project and making it our own rhythm game. We've been trying to come up with some gameplay mechanic to put into our rhythm game framework ever since we recreated Taiko. So at least this is a plus! I also feel like I gained some experience in working really fast with blueprints. So it wasn't all in vain. That's what we keep telling ourselves, anyways.

So, until next month!

2018/04/30

Rendering huge crowds in Unreal 4! (Also, we moved!)

Hey, this is Lussy.

This month has been a particularly tiring one. We moved into our new apartment together, so we're still adjusting to all the changes, and we're still trying to find everything that we can't find since then. Like console memory cards.

With this move, however, we finally have a real home office! We both got new desks and lamps, so hopefully our persistent back pain and eye strain will go away. One day. One day soon. Please.
While Geril got himself a regular desk, I opted for an adjustable standing/sitting desk. So maybe the back pain will turn into leg muscles. Who knows. It's good to have the option of standing up while working, anyways.

In other news, we've been working on a massive background-crowd system. You know how in war scenes you have to show large crowds marching forward, or running into the enemy? That's what we're working on, but inside Unreal 4.

We already had a smart crowd system that could react to other crowds and even initiate combat with each other, but no computer could handle rendering 10 000 of those soldiers all at once in Unreal. So we made a simple crowd that can only march forward at various speeds and follow the terrain's slope. For this purpose, we decided on creating 3-frame 'animations' for characters: 3 static meshes that would alternate while marching, like a flipbook. These static meshes don't strain the engine so much, so we could easily show more than 10 000 of them, while also giving the crowd the illusion of being animated.

The static meshes had to be heavily simplified for LODs, and Geril did all of that by hand. This is what our simplified horsemen's LODs look like:



Pretty... artsy.

So, that was our approach for creating a very light crowd in Unreal 4. Would you do this differently?

Until next time!

2018/03/31

Project BPM Demo!

Hi there!

No, it's not an April Fools joke. The time has come for us to post our very first demo on this blog. So here it is!


We already introduced Project BPM in an earlier post. The game itself stayed the same, but the shell of it changed a lot! Actually, it's a design disaster. Neon colors... Sega Genesis aesthetics.... Neon Genesis Evangelion.... Get it?


It's a very rough build, but it appeared stable to us. We packaged it for Windows 64 bit. Since this is our first time packaging for Windows and actually releasing it, without a test team, please tell us if something is wrong or weird!

The controls are simple - the gameplay controls are detailed on the gameplay screen, and as for the menus, they work with WASD and the arrow keys for navigation (so, the difficulty setting), Esc for skipping and Enter for accepting/starting the song. There aren't any customization settings, but those will come eventually; they aren't hard to do, just time consuming.

We also made a brief documentation for those interested in syncing up gameplay elements to music in Unreal 4. It's here.

We were motivated to post this demo because two very kind people contacted us about Project BPM and gave us a new surge of motivation to work on our stuff. This wasn't an easy feat, because we're swamped with work and had to carve time out of our sleeping time.

So excuse us while we go to sleep, and enjoy the demo!

2018/02/28

Character face rig!

Hi!

Geril here. This month in my free time, just to expand our portfolio a little, I've created a new character. It's still heavily work-in-progress, but it's gotten interesting enough to show you! It's a standard character for use in Unreal 4 and made in Blender, as usual, but this time instead of creating our own skeleton from scratch, I made the skeleton based on this .blend file recommended by Epic for Unreal 4.


While I kept the bone structure and names of the original skeleton, I modified everything I needed to to suit the character, and - as always - I made a specific and unique facial rig. If you've been our reader for a while, you might have noticed that we prefer using shape keys/morph targets for our characters' faces. It's true that they are easier to use for games, but they also limit things quite a bit. And even though I love limitations, because limitations force me to be creative, it was about time for me to step out of my comfort zone and create a dedicated video game character complete with a bone-driven face rig. So I did. The face has a lot of bones that are constrained to a bunch of driver bones for easier use, so within a few seconds I can animate stupid faces for the poor character.


At least that's how it started.


Right now on the pictures and the attached video is a face with standard driver bones. The eyes will move by texture panning, but what will really be interesting is that we plan to swap out parts of the skeletal mesh during runtime. At first this might sound strange, especially for a rig like this, but we want to see how well the Unreal Engine handles this stuff.

The mesh swaps will happen on the fly: the face will be split into multiple smaller meshes (the splits will be invisible of course), and for example when the character blinks, the eye meshes will switch to a closed-eyed mesh version instead of the eyelids stretching over the eyes. We will need multiple meshes which are spread out in-between the open and closed eye states to make a smooth animation, and then we still have to solve how to handle the textures for these meshes. The upside is that we don't have to worry about texture stretching, because we'll be using separate meshes for O and U sounds, and even for sticking the tongue out.


But first we'll need a finished and stable face rig that could work standalone as well. The separate mesh pieces will be created using these weights too, and then modified in a way that leaves most of the weights intact. That way if the lips have a smile on them, and the mesh changes to an O-sound, the smile will stay. It sounds weird in text, but if all goes according to our plans, it should work pretty well. We'll have to change our animation style a bit to fit this technology, maybe make it snappier so the mesh changes won't look abrupt. The only question remaining is how UE4 will react to this all.

While I'm still working on the rig, Lussy's making the textures for the character. This takes up most of our free time now, so look forward to more posts about it in the coming months!

2018/01/31

Still busy...

Hi!

Okay, the fact that we are busy hasn't changed since last month... But at least now I have some time to write about our latest Unreal 4 adventures.


We had to script a horseman. The horse mesh was given to us, complete with materials and animations. The challenge was putting an already heavily script-based human on top of the horse and syncing up their animations and movements.


The movement part was easy, we attached the human's pelvis to a socket on the horse's saddle. However the animations were a bit more tricky, and we still think the whole system could have been done better, but not sure how.



This was our solution:

We united the horse and human skeletons in Blender, and animated the human on top of the horse that way. We then exported the unified skeleton, along with the animations, and assigned the horse to that skeleton. An animblueprint was built for the unified skeleton that contains IKs for putting the rein in the human's hands and the stirrup on his feet (If the IKs relied on any variables outside of their respective animblueprint, they lagged behind about one frame).


Now comes the hacky part: we stuck the human on top of the horse, retargeted the riding animations of the merged skeleton onto the human's skeleton, then built the same animblueprint for its skeleton too, sans the IKs. We rigged the whole thing so that the merged skeleton's BP sends signals to the human's BP to change anim states, so the changes occur at the same time and the animations stay in sync. Occasional errors still occur once in a blue moon (oh crap, today's a blue moon!), but we suspect those are framerate-related.

This system feels bloated and makes any later changes risky, however, we couldn't come up with anything more stable at the moment, and under our current pressure. Do you guys have ideas on how to make such a system more stable?

2017/12/31

Busy busy...

This has been a terribly busy month for us, so we don't have time to write a proper post now. However, we've learned a lot about making two AnimBlueprints (a horse and a horseman) precisely sync up in Unreal 4, so we'll have something to write about next month!

Happy holidays, everyone!