levifloat-blog

[levifloat-blog]

Touch wood

Looks like we’ve fuckin’ done it. A bit of research turned up the potential for the problem to be with buoyancy on destructible meshes, so I started a work-around which re-jigged the boat base class. Initially I added an invisible static mesh (the hull the destructible was based off of) as a proxy for the collision, sending the collision event to the destructible. This seemed to slightly improve the crashes, but only slightly. Then Jake suggested we re-parent the entire actor, and entirely remove the destructible element. It looked like it would be a major undertaking, but it only took a few minutes for him to do, and as it turns out, fucking works. All of this time, the problem was with the class we inherited from the Ocean Project (specifically the buoyant destructible parent class).

So now we can actually play the game and test features and fix bugs. Basically, it’s now playable, we just need to polish and implement a few things that we’ve forgotten etc. So now the only major (ish) problem is the tentacle still feels a little weird. But, like I said, I can now test it for longer than a few seconds. COOL.

[levifloat-blog]

Panic mode engaged

The project now crashes as soon as I try to start it. I’’m terrified. I’ve tried rolling back to earlier revisions, but have no idea whats causing this. Nothing has changed as far as I know.

Shit.

[levifloat-blog]

Bug fix?

So today we took another good look at the crashing, with Stefan’s help. No joy though. he highlighted the error and gave us a bit more info, but ultimately couldn’t find a root cause either. As he explained it, there’s a double up happening somewhere, where a particular variable is being either deleted or overwritten before another function tries to access it. So my working theory is that the problem is stemming from having multiple buoyancy components on the same actor. My revised boat base make more use of multiple components, so might be causing the crashes more frequently, although checking the old ones, they still have multiples too. So my next course of action is to swap the active buoyant sails with ‘dumb’ meshes, to be deleted and substituted on a fracture event. This means they will be their own actor when they float, which will solve the problem if it is in fact the multiples.

The other significant change from today is the implementation of a smart blueprint for the crew that appear when a boat is destroyed. They now are spawned as either standard crew, captain, or a rarer special unit. They make no difference to gameplay, but they do have their own animations, and will have some sounds etc to flesh out the experience. And the special one has its own particle effect that’s pretty distinctive. They spawn a soul which flies to the locker when they die as well, and all the functional stuff still happens, so I didn’t break anything! (Oh and the souls have been fully-featured now too, textured animated and audio driving)

Looks like it’ll be a late night today finishing Andy’s paper with Bobby too. So yeah, happy days.

[levifloat-blog]

Also

We’ve been adding a huge amount of cool new sounds, compliments of Charlie, and some new models and particles, which will make the game waaaaay better. So expect a screencap today/tomorrow.

[levifloat-blog]

Busy busy

So the last few weeks have been full on, working til studio close every night. We’ve gotten through huge swathes of content, however we’re still grappling with a few functional issues. I can’t even list all the new things we’ve added, but unfortunately dealing with some of the same issues we’ve had for quite some time. There are only really two major ones, but they both have their own unique difficulties.

First off, there’s the tentacles. The physics that drive the tentacles, and they scale they are, mean that it often behaves unpredictably. the major problems we’ve had stem from joints jittering or shaking, and they cause massive issues when it comes to swinging them fluidly. What I think is happening is when a joint strays too far from the one in front or behind it, or exceeds an angular limit, it projects or otherwise stretches the joint to cope. This would probably be fine if it were a single joint or a small object, but because all of those joins are important to how your primary actor in the scene functions, its hugely problematic. The other problem with this, is that whatever is happening in these joints appears to negate the inertia at that location as well, causing the motion of the tentacle to slow or stop, ruining the smooth, fluid behaviour it’s designed for. The fix for this is going to be a lot of trial and error I think, but I’m also acutely aware that I cannot go backwards (if I mess up the working version somehow) with so little time before submission. Unfortunately, this means that the key element of portraying the scale of the movement is also compromised. The limb moving unpredictably means that my understanding of the system isn’t great enough to play with, which will mean we end up going with the best ‘playable’ version of the tentacle, instead of the one that drives the best sense of scale. If I can get this working in the next few days, then I might still have enough wiggle-room in the timeline to experiment with some other ways to drive a feeling of mass. However, the other papers are at crunch time now too, so I have at least a day’s worth I need to spend on the other papers.

Second major problem is game crashes. We are getting a mysterious crash occurring, and we have no idea why. Jake spent an hour or so investigating this morning, which I also sat in on parts of, but with little to no success. It’s no fault of his at all, but seems like it’s something a little more complex than we are able to deal with. My assumption is that it’s related to our buoyant actors in some way. They have an interesting problem in their building (which we inherited as part of the plugin) which causes the game to crash any time a buoyancy test point is created under the ocean plane. It’s an incredibly dumb flaw in the otherwise pretty workable system (although to be fair, I’m only going on the assumption that this is the case, as I haven’t investigated any fixes for this), but my thought might be that it occurs when boats or their dropped items enter the scene. Aside from the boats themselves, there are about a half dozen other items which contain buoyancy test points, and half of those spawn when a boat breaks. Any of these could in theory be responsible, but we’re not sure how or why. We also haven’t been able to reproduce it with absolute predictability, so it’s even harder to assess and fix. I’m going to try to reach out to some slightly more code-savvy people in the next few days to sort it out, and hopefully we can get some joy there. This bug is going to be the key one, because it stops the game after about 2min every time, and that would be terrible for our final exhibition. We need to at the very least have something that works for 5-10 minutes at a time, so we can actually show off all of our content, because half the assets only show up a few rounds in, as well as other sounds and so on. So yeah, this is priority one. Even if the tentacle is jittery, or the points didn’t work, or the sounds were in the wrong place, or anything at all else, the game at least needs to stay open. The other thought I had is switching to a different round format to see if that resolves anything, but I’m not sure it’ll have any effect.

Finally, we did have a major breakthrough today. Myself and the team were under the impression the game could not be compiled and build, which we all though Jake had been adamant about. However, today we were talking about it, and he reckoned we could. So about an hour later, and with a bit of tinkering with write permissions etc, we managed to get the game building. It’s totally worth having as well, as loading a built project is much less resource-heavy than from editor, and means we could display our work much more easily, and restart more easily if need be. The only downside is that previously we had experienced physics actors resolving their jitters when run in a compiled build, but unfortunately this was not the case this time. The jitters persist, so that needs more time.

[levifloat-blog]

Progress Update

Right, haven’t posted in a while. So over the break, we had a few things that distracted from our studio work. This meant we didn’t make a great deal of progress. As it stands now, we have working water, that we’re more or less happy with. We have enough control over colour and other material parameters, and the height map is easy enough to pull from to simulate collision etc. The boats have reasonably simple AI, but not functioning in all of their behaviours. They need to be able to approach, engage an ‘active’ behaviour, attack, avoid etc. Approach and movement so far are working, so today I’ll be implementing a better movement target system, so that it can change where it wants to move to, instead of just tracking the player. Attacking and damage need to be implemented too. The tentacle is all good so far, only problem being that it doesn’t collide with enough mass, so it deflects off of the boats too much. Also, the boats aren’t set up elegantly enough for damage and hit impulses etc. So the task list for today is to complete at least 90% of the boat behaviours (what to do when it’s close enough to player, when player goes underwater, attacking etc) and look into some more interesting behaviour such as panicking and running away or kamikaze behaviours.

Worth talking about as well, is what me and Jake did yesterday. We were struggling to get good screencaps (as well as thinking ahead for a display feature for open studio), so we needed an elegant solution for multiple instances of the game, from different locations. We also needed these separate instances to be both stereo rendered and non, so that we could output one standard view to a monitor for a screencap, and the other could display to the vive. We also experimented with doing it over a local network, but our limited understanding of replication made that impossible, although light reading implied that it’s incredibly difficult to replicate a physics component like our tentacle anyway. But yeah, we did get it working locally, so at the very least we could display that way, and potentially (though we didn’t test) record screen captures that way as well.

[levifloat-blog]

See the part with my part for my part

Checkout this week’s development Log

[levifloat-blog]

Tentacle Testing part tres

Ok, so I’ve got a great starter tentacle. Feels responsive enough without being too stiff, right in the spot between a fishing rod and a pool noodle. Needs a lot more tweaking (this is where testing is going to start) to make sure it behaves correctly, but again, this is a good starter. I’m not sure I’ve fully described what my goals are for the ‘feel’ component, it needs to:

Be Responsive

Be Tactile

Imply Mass, scale

Be Consistent

By responsive I mean it has to be able to move quickly through the scene, to respond quickly to the player. It needs to be tactile in respect to hitting, that it has good feedback on the controller, and good effects to reward and mark a collision. It needs to feel like it is massive, not like a car aerial but like the tentacle of a sea-monster. This one is somewhat in contrast to responsiveness, as weight and mass imply a sort of lumbering, slow movement. This will be one of the things I ask about quantitatively in the user-testing. Lastly (although incredibly importantly), it needs to be consistent. It needs to easy to learn, so that the time it takes for the player to accept it as an extension of them-self is as low as possible. It should be easy to learn.

So now I’m waiting on a texture etc. for it, and I can say version one is done. From here, I need to make a few variations, and migrate into the main game project.

[levifloat-blog]

Tentacle Testing part dos

So after a week away from studio on external work, we’ve come back with a renewed motivation. I’ve been working through some of the issues we were having with tentacle ‘feel’. Basically, we (I) had a limited understanding of what parameters influenced the behaviour of the tentacle, so I’ve spent a couple hours today working through isolated tests. There are a tonne of variables that effect the fluid, whipping movement of the tentacle, among them are the linear and angular damping, the weight of each section, the overall weight, the angle each joint is locked to, the stiffness of that lock etc. And further, each one of those is on a per joint/segment basis, as do the lengths of the bones that we make into the mesh. So there’s a TONNE to sort through, to refine the motion. I’ve so far tested through 3 sets of paired variables. First off, we made two equal length sections, with and equal number of joints. On one, we had uniform separations through the length, where the other had the joints getting closer together towards the end. Straight away, the non-uniform setup was much more promising, and closer to what we wanted. In future, we can simulate this even if we go for uniform spacing, by locking joints together in sections, but for now non-uniform is better. Next I placed the base skeleton in a scene with 4 variations. There were two with adjusted angular limits, with one having stiff joints all the way through, the other getting less stiff through the length. The other two were mass adjustments, in the same arrangement; one uniformly heavy, the other tapering. I then attached these all to the same box, running a few simulations with the box being moved, to see how the cables moved. Straight away it was clear the angular modulations made much more of a difference, and the mass tests were almost unnoticeable. Later on these will probably be important for fine-tuning, but at the moment, just the stiffness/springy-ness is plenty to play with. And we haven’t even looked at damping yet. Or connection points. Lots to do.

Oh, and we’re going to try and finish the whole thing this week.

[levifloat-blog]

Kraken Tentacle Update

Just spent a half hour investigating what each of the physics asset creation parameters do when its being generated from the skeletal mesh. It turns out the majority of our problem with the scaling was to do with the original import settings. I’ve now managed to implement much better setting in with the current model in our VR project, with a drastically better result. 95% of the shaking is gone, and the stiffness is a lot more intuitive. However, the tentacle still doesn’t quite whip as nicely as intended. I’ll be adjusting this via the stiffness parameter, by tightening up the closer bones, and loosening and increasing the mass of the ones further out. Next I need to get into the collision events and get some more interesting interactions going, grip/grab mechanics etc. But a pretty sweet update.

[levifloat-blog]

Here we have an update on the boat AI. I’ve made a bit of a start, at the moment they have 3 states of awareness of the player for being in the correct direction, to the left or to the right. A few problems at the moment, one is that they aren’t clever enough to run the responses to the three states simultaneously. This means if you can get outside of its range far enough, it discontinues tracking AND movement. I’ll have to make a few changes to the sequence of its decisions, but it should be easy to fix. Secondly, the range it’s using isn’t super intuitive, as it’s using absolute degrees (in a very complicated series of functions I might add), which flip out when you go past 360 back to zero. So, I’ll probably rewrite that.

In terms of developments to come, they need to scale their turning speeds based on the angle to target as well, they need to be able to stop and turn around etc. and they need to be able to track the opposite side of the boat.

[levifloat-blog]

This is a video from the first VR test of the tentacle. Come a bit of a ways since, but this was the initial test. In this version, the tentacles were imported as-is, no refinement to stiffness or collision sizes etc. Post this test, we incorporated a much nicer model, and managed to get it behaving correctly via adjustment of the joint stiffness and capsule weights, but came across a game-breaking shaking when the tentacle was scaled with the player to sea-monster size. So with that not working we’re opting to re-start the process, modelling 5 or so variations of tentacle and working them through the scaling/collider adjustments to try and nail down the problem and hopefully its solution.

[levifloat-blog]

Team vidlog for the week

[levifloat-blog]

Here’s an update of the tentacles, this was from a few days ago, before I’d sussed variable stiffness. They now twist and flex much more consistently, otherwise they were actually pretty unmanageable. They behaved a little like strips of paper, but they need a heavy, satisfying weight to them, so that we can make the player feel attached to the space. 

[levifloat-blog]

Dev blog one for the Kraken project

[levifloat-blog]

Tentacle Whippin

So I hit a major milestone this morning that I’d been working towards the week been. After messing with the various approaches to creating a tentacle, I not only have one that works structurally, but is now integrated into the Vive-ready test project. Having something actually working with the Vive hand controllers is really promising, as it’s the only part of developing the tentacle that I was overly concerned about. From here I need to refine the movement of it, give it a bit more rigidity in parts and weight. When that’s done, hopefully the first boats and the basic water mechanics will be done too, which means I can begin on making the boats react to being hit etc. That’d be playable. So now I’m doing a bit of testing in my environment before I take that knowledge back across to the main project.

[levifloat-blog]

Over the last couple of days, I’ve been working on different approaches to prototyping a tentacle. The major chunks to bite off dev-wise are the tentacle action and the ocean waves, so while Jake works on the ocean, I’m prototyping the tentacle. I’ve gone through 3 different approaches now and have come to one that has a bit of promise. The first was to simulate the parts of the tentacles as essentially a chain, each having their own individual link to the last (which were all generated in a smart blueprint, given number of tentacles, restitution etc). Although this approach worked on its own, when attempting to graft it to a controller it did not work at all. It seemed to be an issue of hierarchy, a actors don’t seem to easily parent to other actors for some reason, combined with the complex relationship of the various components and locations. Second, much shorter approach was to essentially replicate that as a manually linked chain. This seemed to work a little better, however the links didn’t simulate past the second link for some reason. The option we’re working on at the moment is a skeletal mesh, using Unreal’s rag-doll. I need to test it on Vive, but I’m 90% sure it’ll be an easy transition. Just need to test it when Jake gets in tomorrow.