#floatstudios

[charliehnz]

Kraken Gameplay and Showreel

Gameplay

https://www.youtube.com/watch?v=DsATadueK6k

Showreel

https://www.youtube.com/watch?v=2XFPucSVTOU

[charliehnz]

Digital Portfolio for Charles Hlavac - Creative Freelance

Check out the updated site!

[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]

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.

[jameshehehblog-blog]

Kraken Development Log 06

The sixth development log for Float Studios' current project, "Kraken!".

[jameshehehblog-blog]

The big pirate ship is finally done after a lot of un foreseen interruptions I managed to get it done. This was by far on of the hardest models to UV. I also used the cannon that I had made earlier but since you only see just the front of them I decided to cut all the faces that you couldn't see to save on rendering costs.