next »

[Pixel Noise]

These last posts are a useful bit of info! Nicely written out. Bookmarking this page for later reference

[AnomalousUnderdog]

Attacks now properly use torso-lean-to-target. I've made it that some attacks only lean up (spear thrusts), some allow leaning both up and down (rapier normal attacks), and others don't use it at all (spear impale, warhammer pound, rapier dash attack, basically, all of the charged attacks).

Mostly, when the attack is a vertical motion (spear thrusts), then it doesn't need it too much, but when the attack is a horizontal motion (warhammer swings), then it needs to adjust the torso a lot.

Had a terrible headache so I had to take a break for the rest of the weekend.

[AnomalousUnderdog]

Started working on the first “spell” in the game: “Impaler’s Sanctuary”. A spell of create spear wall (in a circular formation). It doesn’t have the appropriate visual effects yet, and the spear wall is supposed to get damaged when hit, and would break when hit enough times.

It can be used defensively, to give yourself space when surrounded (as they rise up, they’re supposed to deal damage to any nearby enemies and push them back), or offensively, to trap enemies inside until they destroy the spear wall with their attacks.

I’m not yet sure how spells will cost you. Whether they have a “mana cost” and you having mana points, or if instead you have a limited number of times to use it that recharge when you rest, or something else entirely.

I’m also not yet sure about the controls for this. There will be many of these weapon-based spells that you can cast. I’m thinking the D-pad on the controller will let you select the active spell, and something like R1 or R2 to cast it. On the keyboard, I’d just have them on the number keys, like in MMO controls.







No, they’re besieging my little castle!!! After a day, I've implemented destructibility on the spear walls. The spears now also deal some damage while they’re rising up.

While this was easy to implement, the code is getting a little bit convoluted here, since those spears in the spear wall act as damage-dealers (which can destroy objects), but they’re also destroyable objects themselves (obviously, damage-dealers are prevented from damaging themselves). It works nicely, but I suspect I’ll need to refactor that part of the code in the future.

[AnomalousUnderdog]

As much as I love using Hacknplan, my Internet connection has been getting flaky as of late, and cloud apps lose their usefulness. So I’m transitioning my todo list in this offline software called Portable Kanban.

I’ve been suggesting to the hacknplan devs to make a desktop client that can work offline and would just sync (I’d be willing to pay for their subscription plans for that), but I never got a reply. Guess that’s too much of a tall order.

In Portable Kanban, everything is in one screen, and it doesn’t have the cool “game design model” organization feature of hacknplan, but it works offline, which was what I needed.

At least the cool thing with it is it allows me to add custom fields for the tasks, which I use for this neat trick: you rate each task by importance and difficulty. Importance is how much business value it adds to the product, Difficulty is the amount of risk, uncertainty, and technical complexity to pull off completing the task.

You’ll want to focus on prioritizing tasks that have high importance but low difficulty (and at the lowest in the list are low importance, high difficulty tasks). The rationale being you’d want a lot of important things done as early as possible.



This shouldn’t be your only metric for deciding what to do next, as it’s also easy if you do tasks that are similar. This only counts if you have multiple hats in development: if you decided to do a task involving programming a new feature, then do some new attack animations, then to bug-fixing player input, then to a task improving an existing old feature, it’s a lot of hassle to re-orient your mind to the task at hand, especially when the tasks have little to do with each other.

Sometimes it’s easier if you batch together work that are similar. Perhaps work on tasks regarding the GUI first, then do the programming tasks in one go. Or if you have programming task regarding attack animations, maybe you’d want to group that together with the tasks for creating attack animations.

[AnomalousUnderdog]

Started implementing camera shake after putting it off for so long.

I accidentally left camera shake values too high while fixing a bug and that happened.

So I decided to play around with it more. Clearly there's a point where I should stop goofing off with the camera shake, but I don't think I passed that yet.

[AnomalousUnderdog]

Testing functionality for preventing hitting through walls. I still need to make it that your attack animation is disrupted when you hit a wall, but for now, I’m just making sure damage-dealing is prevented if there’s a wall in-between you and the enemy.

[Pixel Noise]

Man I can't imagine how much work goes into this as a solo dev - there are so many systems to implement, things to consider, etc. Thank you for preventing damage through walls. Though I'll admit I enjoy taking advantage of this at times in Souls PvP, it is a huge annoyance when you are on the receiving end

[AnomalousUnderdog]

Your attacks are now interrupted if you hit a wall/obstacle. The “got interrupted” animations probably need some tweaking, but the functionality is now working nicely.

This now makes the wide swings of the Warhammer useless in narrow passageways, as it will most certainly just collide with the walls. But it makes the Rapier’s charged attack more useful since that does a phase dash (bypasses walls/obstacles).

While I’m already making it that the attack animation is disrupted when you hit a wall, sometimes the hit detection still manages to detect the enemies (if the hit detection found enemies before the attack got disrupted).

So here’s another test to make sure you can’t damage through walls/barriers, but still hit enemies on the same side as you are. This doesn’t happen all the time though, so it took me a lot of tries to even get to show this in recording.







The cyan lines indicate hit detection on enemies (a raycast from your torso to theirs), but the purple X on the left one indicates it found a barrier at that spot, so damaging didn’t proceed.

[AnomalousUnderdog]

Ported my game to Unity 2017.2. Pretty ok for the most part. The editor itself hasn’t crashed yet, despite what I hear about other people’s experience with 2017.x.

But I did need to change quite a bit of stuff to keep the framerate the same as before.

________

Horizontal Layout Group and Vertical Layout Group is slow

There were at least, no cryptic compile errors. But testing the game, first thing I noticed was a big decrease in framerate. I was getting about less than 20 fps whereas I got around 30-50 fps back in Unity 5.5.5.

Take note this is the fps inside the Unity Editor though. Standalone builds always have higher framerate values, regardless if it was done in Unity 5.5.5 or 2017.2.



But having less than 20 fps inside the Unity Editor was too much. So I suspect something was wrong.

Firing up the profiler showed me the problem:



A lot of calculations being made with rebuilding the GUI layout. I’m not entirely sure why, in Unity 5.5.5, I was not having this problem.

Using process of elimination (disabling GameObjects until the framerate gets high enough), I pinpointed the problem to the enemy healthbars. I had about 20 enemies in my test scene, so that was 20 enemy healthbars.

In this healthbar I had number values of their health and stamina, positioned using Horizontal Layout Group.



I had those numbers disabled (their GameObjects were disabled) because I decided it made the GUI too “noisy” to show a bunch of numbers on-screen anyway. So I was wondering why Unity 2017.2 was calculating them even though they were not visible.

Furthermore, not all 20 healthbars were being displayed at the same time. Most of the time, only the healthbar of the enemy you targeted will show up.

I do remember a Unite presentation telling me Layout Groups were slow. I’m just confused why the Unity 5.5.5 version of my game was not suffering badly compared to now.

(GUI part of this talk starts at 23:29)





I’m not inclined to wonder too much about this. So for now, I simply disabled the Horizontal Layout Group component itself.



That pretty much fixed the framerate problem during gameplay.

________

Alpha Channel not importing

When I went to the in-game menu, I got this:


I don’t know why I was getting white squares there. Looking at the sprites involved, I found out Unity 2017.2 is not able to import the alpha channel of some .psd files properly anymore.

In Unity, the image looked like this, (see the preview, showing it completely white):



In Photoshop, it looks like this (see the checkered background indicating transparency):



Not all of the .psd files were having this problem. So I just worked around it for now by exporting the affected .psd files into .png files and using those.

However, this should probably not be happening in the first place, so I’m guessing it’s a regression bug.

________

Unity UI Text

My other problem was a big slowdown in framerate whenever I enter the in-game menu.

The profiler again, pinpointed the problem:



About 9 MB was incidentally being allocated per-frame by this NicerOutline script I was using. This was from the Unity UI Extensions I was using, to give some outlining effect to the Unity UI Text.

I had them in all of my UI Text, so going to a screen with a lot of text slowed down the game (like the Graphics Settings Screen).

This is how text effects (drop shadow, outline, gradient, etc.) are done in the standard Unity UI Text component. They are individual scripts. NicerOutline being one of them that I have in my project.




I’ll just clarify that I’m using an old version of Unity UI Extensions that I haven’t bothered updating, so maybe they have fixed that now.

However, the thing is I’ve since upgraded to using TextMesh Pro (ever since it became free), and TextMesh Pro doesn’t have this problem. It also has a bunch of other features that make it superior to the standard UI Text (crispier looking font, built-in letter spacing, etc.)

Text effects in TextMesh Pro are done in a dedicated shader, specifically built for it. It’s fast since effects are done entirely in the GPU, instead of C# scripts.



But since replacing all of my UI Text into TextMesh Pro was a very boring thing to do (I had a lot of Text in many screens), I hadn’t done it yet, and I kept holding off that task since it didn’t seem to affect the game that badly (until now).

So for a long time, only some parts of the GUI was using TextMesh Pro, while the rest was still doing it the old way, with the standard Unity UI Text plus the NicerOutline script.

Obviously I can’t keep using that; it was slowing down the game. I decided it was better to go ahead and finally go with TextMesh Pro all the way.

________

Cloth Simulation and AI

And with that, the game’s framerate was generally better. Some things are still taking a big chunk out of the total frame time, but they do not affect the framerate badly.

The cloth simulation takes a big chunk (the highlighted orange part), since all characters in the test scene are using cloth simulation. I really can’t do anything about the code for that since that’s PhysX.



The most I could probably do is forcibly turn off cloth simulation for characters that are either too far away and/or obscured by walls. Certainly something worth trying later on.

And occasionally, my AI system. Every now and then, all enemies do some raycasts, overlap sphere checks, simple distance checks, etc. to detect if the player/hostile character or some breakable obstacle is nearby.



But again, both of those are not affecting the framerate that badly, compared to the other problems I mentioned. So I decided not to do anything about them.

Just note that those screenshots of the profiler indicate an average of 30 fps because the profiler itself can slow things down a little. When I close the profiler, the Unity Editor can get something like 40 fps on average (and something like 50+ fps if the camera is not showing any enemy on-screen).

And again, like I mentioned earlier, a standalone build of the game will get an even higher amount of framerate.

________

3rd-party Plugins

Updating from Unity 5.5.5 to 2017.2 was quite a big jump, so I naturally expected I have to update a lot of the plugins I use (TextMesh Pro included): Editor Console Pro (better console log window), Rainbow Folders (customizable folder icons in Unity’s project window), InControl (customizable control bindings for the game), Shader Forge (visual shader editor).

If you’re doing an upgrade like that, just be sure to check the plugin’s readme in case you need to do something extra to make sure it updates properly. Usually you need to completely delete the plugin’s folder and import the new version, to ensure no undesired files remain. Just don’t accidentally delete your user preferences for those plugins, if they have any.

In TextMesh Pro for example, I made a separate folder called “TMP User” and moved the TMP Settings file, all the color gradient presets, etc. into that. Those are files that I’ve already edited to suit my tastes, so I don’t want them to get overwritten whenever I update TextMesh Pro.

________

All in all, upgrading to Unity 2017.2 went smoothly. I think I’ll keep using this unless I see some showstopper bug (i.e. the Unity Editor crashing).

[AnomalousUnderdog]

I’ve modified the texture on Desparo’s cape, adding tattered edges and dirtied up the texture a bit.

Technically, I’m done with version 1 of the combat demo so I’m doing these minor tasks I’ve been holding off on, before I move on to making the next part of the combat demo.

[AnomalousUnderdog]

Finally updated the look of the player’s health and stamina bar. The old ones were actually free art from opengameart.org that I used as placeholders.

I’ve also added a purple glow on the stamina bar to indicate that you’re starting to deplete your stamina. I’m guessing it’s usefulness will vary from person to person. I personally have a habit of occasionally glancing at my health/stamina when fighting.

[Pixel Noise]

I definitely keep an eye on my stamina. I think the glow is a nice idea, but the current iteration transitions too hard/fast, and I think the purple actually ends up obscuring how much stamina you have left. Since you are using the yellow to show how much stamina was just used, maybe a softer/more gradual transition, intensifying the yellow and maybe adding some glow to it? I think that you be less obtrusive, while still effective.

[AnomalousUnderdog]

I definitely keep an eye on my stamina. I think the glow is a nice idea, but the current iteration transitions too hard/fast, and I think the purple actually ends up obscuring how much stamina you have left. Since you are using the yellow to show how much stamina was just used, maybe a softer/more gradual transition, intensifying the yellow and maybe adding some glow to it? I think that you be less obtrusive, while still effective.

I sped that up on purpose, because when it was slower, the effect didn't have enough time to finish fading in, because the natural stamina regain finally kicked in. That's also because I maintain that the effect only shows when you have 1/4th or less stamina (I don't want it staying too long).

I'm not so worried that the purple obscuring how much stamina is left, it's a warning that you're running low and need to stop exhausting yourself anyway.

I actually added a bright highlight at the edge of the stamina bar to help tell where it ends (that's in both the normal and purple version). I can try making that more apparent. I also want to look into changing the colors used.

[Pixel Noise]

Good points. I do see the highlight at the end of the stamina bar, but maybe it could be slightly more present.

[McMutton]

I haven't checked in on this in a while, but man- the project has improved quite a bit!

Looks fantastic with the current updates.

[faborro]

Nice read! Especially your approach on the performance issues. Great development.
I'm hesitant, but will have to upgrade my unity version to 2017.2 soon, too

[AnomalousUnderdog]

Thanks everyone!





Here’s a compilation of all the work-in-progress video clips I made for 2017.

As a recap, here's last year's summary:

[AnomalousUnderdog]

Improved the analog stick target switching controls, it’s now based on the closest target inside a cone.

Used to be, I’m simply searching for the enemy closest to a line starting from the center of the screen. It didn’t really work very well, but at the time I couldn’t figure out a better way to do it.

I have no idea how games do these things. So drumming up my head to invent some good algorithm for this, I realized target switching shouldn’t be using a line at all, but a cone area. It should search all enemies inside the cone that is closest to the tip (of that cone). If it can’t find one, only then would it look for the closest enemy outside the cone.

[Tuba]

First time seeing this, looks pretty cool, like a fast paced Dark Souls, which is not something you would expect.

Nice job.

[AnomalousUnderdog]

First time seeing this, looks pretty cool, like a fast paced Dark Souls, which is not something you would expect.

Nice job.

Thanks! My references include Nioh and Bloodborne, which are pretty much fast-paced Dark Souls type games.