• Register
Post news RSS Weekly Update # 37 – Special Points and JavaScript Optimizations

It’s time to put more variety in the battles of CrossCode. Next to regular throwing, dashing, defense and close-combat, we plan to have special versions of these skills, which we currently call battle techs or simply techs.

Posted by on

37 is totally a prime number.

Also, after two weeks of work, we have some new stuff to show!It’s time to put more variety in the battles of CrossCode. Next to regular throwing, dashing, defense and close-combat, we plan to have special versions of these skills, which we currently call battle techs or simply techs.These days we’re working on all the stuff connected to battle techs (e.g. SP!).

However, something unexpected happened… Well, just read on to find out more!

Special Points (SP) in CrossCode

Introducing a new battle parameter: SP are required to execute battle techs, kinda like Mana or MP. The player will only have a very limited amount of SP (currently the maximum planned amount is 16). However, SP can be gather very quickly during combat: simply attacking the enemy will slowly increase your SP, even more so when using an enemy’s weak point. Outside of battle, SP will regenerate over time.
This week, we extended the player’s status HUD to include SP:


Okay, let’s explain the HUD is more detail!The first thing you might notice is that SP come in two colors: blue and purple.
Blue SP will regenerate automatically, while purple SP can only be collected during combat and will slowly degenerate outside of battle.
The SP that is currently regenerating (or degenerating) is displayed as small bar. We made an extra effort for a nice transition when those bars appear and disappear:


The second thing that might stand out: SPs are grouped in 4 units.
This is because the SP growth speed changes after every 4 units:


The size of the SP bar shows it: The first 4 SP are the quickest to increase, the 4 SP after that will take longer, the 4 after that even more so etc. How much we will increase the growth time every 4 units is still not entirely decided yet, as this is an important balancing factor. Point is: Gathering large amounts of SP takes longer than simply gathering and using small amounts. However, having large amounts of SP stacked might always pay off in critical situations, especially in difficult battles.

Of course, the number of SP won’t always be 12. We plan to increase the number of SP during the course of the game from 4 to 16:


As you can see: half of your SP will be blue and regenerate, while the other, purple half can be collected during battle.

The SP HUD was completed, working fine. Then we went ahead to integrate the actual battle techs when suddenly:


One evening Intero was testing the current build of CrossCode on his laptop. Is was not a gaming machine, so the performance was pretty poor. However, because of that we noticed something. Something that was bad news.

The current build was noticeably slower than the TechDemo++.(Tested in Chrome)…

Maybe that’s just me, but whenever I hear about performance problems in my games, I get really nervous. So I postponed any other plans for CrossCode and dealt with this problem right away. After some pretty frustrating testing rounds (JavaScript is fun to work with… UNTIL it comes to profiling and optimizations) I actually found the problem.

Turns out the problem was the games physics engine. However: the actual algorithm has barely changed – and still, everything took longer! The problem was something else: the data structures.
It was the hierarchy-based entity system (as found in impact.js) that leads to very slow performance in the physics (at least with Chrome/V8). This is actually critical information for anybody who plans to develop with impact.js and is concerned about performance. We might release a more detailed report about this, if anybody is interested!

Anyway! After we found the problem, we applied some ridiculously massive refactoring (@Impact.js Users: Just assume you need to modify every entity pos and size reference in your code. EVERY. SINGLE. ONE.)… and the performance improved.

A few numbers:
TechDemo++: 4ms per frame
Before Optimzation:: 5-6ms per frame
After Optimization:: 4-4.5ms per frame (well, there IS a bit of new stuff, afterall :P)

So… What else to say then:


*sigh* So much technical stuff. Who’s up for some graphics?

Yay moving pixels!

After that performance-related distraction Lachsen still found the time to put together a new charge animation for Lea:


You will see this one before executing a battle tech.

worked on several elemental effects. Like this nice electrical effect:


and TQ worked on more environmental graphics and we also got some new concept art ready… but let’s keep this for another weekly update, shall we? :D

So that’s all for these two weeks!

Also be warned: We might (finally) present some ‘new’ (yet already mentioned) members of Radical Fish Games.

Until then!


From that electrical effect GIF I see three different animations...just pointing that out

Reply Good karma Bad karma+1 vote

Nice performance catch!
Thanks for sharing and helping other web developers

Reply Good karma Bad karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.