It's already March!

Hi! Geril here.

Working on a new project has its ups and downs. On the one hand, fresh new ideas and goals, and on the other hand, doing things that we already did many times.

But this time we got something new. We can't say much about the project - NDA and all -, but we are now gaining experience with working with motion capture. Because of this, we were forced to learn how to use Post Process Animation Blueprints in Unreal 4, and man, we should have learnt this years ago, it makes helper-bone handling a non-issue. We used Unreal's Metahuman as the basis, so we learnt how to do it by mimicking its methods, adjusting them to our needs and changing them to fit our custom skeleton.

I really want to show off things, but we can't.

On a different note, after the massive burnout and nightmares, Lussy is finally getting back to her usual creative mode, working on a 3D model she wanted to make for months now.

Oh, and we modded a Nintendo DS Lite to output an RCA signal. We're using it with our projector, so it looks pretty nice. This pushed Lussy to finally finish Castlevania: Order of Ecclesia and play Okamiden. One day I want to print a new case for the modded DS, but our 3D printer is acting up, so I'll just have to do it later.

Also, we needed an Xbox Series controller so we wanted to buy one. I asked Lussy to choose one, but she didn't like any of the controllers for sale so we ordered a custom one - Lussy designed the controller to her liking. It has our company's name on it, so it's officially ours. The extra features are nice and all but what I really like about it is its battery life.

Still Alive!

Sorry for the long silence. This year so far has just been too stressful to do anything but work. And because work created most of the stress and drama in our lives, it kinda fed off itself, overwhelming us to the point where we couldn't take it anymore.

So after three years, we're leaving the project we've been working on.

There were specific things that prompted the actual resignation (or more like, the last straws that broke the camel's back), but even if we end up writing about them, it won't be now, only some time in the future. We're not sure we want to even talk about the project we were on - and that makes assembling our portfolio quite hard.

Anyway, now that we're done, we can do things that we actually want to do, like improve our development skills, make our own little projects, spend time on hobbies or just in general, be less stressed.

We have several opportunities, we'll see what we want to do with our lives, but one thing is for sure, we'll need a bit of chill after this whole mess.

Also, we wrote a few posts in the last eight months that we never released, mostly because we were too tired and overworked to think about the blog. Here's some of those, just to log what happened with us in 2022 so far:

March:

We rarely talk about our actual work nowadays, but there's something that we really want to share: we've been working with iPhone's Live Link Face app, based on the Apple ARKit. Connected with Unreal 4, it allows us to use real time facial capture. It works well out of the box, but to make it work the way we wanted it to, Lussy had to adjust many things, and create logic that mimics missing features and makes everything move smoother.

One of the issues with this tech is that it can not separate the two eyebrows' movements. We worked around this by using slow-moving eyebrow blendspaces fed by the eyes' lookat position. Also, shoulder movement was added to the head movements. Honestly, what really sells the method is the simulated physics on the hair.

We'd really like to show you what we did, but we can't.

June:

This month, we got our hands on a Steam Deck.

Nice little machine, and it's a weird experience after the GPD Win 2. The most interesting thing about it is its operating system. Steam OS is a custom Linux that acts like Windows, making independent Windows-like directory systems for each software.

Control-wise it's quite agile, I (Geril) can customise it any way I want, and because we already have a Steam Controller, we know what to expect from its touch pads, and already got used to its quirks.

As somebody who played WoW a lot on the GPD Win 1 and 2, I found the Deck's options a big jump forward. There's many ways to adjust and optimize the controls, it is even possible to add scrolling menus and context sensitive values to change the controls' attributes.

We've played WoW, Hatsune Miku, Fallout 4 and a bunch of indie titles. We've even used Discord while playing WoW, and it worked just fine.

The next step is to figure out if we can use Unreal Editor on the Deck. It's not easy to set up a launcher on it, desktop mode has to be used to add the software to Steam as a Non-Steam title.

Lussy is exploring the hardware's latency with rhythm games, and on its own it works fine, but on the TV or with a controller, there is some noticeable latency.

Maybe the official dock will solve the issue, we'll see.

---

Anyway, in the coming months, look forward to a lot more content.

PIU VR!

Merry holidays and such!

Geril here.

This year was... a lot. Didn't have time for personal projects or anything. Well, at least at the end of the year we had a bit of time to just do whatever, so we're trying to achieve Lussy's ultimate goal: getting a Pump it Up arcade system in our household.

Sadly, we don't have the space or the money for an actual PIU arcade cabinet, so we went for the next best thing: emulation. But not just plain old emulation with keyboard or basic flimsy dance-pad inputs, no. We're going VR.

Well, for the inputs at least, we're not sure about the headset. We may not need that.

So in our time over the holidays, we grabbed one of Lussy's old boots, and attached the Vive controller to it. The position recognition was fine after we figured out the right way to attach the Vive controllers. What Lussy didn't like was that the moment for the actual contact with the floor was imprecise.

Because of that, the next step was to attach pressure sensors to the boots. After some cutting, wiring and duct taping, Lussy found the right positioning for the sensors, and the VR boots 0.7 was born!

We did the whole thing in Unreal 4 – because of course we did –, and used a control rig to make a basic mannequin character mimic the foot and leg movements. It was pretty hard to figure out the right rotation values, but in the end Lussy made it work with the tech we made.

I made a basic dancepad mesh and we reused some of our old assets from our older rhythm game prototype, so we actually have some visuals. Nothing fancy, but it helps us understand what's going on. Can't wait to work on it more.

In January we'll probably have no time to work on it. The start of the year is never easy and now that we have a company it's getting nightmarish. But we'll see.

Burnout.

Hey! Geril here.

Well, these few months were quite a struggle to get through.

We crunched, and burned out like dried leaf set on fire. The project we're working on got an update and we've had to work a lot on it to get it to the finish line. We got a little bit of a break afterwards so we've been sorting out all the stuff we put away because of work. One of these things were the blogposts.

So what happened with us outside of work? Not much. Really, we concentrated on work so much we didn't have time for other things. 

In the last week, I learnt photogrammetry, what is basically a bunch of photos of an object taken from different angles and pulled through a photogrammetry software - I used Meshroom. Of course it's not that easy, because the result is noisy, super high-res and at a weird angle, but I can just fix those issues in Blender and bake the hi-res mesh onto a relatively low-res mesh.

After a few tries I realized that this works best with food and natural shapes, not with precise geometrical ones, so I mostly just made food-scans, removed the plate or bowl and baked the rest to a lower res version of the photogrammetry mesh, then put it back on a plate or bowl. (he is basically photographing everything before eating, and he takes a LOT more photos than your average Instagram food blogger - Lussy)

It's fun, I also baked a normal map and a few support masks – roughness and AO – so it looks pretty nice in my opinion. For optimization reasons I also made several LOD levels for the mesh, too.

Right now it doesn't have a purpose, or any plans with it, I just wanted to learn how to do it.

Also, Lussy gave me my birthday gift early this year, I got a Twin Famicom from her! It's an awesome system, a combo of the Famicom and its Disk System. I love it.

We also have a Metroid disk for it, and it runs much smoother than the PAL NES version we also have. So we're collecting Famicom and Famicom Disk games now. It's getting really hard to find a good way to store our games. We're planning to buy more shelves, but without a car it's hard to get them home.

Oh well. 

We hope that from now on we'll have more free time. We're not sure right now, but maybe.

New (non-personal) project!

Hi, Geril here.

This month we met a fellow artist who happened to be working on a FPS project.
He showed me their work, and although I liked the quality of the graphics, I thought the technology behind it was lacking. I made a deal with their team: we'll make an FPS project similar to theirs using their assets, but in Unreal; and if they like it, we'll be able to get on their team.
So this month we worked hard on making an FPS game from scratch. Of course because Unreal is excellent for shooter games, it was much easier than the other projects we have worked on, so we made rapid progress.

As of now, we have implemented:
– health and shield systems
– a basic enemy AI
– sprinting
– a weapon database with different weapon types (we made lasers, ballistic bullets, explosives and an energy beam for now)
– weapon sway and recoil for feedback purposes
– ammo logic
– weapon and ammo pickups
– a GUI directional hurt indicator
– different enemy types and a spawner
– a gore system (dismemberment and such)
– custom damage logic
– interruptible death sequences before ragdolling
– splitscreen local multiplayer
– switching to third person camera on player death

And some more, smaller stuff.

The team liked what we did in less than a month so they let us on the team!
As for now, we can't show you any images or videos, but we'll ask them if we could share some test footage here.

Another Project Contrivance build!

It was a surprisingly hard month.
It started out slow, but at around the middle of it, we suddenly got a bunch of work to do. We'll talk about it more when it's relevant.

Also, we uploaded a new build of Project Contrivance!
You can download it here.

It has a new overworld, where you can choose the puzzle maps you want to play via warp pads, and you can also discover secrets (but it's mostly just WIP things for now).
Also, you can find a secret warp in each of the puzzle maps as well. They are pretty hard to find.
Other than that, there's a new puzzle map, too.

We hope you'll like it!

Contriving again!

Hi! Geril here. It was a quite mixed month.

Our friend Davy said something that made us think: we should concentrate on one single project until it's done.
Well, yeah, it sounds obvious, but because we make a living as developers working in outsourcing and such, it's hard to concentrate on just one thing, since we have to train ourselves in different parts of game development.
But he's right. If we want to be independent developers, not just regular developers, then we have to deliver a game. We've got a lot of Unreal projects just laying around, most of them are for paid commissions, but some of them are ours. So we started checking our projects, and their potentials:

– OLP is a bit too big in scale to be feasible with just two of us. It's an excellent project to practice animation, locomotion logic and such, but it's a game that we can't really finish by ourselves.

– Project Blind aka. Lemniscate. Oh Lemniscate, you grayscale mess, you... The main issue with this project is, we were inexperienced in Unreal, and what we made is very unstable. Last time I tried, it wasn't able to launch itself in the editor. So we'd have to remake the whole thing from scratch. And that game is so dark and uninspiring to begin with that we just don't have the spirit to work on it.
Maybe if we have something to shake up the visuals and gameplay, we'll take another look.

– Project BPM. We do have ideas as to where we could take this proof-of-concept project, but for now, it's just a Taiko clone. But that's fine, since it was only made to figure out if it was possible to develop an accurate rhythm game inside Unreal 4, and it was a success. We will work on it further once the concept becomes more solid.

– Project Contrivance aka Puzzle For Two. This project works surprisingly well. We checked it again, and wow, it still works fine and can be built on pretty easily. The design is basic, but it can be charming (the robots glow and make cute little noises when you pull the L or R triggers, we still like that part). The movement could be tighter and the camera needs a complete rework, but the game's logic is solid, and basic visual programming as a gameplay element is kinda fun.

So we started working on Contrivance again. In just a week, we made two playable maps (okay, we made one and touched up an older one) and added lots of features to them. We'll bake it this weekend and put it up for download later. We'll leave a link here too – if you have time and want to try something very unpolished and gimmicky, then you're free to download it. We are more than happy to hear your opinions and criticism on it. We have to improve ourselves somehow, after all.

Davy, if you guys are reading, our reply is coming soon! :)

EDIT: We have uploaded the project, here is a link.

New historical project and also some OLP!

Whew, this has been a tough month.

We've been working on a new project based on The Oregon Trail video game. We're trying to recreate the game mechanics and most if it is already done in fact, and it has only been a week or so. It feels a little like practicing, really. We made it so that it will run on very low-spec devices, something we've never had to worry about in the past, so we're also learning new things.

The shaders are entirely unlit, and the graphical representation so far is very minimal. There is already a working menu system however, and the game can be started up and finished – something else that we've only got to once or twice. It's a bite sized project and it's satisfying to see how fast we are progressing with it.

The project is half Hungarian, half English at the moment, and the subject will most likely be related to Hungarian history, the historical accuracy assured by the same team that we worked with for our past historical projects. Here's a test playthrough of it. There is no UI design yet whatsoever, so it's very cluttered and basic, but gets the job done.

In other news, you can now throw weapons against the wall in Project OLP, and they will stick. So there's also that. Here's a strangely wide video:

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.

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.

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?

A GPD Win post!

Hi!

This month we've taught horses to follow paths, made a character creation system and also put together some complex interactive materials. All that in Unreal 4. Too bad we can't show any of this right now, because it's for our current job. In any case, we're learning a lot working full-time in Unreal 4!

There's a thing we only briefly mentioned in our previous post but didn't elaborate on it: the GPD Win that Lussy created the rhythm game project with, using Unreal 4.

The GPD Win is advertised as a portable Windows 10 PC, and Geril bought one about 3 months ago. At first he considered getting a LattePanda, but figured it would be too much trouble to make it stable. (Since, funnily enough, Geril bought it for work, stability is a huge concern)

Even though our GPD is for work, we still use it to play some games: we play World of Warcraft on it using random public Wi-Fi hotspots; Fallout: New Vegas and various indie games. For example, Cuphead runs with a stable 60fps.

To play any "serious" modern games on it, we need to do some heavy work and tweaking just to get it running in a bearable manner, so we don't do it very often. It's just too much effort, but it's just about what we expected.

But as for Unreal 4, we had no clue how it would run. It's a huge relief that it runs well, surprisingly well. Of course everything that can be set to low has to be set to low, and everything takes a really long time to load and compile.

At first, Geril created simple materials, material instances, particle effects and levels. Editing materials is fine, but compiling shaders is a problem - probably because the built-in storage is really slow. It also gets very hot when compiling shaders (and even the maximum fan speed doesn't help), so we actually had to leave it in the fridge for an hour to complete compiling about 5000 shaders. Well, at least anyone who opened the fridge had a laugh.

The framerate immediately drops in the editor when working with any lights in the scene. Funnily enough, playing in editor produces better framerates than not starting the scene at all.

What really works well on it though are blueprints. Last month's practice project was created almost entirely on the GPD, and apart from the controls (using blueprints with analog sticks...), there wasn't much to complain about.

We could talk about what's actually in the GPD, but we think it's irrelevant - it's basically a 64 bit PC, and Windows PCs are known for their customization options, therefore any issues can ultimately be solved. We were positively surprised how agile the Unreal Engine is, and how much work can be done using such a tiny machine.

So we can work even on the go! Yay... I guess?

With that said, Happy Halloween! (The Halloween spirit evaded us this year)

Keeping the beat in Unreal 4!

We're really looking forward to not beginning our posts with this: we've been very busy this month, and had almost no time for our personal projects.

That's only almost, though. We have had time for an approximately 3-day practice project in Unreal 4 (about 1.5 days of this was done on a GPD Win device, which can run Unreal 4, impressively, and is also portable, so we could work on it during a long trip). I (Lussy) have finally figured out a way to bind things to a soundwave's position (in seconds) in Blueprints, so we've made a replica of the rhythm game Taiko. Because we didn't have to come up with new gameplay, and only had to implement the existing mechanics, we've been messing around with binding things to BPM, and working on sickeningly colorful graphics.


Excuse me for the sub-par play, it was late and oh yeah we had to show off the 'Miss' particle effects!

The song and beatmap in the video are from one of the original Taiko games, but we used this osu file to bring them into our project by exporting the contents to .csv and importing it into a data table.

We tried to only include really light, unlit-only graphics that wouldn't impact gameplay. We even though about only using 2D sprites or just widgets, but it just didn't seem right for an Unreal project. But in any case, the gameplay stays stable even if the framerate dips. I can't overstate this, we're REALLY happy about the whole thing syncing up, and we never had to use ticks. I've been trying for years to accomplish this

So where to from here... This is a really low priority, tiny project, but we have a few ideas for our own gameplay mechanics that we are going to replace the Taiko mechanics with. Only the timing mechanism will stay. Until then, ... We managed to actually sync things up to a given song and rhythm without the framerate messing things up! Woooo!

Summer's over already!...

Hey.

We're going through a pretty rough transitional period at the moment. We've had time to do this article for Sketchfab however, so enjoy:

Sketchfab Art Spotlight: Frey Couch Scene Sound

This is related to the Fisheye Placebo fanart lipsync scene we've done. We show off some making of pics in the article, and describe our workflow.

There's also this little test we've cooked up, it's an Unreal 4 Blueprint AI system with very basic pathfinding and a few interactive objects.

The interactive objects work via a point of interest system. First, we created an offset for the head that follows the points of interest that the character is closest to (or that has more influence). After those, we've also added attractors and repellers as child blueprints to the PoI-s. The attractor has a chance to summon nearby characters to itself and make them clap, and the repeller can either explode and kill characters that were caught in the blast, and/or send the rest fleeing and cowering in fear. These are all pretty rough and basic, but functional nonetheless. We spent about a day working on them, they were made as a tech demo.

Oh yeah, and the assets are from the World of Warcraft.

Peace!

Conversation Blueprints!

Hi! It's Lussy.

We're busier than ever this month. While we couldn't significantly progress with our projects, I had a little time to practice UE4 Blueprint scripting, so I created a conversation system using the new String Tables in UE 4.16. It's still in progress, but here are some features:

• Each line of NPC dialogue can have up to four possible replies from the player. The conversation itself is saved into structs that feed off String Tables.

• There are stats. Player replies can add to or subtract from a stat, and replies can also be tied to a stat requirement; for example, if your knowledge is under 5, a reply will be grayed out. I went with one stat this time, and it's "Personal", which is code name for how many times the player talked with an NPC and wasn't a complete ass. More stats can be added as needed.

• I based the camera on Legend of Zelda: Breath of the Wild - the camera can be rotated during conversation, and is locked to the middle point between the player character and the NPC. There's a smooth interpolation when a dialogue begins and ends.

• Greetings above the head - we gave each NPC a random personality out of 4 possible types: Normal, Wise, Upbeat and Lazy. Influenced by Animal Crossing.
  The personality type determines the greeting that appears above the NPC's head when walking close to them. We plan to include a system that lets NPCs insert random, personality-specific words into their sentences, or change adjectives to their own most preferred word. 

I still need to work on making this a more open system; for example, right now it's not possible to converse with more than one person at a time. I also need to figure out a way to tie the conversations to certain situations that come up in the game. Another feature I'd like to add is an optional animation for each line, for each character involved in the conversation.

If this becomes stable, we plan to use it in some of our projects, when it's appropriate to add such a system.

Unreal 4.16 & 3D printing!

Hi!

This month was also very busy. We're currently working on an outsourced project, and that takes up a lot of our time, but at least we're using Unreal 4 and Substance Painter, so we feel at home. The extra practice doesn't hurt, either.

Unreal 4 got updated again! We've been waiting for volumetric lights and fog, and 4.16 finally delivered them. They will be useful for Lemniscate, since we've used fake godray effects for all the lamps, and this will make it easier and hopefully cost less in terms of hardware. It also looks cool.

In other news, we got our hands on a simple CTC Prusa 3D printer! We're still calibrating it little by little, messing up lots of prints but nailing others. Geril likes the DIY-aspect of it, and the fact that almost all components can be replaced and upgraded, just like a PC. Lussy likes it because once it works reliably, it will be very useful for cosplay.

Putting the printer together wasn't easy (it took about 8 hours), but we've learned a lot about 3D printing. We're still in the process of attaching extra cooling fans, so our prints are imprecise, but here's a bust of one of our characters, Beat!

Have a nice day!