Back from Japan!

Hey, this is Lussy.

We are back from Japan, and we have brought back an unbelievable amount of used video games for very cheap! The only issue was packing them all up without breaking them during flight, but we succeeded – nothing was harmed, we were victorious, cue Final Fantasy victory music.

After successfully securing tickets to two L'Arc～en～Ciel Christmas shows (L'ArChristmas...ha), we flew to Japan for two weeks. Geril has only attended one show, and I went to both of them – they were amazing, as expected.
So it was the tickets that gave us the final push to actually travel, but we were looking forward to thrifting for and playing all sorts of video games there – we are developers after all, so there were a lot of things to check out in Tokyo.

One thing is certain, we won't be able to look at thrifting the same again. In our country, everything costs way more by default, and the 'used' condition's standards are lower as well. In Book Offs in Japan, what we found in the 'junk' section for 100 Yen was about the same as the standard 'used' section here, however, even the Japanese 'used' section wasn't as expensive as ours usually are.

If you're going to Japan, and read about places in Akihabara like Super Potato – those flashier places are good for looking and browsing and all, and you'll be able to find the rarest games there in the best condition. But if you're willing to spend a little time (okay, a LOT of time) digging around in the 'Off' chain of stores (Book Off, Hard Off, Hobby Off), you'll be able to find a lot of things for dirt cheap. And even when shopping from the untested junk section, we've only had two games refuse to load, and we're still working on cleaning those games, so they might end up working as well.

Our haul. There are some unrelated objects in the photo too, sorry about that...

As far as consoles go, we've picked up a WonderSwan, a Nintendo DS Lite and DSi, a Nintendo 64 and a PlayStation 2. The first three because we were missing them from our collection, and the second two for playing Japanese games. We've had a blast digging around for PS1, PS2 and N64 games during daytime and then going back to the hotel at night to try them out. I also had a great time looking for music CDs (which are still profitable in Japan, I've even bought a few recent ones), but since my Japanese is very patchy and I read slow, Geril often left me on the music floor and went through the whole shop by the time I was finished.

Akihabara

Aside from shopping around, we also visited all the arcades that we saw. And the rhythm game sections! Although they were very loud and very packed, a lot of thought went into them. For example, many of the games had an audio out where you could plug in your own headphones to hear the game better (the machines were placed tightly next to each other, so hearing anything properly is an issue). You could also pay with various cards instead of coins, including the subway card that the both of us have purchased, so when we ran out of coins we tapped into our transportation money.
Sadly the fighting games were almost always on the upper floors in the smoking sections, so we had to avoid those.

It was nice to see that video games weren't only purchased by the stereotypical target audience. We saw grey-haired old men browsing games, we've seen women browsing games, we saw everyone openly browsing the porn section – there was everything.

However, we made two major mistakes: not renting portable Wi-Fi and not learning Japanese in advance. While there were free Wi-Fi hotspots, we needed to register for almost all of them and their speed was very limited. In our hotel, we had a single hotspot for a 10-story building, so we were lucky if anything loaded.
And English... we're not sure if this is because people really don't speak English, or they are just too embarrassed to try, but almost nobody tried. So it would have been useful to speak the language just a little more fluently in order to have a better time.

Okay, that's it for this year. Happy New Year, everyone!

Still consistently working on OLP! (...sort of)

Hey.

This month was a pretty intense crunch time for us, but we did make time for progressing with OLP.

Some of the systems we've integrated include head/eye IKs.

These were already included in the original OLP, but as a sort of always-on feature that we were surprised even worked. The version we've created now is only active when it absolutely needs to be.

IKs are activated when the character gets near an interactable item (in this case, a pickup). Once the item gets in range, it sends an overlap event that turns on the IK and saves the item's position.

This next part caused us some headache at first: if an item isn't moving, there's no need to get its position every tick. So we turned on sleep/wake events for the item to let the player character know when it was moving or physically active, so now the position only gets updated when it is absolutely necessary. We also included kill switches for the head and eye IKs separately, so when the characters are so small on the screen or running so fast that they wouldn't be visible anyways, they don't get calculated.

The most unnecessary feature we added in relation to this is a blink for when the IKs get activated or deactivated. Since the eye pops onto the target object immediately, it looked weird, but the blink fixes this. So even though it's unnecessary, we kind of like it.

Oh, and the Lookat node inside AnimBlueprints is a broken nightmare. We still have to do something about the head IK's transitions.

In other news, we are traveling to Tokyo next month!

At first, it was my (Lussy's) idea to go, and Geril was a little reluctant. But after checking out all the generously packed video game stores online, even he is pretty hyped up about the trip. We're pretty sure we'll be back at the end of next month with at least one very weird story about it.

Laters!

Remaking old stuff!

So after last month, we continued working on Project OLP.

Our current concept of OLP is heavily based on this GDC video by David Rosen (we highly recommend checking this out!).

We've created our player character's movement animations by hooking up poses only and blending them from blueprints. The only actual animation sequence we used was the idle animation.

And her tail and ears are physically active.

We've also cleaned the project out of all outdated assets and code and started almost from scratch with all the experience we've gained since we last worked on this. It's kind of cathartic to be able to start it all over and have development go so much faster and smoother.




We're almost caught up with all the features that were present in the original project, only now they work better and the Tick event isn't as badly overused as it used to be (still looking for ways to optimize blueprints, though).

(Sorry about the last frames of the gifs, our capture software likes to mess things up as it stops capturing. Also, I'd like to note that it's impossible to arrange inserted pictures in this editor.)

Now that we could actually create some gameplay elements as opposed to only being able to move the character around, we've been creating pickup objects that can be used for combat, or as usable items. Geril is modeling all sorts of random things that players will be able to throw at each other when they don't have a weapon equipped. You'll be able to pick up most objects you see, and even destroy things to make more objects for yourself – if a wall shatters, you'll be able to take the bricks and throw them at your opponent. Different objects will have different properties and special effects: for example, a glass vial will shatter, leaving shards behind that will hurt whoever walks into them.

You can expect more to come in relation to this, we're kind of on a roll here.

On shipping something less than great...

We're not proud of every piece of work we've done.

I guess it's part of being a creator, but sometimes the final product of a project is so... not good, that we'd rather it didn't have our names attached to it.
It's a depressing feeling.

Story time.
We worked on a project for about a year. It was a day job for us, making a historical-educational movie that was rendered in Unreal Engine 4. We created AI for big armies and individual characters. It was kinda hard – most of the small team wasn't really familiar with UE4, and the assets were not optimized for videogame technologies (and some weren't even PBR). But the team decided to go ahead anyways.

We finished the AI and most of the logic by May, but the rest of the team had to work on a lot of other parts of the production as well, and so they had no time to test crowd simulation, combat and such.

Mid-June, they started rendering clips for the final movie, but they had trouble with the untested blueprints (as expected of untested technologies). Since we were already pushing the deadline, instead of properly testing and taking a step back and refining the system, the team rushed work and tried to work around smaller issues. On top of that, we didn't have time to properly train them to use the huge and complicated system they described they wanted, so the majority of the features we implemented went unused.

For example, we created a face customizer, kind of like in The Sims. A character could have a randomized, custom face applied, so the crowd didn't look like an army of clones. But instead of using that, they left the crowd without custom faces, so yeah, it does look like an army of clones. Or, at a lot of parts, blueprints weren't even used, just featureless skeletal meshes (no custom faces, no mimicry, not even eye movement).

We also had to animate a lot of scenes in a few days; scenes that would, under normal circumstances, take a few weeks, maybe a month to set up. So you can imagine what the quality of those animations is like.

When we saw the final version of the movie, we were baffled. We suspected, based on our communications with them, that the final result wasn't going to be spectacular, that the team had to cut corners to meet deadlines, but we never imagined they would ignore features we spent months on developing. It was just sad.

After watching (that was a funny situation, trying to keep a straight face in the office for our coworkers while watching the video), we came home and tried to go back to work but it was just too hard. I mean we spent a year on this project, and it looks and feels like we created nothing. Were we this bad at communicating, or was it just too complicated for others to use? Guess we'll never know. But it just about killed all of our motivation for a few weeks.

We're gonna continue working together with them on other projects – they said the main problem was the miscalculated deadline – and we're gonna use the experience we gained to try to make things better. It's just hard to do work after a result like this.
Especially on our own projects.

We wanted to post another Sketchfab thing this month, but this finished movie just shook us.
We've had almost no free time to work on our own stuff, and all for this...
But we digress.

We actually went back to our old project, Project OLP, to see if what we made back then was any good, or if we just imagined it. And... it still works, and it's a lot more developed than any of our other projects... so maybe we should continue working on it.
We'll decide later. But as for now, it's fun to work on something that we have full quality control over.

Still trying to figure out if there's life on mars.

Fallout 4 Vulpine race mod released!

Hey.

So this is sort of a huge milestone for us.

A few years ago, we started collaborating with BeardofSocrates on a mod for Fallout: New Vegas that brought a fox-like playable race into the game. Given how much we worked on anthropomorphic animal characters, it wasn't too far out of our comfort zone. But we ended up completing that project under the pseudonym Mystery Science Team, because of the backlash these types of mods tend to generate.

After that was done, we started work on a Fallout 4 version, and a lot more work went into that one, since we included a full character creation as well, with a complicated weighting and morphing process. Since Fallout 4 uses pseudo-PBR, the textures ended up looking a lot more detailed and complex as well. We thought about using the pseudonym again, but we decided we were proud enough of this mod to deal with the backlash.

An unbelievable amount of guesswork and trial and error went into creating this mod, and because of scheduling issues, we progressed slowly, but alas, the female version has been mostly completed and released a few days ago. You can check it out here.

Reading the feedback and comments on the public release, we're glad to see a lot of people think it's a quality mod and that makes the whole thing feel worthwhile. Of course there are also those who hate on the mod without giving it a chance, and label it as a furry mod right off the bat. We expected this, but it's still a bit baffling to see. Targeting furries wasn't our intention; we have collaborated in the development of the mod because animalistic mimicry is a lot more fun to create than human mimicry, fur is fun to paint, and modding something into a game that isn't supposed to be there is a challenge.

The male playable character is currently in development, and should be available eventually.

So, bottom line, we were Mystery Science Team and we are proud of what we have achieved with these mods. We're also happy that we ended up working together with BoS, because we wouldn't have made such a good friend otherwise.

PS: We're still trying to figure out if there is life on Mars.

Pump It Up arcade hardware!

Hi!

Phew, it's a really hot summer this year. We'd rather just lie down in a cold air-conditioned room, face down, and sleep. All day.

But!

Today we're showing you something different than usual.

My (Lussy) probably biggest wish as a kid was to have my own Pump It Up arcade cabinet. For those that don't know, Pump It Up is a Korean rhythm arcade game similar to DDR, but there is one additional panel on the floor and they are arranged differently. I prefer it to DDR because of the different panels, and also because of its soundtrack.

It was really hard for me to research anything about the arcade hardware, but a few days ago I found a main board for an older cabinet type, the MK-3. What little research I was able to do showed that this was the model that my old favorite software ran on, so I ended up buying it. It's a proprietary PC motherboard with some custom chips thrown in for good measure, and a glorious CD-ROM drive to read the software off of.

There are a bunch of parts missing, most notably the power supply, so we weren't able to test it yet. When we do get it running, the biggest challenge will be to find a set of pads for it, and find a place to store them at. We can't even begin to imagine what adventures this little machine will have us go through until we make it complete and get it in working order, but we're looking forward to them.

By the way, we are still working on our own rhythm game project, and the gameplay concept testing phase is coming along nicely, however there's still some work we need to do before we can show it off.

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.

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!

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!

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!

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!

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?