CrossCode Update #45 It’s GIF time!

Alright, last update before the CrossWeek!

We finished our editor for animations and have some more or less interesting animations for you. We also started implementing the new tutorial boss enemy and added some nice new ball effects. Lastly we baked the game again, which is kinda like creating a release version.

Animation Editor

Felix finished the animation editor and even gave it some polish (we can’t resist, sorry :P). So, let’s summarize some features the editor has:

  • creation/deletion of multiple sub-entities
  • creation of several animations
  • creation of sub-animations per sub-entity
  • creation of sprites per sub-animation
  • inspect and play/stop animation via timeline
  • Drag-And-Drop entities and sprites for positioning

With this editor we simplify the process of creating complex animations, so we don’t spend huge amounts of time fiddling around in JSON files for every big boss………!



Let’s move on!

Felix used a rather funny placeholder enemy you might already have spotted on his Twitter account. Since an animation editor is nothing without an actual animation he created some… interesting animations. Here is a simple one:
anim-editor-3 We scaled the GIF down a bit to reduce the file size. It is also a bit faster than it actually is.

He then moved on to create something more mature:


Well… it WAS complex to animate, and it worked! Future animations will be at least as awesome as this one, promised!

Tutorial Boss

For the training session with captain Jet we mentioned in CrossUpdate #43, we added a special type of turret enemy, that will teach you how to aim better and use bouncing balls to your advantage. For this purpose we also created new types of balls. Check out this GIF for a “homing ball”-type shot by the large turret:


Of course these are just placeholder graphics but we hope they give you a good look at some interesting battle situations.


Some of you might wonder what we mean when saying “we baked the game again”. Well, baking is the process of merging all the game files together into a single compressed one. This is a feature available in impact.js by default. But we extended the process to also include a more advanced type of obfuscation via Google closure compiler, which has the tendency to break things…

like… breaking bad …


Okay we’ll stop now, promise.

Closure Compiler has some advantages, such as a type analysis that actually helped us spot some errors today. In the end we fixed a lot of bugs and got a version of the game that runs as smooth as the developer version. From now on we probably will bake the game more often to ensure everything works fine and we don’t end up with millions of problems when we actually want to release the game.

Aaaaaand that’s it for this week. Over the course of the next week we will be at CrossWeek, where some of our team members meet to work on CrossCode all day, no distractions. We hope we can produce some nice new content for you this way and also push the game towards the demo.

So stay tuned and until next time!

CrossCode Update #44 The Boss is approaching. Also: new Music!

It’s coming closer…


…and there will be no escape.

…because it’s a boss. You can’t escape from a boss. It’s a rule!

Anyway, welcome to another CrossCode Update!

Dat boss, srsly

We have been making a lot of progress towards our first real boss fight, though there is still plenty of work to be done.
That’s because this boss is not just like any other enemy. It’s complex. It pushes the engine to entirely new levels.

Well, to be precise: the boss will be composed out of several entities.
The goal here is to model a larger creature whose shape can’t be properly abstracted with a simple bounding box (the common shape of entities).
So instead, we put several entities together, e.g. one entity for the leg, another for the torso and so on.

Of course that means we’ll have to move and animated these entities in sync.
That’s what I’ve been implementing last week. Here is a screenshot of a test enemy based on the new technique:


This enemy is composed out of 3 entities. That’s kinda hard to see from this screenshot, so here’s another one, where Lea is standing on top of that… thing:


(I also apologize for coming up with such disturbing test graphics)

The work isn’t done with implementing this entity synchronization, though. We still need to have a way to create animations for these kind of multi-entity thingies. And no, you really don’t want to put together and animate several sprites by manually editing JSON assets. So yes, I started working on an editor for that. And that’s… kind of a long term project. Here’s a screenshot from the current state:


So, that’s not quite finished yet. But my goal is to complete it until the CrossWeek we plan to have soon (more on that later).

So, apart from all the technical stuff, we also got first graphics for the boss by T-Free. You can see them at the top of this post. Yep, that’s all for now. :P

Skill Menu, graphics, music, and DUNGEONS

Apart from all the boss related efforts, work continuous on several others ends as well. R.D. worked on the circuit menu and is close to finishing the circuit overview.
Martina made progress with the the map graphics of the new area (we’ll probably have a first preview ready for the next update). And then, Intero is back composing awesome music for us! Not only did he work on a new theme for the cargo ship, he also composed a new type of battle theme. In fact, you can listen to a preview here:

Kind of an unexpected turn from the other battle themes, right? We’d be happy to hear your opinion!

Finally, we had a very productive planning session this week. We did some brainstorming and collected several ideas for puzzles, enemies and the general graphical design of the first dungeons of the game! We push the planning of the dungeons, since we plan include them in our next milestone.

Milestone and CrossWeek

Apropos milestone. The current milestone is for spring which is… now. But we’re not quite ready yet. So we set the final deadline for our milestone to 20th April.
And also, we’ll be having our CrossWeek from 14th to 20th of April!
CrossWeek means, we’ll meet up together at one place and work on CrossCode, full-time, for one week.
That should be sufficient to finish that milestone once and for all!

And that’s all for this update! Stay tuned for the next update. Who knows, maybe you’ll see more of that mysterious boss enemy.

Until then!

CrossCode Update #43 Content Here!

Welcome back!

Finally it is time for a brand new CrossCode update! We’ve been working a lot on new content, such as a training session with captain Jet, the first boss battle, a complete new area, and the circuit menu.

Training with Jet, boss battle and new area

You might not know it, but Jet is pretty good at throwing balls, too. This is why Lea gets an extra training session with him, going through some advanced combat mechanics. In contrast to the tutorial in the cargo hold, this will all happen on the deck of the cargo ship. The idea is to give the player a better understanding of mechanics so he can pummel enemies more effectively. It is also a part of the plot so we aim to create a good mix of both tutorial and story. If you already know the mechanics you will be able to skip through the tutorial bits, while new players will get an optional “how-to” part.

How this looks, you ask? Something like this:

In this task, your goal is to hit the target-bot 10 times in quick succession. If you have too many misses or take too much time, the captain will show you how you can quickly fire multiple shots while retaining your aim.

For the boss battle we do not have that much information for you. We sketched out its design and discussed on how you fight this boss (hint: attack its weak point for massive damage). Over the coming weeks we plan to actually integrate the boss into the game. However this comes with a new addition to our engine which enables handling animations and entities with multiple parts or sprites. So it might take some time.

As for the new area is the first one outside of the cargo ship. It’s in a very rough state as of now and we just started creating assets for it. This means our graphics artist work on creating the environment and details. We will show you more of this area as soon as we got something more fleshed out. Until then we can already tell you that the region is influenced by Japanese gardens mixed with a futuristic setting.

Circuit menu and something familiar

The circuit menu comes along nicely. We pretty much finished the overview menu. Here is a quick picture of the current state of the menu:

As you can see, there are already 2 element trees done. Adding the other 2 is basically nothing more than adding one line of code for every tree.

While I was coding the overview menu, Felix and I realized that the detail view we showed in CrossCode Update #41 could be a real challenge performance wise. The amount of GUI elements would quickly reach a number that could be a serious bottleneck because of the sheer number of skills. Because we knew that eventually we come to the point where this problem would occur on other GUI elements as well, Felix optimized the GUI system… again. He abstracted the way GUI elements are drawn, which oddly enough increased the performance a lot. This new change also makes it easier for us to change the render context in case we want to implement a WebGL solution for the rendering. So, good news for everyone! We have a much nicer syntax to draw things on the screen and you get better performance (If you interested in more information, leave a comment).

And that’s it for this update! Hope you enjoyed reading it!

Optimizing an HTML5 game engine using composition over inheritance

Hey, everybody!

Due to some vacations and other distractions we’re not quite ready to give you our bi-weekly CrossUpdate.
However, as promised, we now finally post our technical article about performance.

Here we go!

Incoming performance problems

We started with HTML5 game development around the end of 2011. We bought an impact.js license and started working on CrossCode. And since CrossCode demanded 3D collision, we modified the engine – and continued doing so until almost every nook and cranny was changed in one way or the other. So it’s safe to say that we did not only develop a game but a whole game engine with it.

And of course, whether you create a game or a game engine, performance is always an issue. To be frank, initially we did not pay too much attention to performance. We saw that our game was running with 60 fps on modern machines. 60 fps for an HTML5 game – what more do you want, right?

However, about half a year after we released the TechDemo++, things changed as we had a terrible realization:

Our game has become slower.

Yes, it was slower. Not because there was more content or complexity. When running the same maps with about the same number of entities, we experience an decrease in performance when comparing the latest development version with the TechDemo++.

Fortunately, we managed to fix these performance issues. And with this technical post, we want to share our experiences.

The core of the problem

Some time ago, Google released a very interesting video about optimizing JavaScript games for V8. Around 33:30 they describe how two properties of the code will decrease JavaScript performance, as they make it hard for V8 to apply its optimizations:

  1. Polymorphism: calling the same functions with lot of different input objects.
  2. Object size: a large number of properties per object.

Our game, as any game based on impact.js, uses composition over inheritance to implement entities.

It turns out that composition over inheritance in JavaScript will inherently lead to polymorphism and huge object sizes and therefore to performance issues. And the worst thing about this: these issues will not show right away but over time as you get a larger variety of complex entities.

Bummer, right? Well, let’s first explain the issue with composition over inheritance in more detail. Afterwards we will show you how you can still fix all this without implementing the whole entity system from scratch.

Composition over inheritance under the looking glass

What does composition over inheritance mean in our context? The idea is that the game engine provides a generic entity base class from which all other game entities should be derived. Derived entities classes can add more properties and implement new functionality. In a game engine such as impact.js it is encouraged that each new entity is created as a new class. So what we get is something like this:


The first problem becomes apparent once our entities grow in complexity: since all functionality is stuffed into entity classes, we accumulate a huge amount of object properties. Here is an example how this applied to our ActorEntity class:


So in short: we easily passed the object property limit until which object access is optimized in V8.

The next problem lies in to the use of our entities within the game engine – the collision engine and rendering. Because collision and rendering is one process that is the same for all kind of entities, we inevitably arrive at this situation:


And this, dear readers, is polymorphism to the max. To be precise, it wouldn’t be polymorphism for other object oriented languages such as C++. Those languages have an explicit object system, where the base class can be passed through these kinds of algorithms, guaranteeing fast property access. However, we’re talking about JavaScript here – a prototype-based language in which we merely simulate object oriented programming. As a result, we get flat object structures – one object containing the properties of all ancestor classes and the top class itself. So basically we have an individual object signature per entity class and therefore: polymorphism.

The consequence: the drawing and collision procedures are very hard to optimize for most of today’s JavaScript engines. And these procedures are the very bottlenecks of every game engine. So in short: bad news.

But fear not, as there are ways to fix this. And we don’t even need to throw away the whole composition over inheritance pattern.

Fixing the performance issues

Now that we understand the reason for the performance issues, it’s time to fix them. Since all these issues rise from the composition over inheritance pattern, an obvious “fix” would be to simply not use this pattern and move to something else, e.g. an entity component system. At this point we can basically overhaul the whole game engine itself – and that is not always an option. However, there is also the option to go for a mixture of both patterns, where you introduce components only for performance-critical aspects of entities and use composition over inheritance for everything else.

In our case, we decided to split the drawing and collision aspects of entities into separate components:

  • The drawing aspect is enclosed into Sprite components
  • The collision aspect is enclosed into CollEntry (Collision Entry) components

Both the Sprite and CollEntry components are free from any class hierarchy – there is only one class for each component, which is used for all entities. This is essential to make this fix work.

Entity properties are distributed among the entity class and the two new components. Since the drawing and collision aspects take a major share of these properties, the size of the entities class is greatly reduced.


To retain control over all properties, the entity will simply keep a reference to both the Sprite and CollEntry components

Finally, performance-critical algorithms of the game engine are modified to work on the new components only: the collision detection operates on CollEntries and the rendering on Sprites.

And that is all. In practice, these modifications demand a huge amount of code refactoring. However, most of these changes are of syntactical nature, e.g. “this.pos.x” needs to be changed to “this.coll.pos.x”, whereas “coll” is the reference to the CollEntry from within the entity. We managed to refactor our (fairly blown up) game code in about 2 days.

Performance results

Optimizing JavaScript is tricky, since JavaScript engines do a lot of optimizations by themselves. This makes it more important than ever to avoid premature optimizations. You never exactly know what impact your changes will have on the overall performance. In our case, we detected the bottlenecks by comparing profiling results of the TechDemo++ and the current WIP version of CrossCode. Finally, to be certain that our optimizations did in fact help, we compared the overall performance before and after the changes.

First, we compared the collision performance before and after we introduced CollEntries. For this we used a collision stress-test, where plenty of NPCs were simply running against each other:


We got the following results:

Browser ms per frame Improvement
before after
Chrome 32 10.7 – 11.6 ms 5.9 – 6.4 ms 45%
Firefox 27 7.8 – 8.4 ms 7.0 – 7.6 ms 10%
IE 10 5.4 – 6.0 ms 5.4 – 5.5 ms 4%

As you can see, we got a general improvement for all browsers. Especially the performance in Chrome increased a lot.

Second, we applied a similar optimization in our GUI system, where we extracted the most common parameters from the GUI base class into a separate Gui Hook class.
Again we used a stress-test, displaying the part of our menu with the most visible content:


Again, we got a general improvement:

Browser ms per frame Improvement
before after
Chrome 32 6.0 – 6.2 ms 5.6 – 5.9 ms 6%
Firefox 27 5.0 – 5.8 ms 3.7 – 4.0 ms 29%
IE 10 4.0 – 4.4 ms 3.5 – 4.0 ms 11%

Interesting: even though we basically applied the same optimization, we get more speedup in the other browsers this time, especially in Firefox. We have no idea why that is, really. Again, JavaScript performance is kinda like black magic – it’s hard to tell why exactly things become faster.

Moral of the story

So what did we learn from all of this? How about: Drop composition over inheritance because it is slow! Right?

Frankly, we wouldn’t make this kind of statement. It is clear now that approaches such as the entity component system are a better choice with respect to performance. However, composition over inheritance still has other advantages. For instance, we think that our inheritance based entity classes are much easier to read and understand. In the end inheritance will only lead to performance problems if your game reaches a high degree of complexity. So if your game only includes a small number of entities with a low number of properties (something close to the regular impact.js engine), you’ll be fine. And even if you arrive at complex territory, you can still isolate bottlenecks and apply improvements as described in this article.

So in the end: there is no need to drop composition over inheritance all together.

And this concludes our technical report about performance!
I hope you learned something new about the wild and frustrating world of high performance JavaScript.

Until next time!

CrossCode Update #43 Mostly Graphics

Hi again!
Yes, we’re one day late this time. Sorry for that!

Let’s go right to the update. Since last time, we worked mostly on graphical content – so expect some nice pictures.

Rhombus Square at the horizon

We have shown you concept art from a new place called Rhombus Square in a previous update.
Now I have created first in-game graphics for this location – a neat background:


What you see here is a skyline view at Rhombus Square. This background will be displayed during an important cutscene at the beginning of the game, which will be developed soon.

More cabin details and other graphics

Thanks to Teekuh, the crew of our cargo ship won’t starve anymore with this new, fantastic galley:

Note: this screen is only a mock up, which will be properly implemented soon. That’s why the lighting is kind of strange in the lower left corner.

In addition, T-Free is currently working on a new enemy (a kind of mid-boss) and Martina will soon continue working on graphics for a completely new area!


So, not too much content for the game this time, right? This is partly because we spend more time on another end:
We continued planning the future of Radical Fish Games as a company. We talked with several people on how to get finances for our project. We got to the conclusion that crowd funding will be our best bet. Still, there might be some other ways that will help us out financially, at least in short terms. In general: things are not always that easy in Germany…

And that’s all for this week’s update! In case you’re still waiting for our next Technical Report about Optimizing JavaScript in Game Engines – I’ll work on this one soon and post it before the next CrossUpdate. So, within the next two weeks.

Thanks for following our news and until next time!

CrossCode Update #42 Under the Hood

Welcome back!

That was quite the fun week and we did a lot of work on different ends. We added more details to the game and worked on advancing the plot. The Equipment menu got a bit more polished and some fresh new hotkey buttons. We also carved out the details on the circuit menu and began to implement the skilltree itself into the game. We also started planning a little something for our team!

Details… so many details

The cargo ship is the starting area of the game and since this will (probably) be the first thing the players sees we want to make sure they find a place filled with details and atmosphere. Of course this means more time is needed to finish up the area but don’t worry we will not go over the top. Over time creating areas will get more easy for us and we plan to reuse details in later areas if they fit. So apart from us explaining why we love details… what did changed?

First T-Free worked a bit on the waves and made them appear more staving. You can see the difference here:
These are the old ones, and the new ones look like this:

water (Lea defies gravity!)

Thanks to TQ and T-Free the cabins got a new update which includes the workers lounge where people calm down after a hard day of work or… well… play video games:
gamerdude(Can you guess the game which he’s playing? And yes, that typo is intended!)

There has been different works on other areas too, but we can’t show them yet so stay tuned ;)

Equipment Menu

So I finally finished up the functionality of the equipment menu. It took quite a while but I also added a lot of reusable features along the way. Lachsen just rewrote our button manager system that handles moving through buttons via mouse, keyboard and gamepad to better fit what we need. Now we can easily integrate multiple menus on top of each other without any collision problems between different groups of buttons. This is a large topic to cover actually. If you want to know more, leave a comment and we might make a technical post regarding your questions. Next to the new system I also added hotkey buttons. These buttons can be found in the top bar in the menu. They serve as shortcuts to different menus or to revisit the help menu (the help dialog will only appear once if you enter the menu the first time).
You can get a look on it in this picture:

Optimization & Circuit Menu

Lachsen spent some time on optimizing our entity system. The result is really amazing. The whole update goes faster by 1 millisecond! Okay, that doesn’t sound much by itself… but it is about 20% of our total time per frame. This mostly means that we can possibly add more entities to a map without losing those precious frames. Here is a quick look at our performance testing range:

These are 313 entities running at smooth 60 frames per second. We will cover more about this topic in an upcoming technical post about optimization in CrossCode. If you’re interested you might want to keep an eye on the blog for the next few weeks!

The circuit menu has finally taken a bit more shape in form of actual code. We sketched out the basic outline of the tree that contains the skills so we can easily create the tree itself whilst changes can be added with ease. As you might have seen in our previous post, we use a tree structure combined with so-called OR-branches. Along with this, we discussed the data structure we want to use for a single skill. We tried to make it as flexible as possible so we can make changes fast. The coming weeks will probably contain lots of information regarding the skill tree and the creation of the circuit menu.


A week of non-stop CrossCode Action? Developing until we fall asleep in front of our laptops? This is what we’re currently planning to do! A part of our Team will meet up to work together on CrossCode for a whole week. We hope that we can squeeze out more content for the game in that week, so we can proudly present it to you in the next update!

And this is where the weekly ends. We hope you enjoyed the weekly and will be here in 2 weeks to get a fresh batch of CrossCode Updates!

Until then!

In Germany it’s already the 10th February, which means Intero leveled up! We wish our composer the best and hope that he will continue bringing awesome music to CrossCode. Happy Birthday Intero!

CrossCode – How to GUI System

Hello and welcome to another technical post!

This time we want to talk about the GUI-System in CrossCode! Some people have asked us how we draw GUI elements and how we handle animations and all. Well today we gonna answer these questions… hopefully!


Before we actually created a GUI system, we talked about what we want from it. It was clear that we needed a more sophisticated system since we wanted a menu that comes with lots of animations, scroll panels and also a way to handle navigation. Why Navigation? Because there are actually 3 different ways to control the menu (We don’t go into detail about controlling in our GUI system, but we can make a separate post if you like!).
First, we have the mouse. This means buttons can be focused, unfocused, pressed, hovered and so on. Secondly you can use the keyboard to maneuver through menus. This requires a way to handle groups of buttons you can go through and optional buttons that can be accessed via hotkeys. The same goes for the third option which is the gamepad.
For handling the GUI elements themselves we decided on a tree structure. This means that every GUI element can have a (possible) infinite number of children, which in turn can also have an infinite number of children.
Check out this this image to get a picture of it:

Pretty simple right? It was one of the goals to keep it simple whenever possible. There are not complex layout systems or anything. So, before we start talking about handling GUI elements, let us take a look and the outline of each GUI element.

The GUI Element

Every GUI element in our engine derives from a base class. This class contains information about the position/rotation/scaling, the animation state and etc., the GUI Manager (which we get to in a bit) needs to display the elements. The structure looks something like this (beware: pseudo-code incoming!):

These are the basic parameters and functions required for our system to work. As you can see there are quite a lot of parameters. Let’s get a quick overview about what each parameter stands for:

  • pos: the position of the element relative to it’s parent and the given alignment.
  • size: the size of the element in pixel.
  • pivot: the point around which to rotate.
  • align: the alignment relative to it’s parent.
  • children: array for all children this element contains.
  • zIndex: virtual z axis for deciding in which order the top level elements are displayed.
  • mouseOver: true if the mouse hovers over this element.
  • clip: true if this element should ‘clip’ to the size. This means that children are only visible in the rectangle of this element.
  • updatePause: true if this element should be updated even when not visible.
  • transitions: contains all transitions the element has (subclasses can override this). Each possible state has the following parameters:
    • state: the state to transition to (contains a subset of currentState).
    • time: transition time TO this state in seconds
    • timeFunction: The bezier curve to use (We call them Key Splines here).
  • currentState: the current state the element is in. This contains offsets to the current position, the alpha (transparency) value, the scaling and the angle.
  • currentStateName: the name of the current state.
  • animState: the animation state if any. Used when easing between 2 states. It contains a timer, maxTime (the time the transition takes) and the time function to use.
  • update: called by the manager to update the element.
  • draw: called by the manager to draw the element.
  • doStateTransition: can be called to invoke a transition. The transition is handled by the manager.

Most of these parameters and methods are actually handled by our GUI manager. And that’s why we will now talk about the manager class.

GUI manager – Update

The GUI manager is what brings each GUI element to life by updating it’s state and calling the update and draw methods for each frame. The manager in turn is called every frame by the game. So, let’s go through the different steps the GUI Manager goes through on every frame.

First, every element needs to be updated. As stated above, the top level GUI elements are added to the manager and serve as a starting point. Each top level element can have a Z-Index value to determine in which order the top level elements should be updated and drawn. We do this by simply sorting all elements with the sort method JavaScript provides:

This simply makes sure that the element with the highest value is updated and drawn last. After this we walk through each element and it’s children recursively. However there are some steps we do to update each element:

  1. check if GUI element is visible
  2. update the state of the element (only if it’s visible, except when pauseUpdate is true)
  3. set mouseOver to true if the mouse if over the element
  4. call the update method of the element (only if it’s visible, except when pauseUpdate is true)
  5. do the same for all children

The pauseUpdate property is mostly used for the HUD, which needs to be updated even when not visible (e.g. to update the stats in the element selection view when leveling up).
Every calculation includes the current position, size, scale, rotation and clipping of the element and passes these information onto it’s children. This might seem a bit over the top but it makes sure that you can’t hover over a button when it’s parent is not visible for instance. Also we directly skip every child of the parent if it is not visible and the updatePause parameter is false. Code-wise it looks something like this:

Of course the actual code is bit more bloated with calculations but it should give you a basic idea on what we are doing.
Also the checkIfElementIsVisible method takes an animation between states into account, to make sure we can animate a state from invisible to visible.

To animate the states we simply do the old interpolation between values trick. When setting a new state to transition to, we set the initState to the current state and the targetState to the wanted state. Additionally we set the time the transition should take as maxTime and a timeFunction used for the ‘tweening’. After this we update the timer and divide it by the given maxTime. We then use bezier curves, which we set as timeFunction, to tween the result and interpolate between the target value and the initial value. This sounds pretty complicated but let’s have a look at the code:

This is the gist of our “animation system” for GUI elements. By now some of you might notice what we’re actually doing here. We basically copied the same system CSS uses. Each element has a state and we can define a new state by simply telling the system the properties of the new state. Without any extra effort the system eases between the states to create a smooth and nice animation!
By the way, we use the same system for easing between positions! We have a target and initial position and interpolate between them to create movement animations!

GUI Manager – Draw

Now you might ask yourself: “Okay, and how does this look? Where is all the graphical stuff?”. That’s where we are going now. As with the update method we first check if the element is visible or not. If not, skip this element and all its children. Because, why drawing something that is not there, right? The fun starts when the element is visible. To translate the position, scale or rotate the GUI, we use the context which we get from the canvas we’re drawing on. The context basically provides us with methods and properties to draw graphics or primitives on the canvas. Next to this, the context has some neat functions to manipulate the position, scale, rotation and so on.
So we take the position of the element and feed them to the context. Since we always take the values from the current state, we can easily archive animations just by transforming the canvas to the elements properties. The transform will be taken over to the children, so every context manipulation to the parent is also reflected in the child elements. This picture here shows how this could look:

Pretty cool, huh? And the code for this is actually really simple. The following also includes how we do the clipping, which makes sure that nothing is drawn outside of an element’s rectangle:

Note that on the first visit of the method, we actually have no parent since we are traversing the top level elements. When translating, we first get the position of the GUI element based on the parent’s position (0 if no parent is there) and the alignment (as stated in the definition of the base GUI class). Since we can “right/bottom”- or “center”-align elements, we need to position them correctly on the canvas. That’s what the getX() and getY() methods do.

But wait… something is missing, right? Where do the actual graphics come from? Well…

Drawing Graphics

Each subclass of a GUI element draws it’s contents before each children. For drawing these elements we use the Image class provided by impact.js. Since transformation is handled by the GUI manager, we simply draw portions of an image on the canvas using the Image’s draw function. Let’s go through a simple example of a button. We assume the following image is our button-asset:

And we have a button-class that looks like this:

This would result in something like this (assuming the button is a top level element):

Now this seems okay, right? We set the position to [20,20] and it was drawn correctly. But there is a problem: Scaling. A lot of GUI elements in CrossCode can have different widths and heights. We can’t simply stretch them with the state scaling, that would look a bit strange, right? To make this happen we added NinePatches to the engine. These allow us to define 9 areas of which a drawable piece is made of. The edges are drawn normally while the top, left, right, bottom and center pieces are stretched to the size of the GUI element. So this asset:
turned into this:

This also means our button-class changes. We swap the Image class with our new NinePatch class which creates an image, too, but also takes extra parameters to determine how to draw the “box” using the nine “patches”: (If you’re interested in a technical post about NinePatches, give us a quick comment!)

To give you a better picture of what the NinePatch does, the following image shows how the button-asset is “tiled”. Next to the button-asset is another box-asset that demonstrates how the NinePatch would divide a normal box into 9 pieces:

As you can see the button-asset is actually only split into 3 parts. This is done since we only need to fill the horizontal space when setting the size. The height always stays the same. But the right asset, as you can see above, is a box that can be stretched into each direction. It is just a small example to show you what the NinePatch can do.

All of these features are used to draw all the GUI elements. Even the text is just a GUI element that draws a number of characters. We extended the basic font-class to be able to draw icons too and we optimized it so it would pre-draw the text on a canvas which saves a huge amount of draw calls, especially in the menu.
This means that this:

…is nothing more than a collection of different elements drawn on the screen one after another using the Image or NinePatch class. Lots of the elements are just boxes that are stretched across the screen. Of course, not everything is as easy as it seems. As you might imagine, some GUI elements need a lot of padding and adjustment to look and feel just right.

Not that we didn’t cover every inch of the GUI system here, but we wanted to give you an idea of how our system works, how we animate and draw the graphics. We will talk more about the optimization of some features and aspects of the GUI system in an upcoming post. Like the fact that the BaseGUIElement properties are actually stored in another object. But to keep it simple, we decided to show it to you the way we started it.

Phew… well that was one hell of a post. We hope you enjoyed this (really) long technical post about our GUI system. If you have any specific questions about the system or another aspect of CrossCode, do not hesitate to ask! We are happy about every comment :)

Have a nice day and see you on the next CrossCode update!

CrossCode Update #41 – Circuit menu, messy cabins, snowballs and more

Hi again!

First, in case you are confused: we decided to rename our Weekly Update into CrossCode Update because of the lack of an actual weekly schedule.
But don’t worry: This doesn’t mean we’ll post updates whenever we feel like it. The bi-weekly schedule seems to work out fine so far, so we’ll stick with it.

Anyway! What’s in for this update? Lots of stuff, in fact! We went ahead and started with a major goal of our next milestone: the circuit menu (formerly known as the talent tree). On top of that, we have a lot of graphical improvements, sound and music!

The new Circuit Menu

We talked about the talent system in CrossCode before.
First big change: we renamed it to Circuit Menu. Has a more futuristic sound to it, right?

We started with planning out the layout and control patterns of the circuit menu. We all had very similar ideas, so we found an agreement very quickly.
However, before starting with the implementation, I first wanted to integrate several optimizations in our GUI systems. Those were very similar to the optimizations we had for the entities and the collision engine as mentioned in this update… and they worked again! And for all of you who are still waiting for a more detailed article about these optimizations: we did not forget it and will post it let’s say… sometime in February!

With these optimizations done, the next step was to create graphics for the interface. I finished this just about yesterday. And here comes a first mock-up for our new circuit menu!

Let’s start with the overview:

Here the player can select one of the five circuits for further inspection (neutral in the center and clockwise around it: cold, shock, heat and wave). On the lower left you see available CP (Circuit Points) for each circuit. Those are used to activate the nodes (i.e. learn the skills) of each circuit. Note how activated nodes are already highlighted in the circuit overview! (That will be fun to implement. Good thing I won’t have to do it, right R.D.? :P). As for the “swap branches” option… we’ll probably talk about that in another update.

Now let’s zoom in into one of the circuits:


First what is missing: Icons are obviously incomplete. Even the existing icons might change (in fact GFluegel is already working on that). Also, the whole tree structure is more for graphical testing. That being said, we like how the result turned out, with that circuit pattern in the background and all.

Finally, here is how you can interact with a circuit node:


The description will most likely appear whenever you hover a node with the cursor. Once you click it you can choose an option on how to interact with it. It’s more or less what you’d expect.

With all the graphics prepared, it’s now up to R.D. to implement the menu.

Pictures and Sounds!

T-Free was working pretty hard since the start of this year. He completed all the effects for the cold element mode. You could see some of the effects already in our Recap 2013 video.
Anyway, have a gif:


In addition, T-Free also added some nice wave animations for the cargo ship:


On another end, TQ and R.D. further improved the cabins environment of the cargo ship:


Seriously, look at all those details!

On the sound side, we have Teflo who recently contributed new menu sounds, e.g. for the equipment menu. Even though we’re still fine-tuning these sounds, they already help to make the equipment of items a much more satisfying experience.

Finally, our composer Intero continued working on the BGM for the outside of the cargo ship. He already created an initial version, which matches the mood perfectly! Maybe we’ll release another preview in a following update. :D

And… that’s all for this update! Overall, it’s a fairly good start for this year – especially considering we had to struggle with several study-related deadlines during the past weeks.

Otherwise, you can look forward to another technical article about our menu system that we’ll post during the next two weeks.
Until then!

CrossCode Recap 2013

It’s finally time for the great recap of all the things happened in 2013!

CrossCode has come a long way. Thanks to all the help and the great feedback we managed to push CrossCode quite a bit. Since the TechDemo, CrossCode has changed a lot. And today we present these changes to you in the form of a video! This video will cover the biggest changes we made to the game, all commentated by our composer Intero!

So… less talking more watching!

A quick heads up: creating such videos is a new experience for us, but we still hope you enjoy the result! We learned a lot from making it, so expect better quality next time.
Also, in case you find the hit sounds a bit strange at parts: yeah, that’s a bug. We’ll fix it soon!

Also, let’s summarize all the new stuff with text too!

CrossCode now has real cutscenes, which are mostly presented via dialogues and various animations. The characters in the dialogues are portrayed with facial expressions. We aim to always make the appropriate expressions for any given situation, so you can expect lots of them! Also characters might talk to you via the new side message system which is displayed at the lower left of the screen. Since these run in real time while you run around bashing enemies, you can also check out a list of the last 50 messages in the pause menu.

What is a RPG without NPCs to interact with? …Right! CrossCode now has them too! You will able to talk to a lot of NPCs while playing the game. But we don’t want NPCs to be just mere decoration, topped with some text. NPCs will mostly have something interesting to say and maybe also have a quest for you. We also plan a different kind of dialogue system with NPCs, which will hopefully make NPCs and the dialogues feel and look even better.

The TechDemo really had no story whatsoever. But this changed completely. Cutscenes are a big part of our development and they are coming along nicely. We spent a lot time on them to make them just the way we want them. This is mainly because we don’t only want to deliver fluent gameplay but also a good story that keeps you entertained.

Just like a classical RPG, CrossCode also has a classical menu, which you can access anytime outside of a battle or a cutscene. Here you can look up your items, change the equipment (which is also the only menu that is basically finished), level your skills, look up information or change game options. The goal here is to create a visually appealing and yet easily accessible menu. Especially if you want to quickly look up things you don’t want to meddle with bulky and slow menus.

Let’s dive into some combat-related features!

In the TechDemo you could not attack enemies on close range. Well you could, but you would take a large risk. With the new close combat attacks you can not only attack enemies close-up but also hit multiple enemies at once! You are still in the risk of being hit from the back but you have a bigger chance to survive in a fight against a large number of foes. It also gives you more “mix-up” options to approach enemies.

Sometimes you can’t counter an attack and dashing always would put you in a bad situation (like an enemy attacks with an “area of effect”-attack). This is why we added guarding. Guarding will reduce the damage you take by a lot but only if you guard the attack in the right direction. If an enemy attacks you from behind, you will receive the full damage.

To make the combat more interesting we added the so-called Element Modes. Each mode will make you more resistant to the corresponding element and grand you special abilities only available in the specific element mode. Each element mode will also have special use in combat. Heat is a aggressive close ranged element, while Cold is a defensive element. Shock is for risky fast paced attacks and dodges, while Wave is for backing up, healing and trying to figure out a strategy. Of course CrossCode will feature enemies that use one or more elements, too. There might even be enemies that require you to switch through 2 elements or more to fight them effectively. Element Modes will also have special properties for solving puzzles in the game.

To make combat even more fun, we added battle techs. Battle Techs are skills that are executed by holding down the charge button and releasing it. While charging, time will slow down, which gives you a bit of time to think about your next step. Which Battle Tech is executed depends on the action you’re currently doing and how long you hold the charge buttons. The actions are throwing, attacking with close combat, dashing or guarding. Each Battle Tech will consume 1 or more of your SP, so you can’t just throw them out but have to use them wisely in the combat. You can easily regenerate SP by just attacking the enemy. Outside of combat your SP will regenerate to a given threshold.

And this sums everything shown in the video…

or wait…

we forgot the greatest news!

Thanks to node-webkit we managed to bring CrossCode to the Desktop! That’s right. CrossCode will also be available on Windows, Linux and Mac. This is pretty new to us, too, so expect more announcements at a later date.

But wait! There is still more!

Not only can we bring CrossCode to the Desktop, we can also bring it to the Wii U! Thanks to Nintendo and the Nintendo Web Framework we can port CrossCode to the Wii U. There is still some stuff to do to make the game run on the Wii U. As you might imagine the Wii U has a specific hardware set and we need to adapt CrossCode to make it more playable and avoid potential problems.

And… that’s it! Now considering the fact, that we only work on CrossCode in our free time, quite a lot of stuff happened. This year, we hope to finally change the pace and work full time on CrossCode. It will be an interesting year for Radical Fish Games and we hope that we can continue to show you our progress every second week. We have great things in store and a demo in work. So stay tuned for an awesome year, full of CrossCode-Action!

Until next time!

Mega Ninja Hobo Connoisseur

It’s time for some 8-Bit Action!

Over the holidays we were cramped together in a small room so we thought: “HEY! Why don’t we make a Gameboy version of Ninja Hobo Connoisseur?”.
Long story short: We did it and today we gonna release this epic version of Ninja Hobo Connoisseur under the title:

Mega Ninja Hobo Connoisseur

kickass-winetasting-8bit(You can click on the the image to get right to the game!)

So what did we change? Quite a lot:

  • All graphics redone with 4 colors
  • Remixed Soundtrack by Intero and recorded with a real Gameboy by TQ
  • Small effect changes (no transparency on the Gameboy)
  • Changed the resolution to 320×244 which is twice the size of the original gameboy resolution
  • Gameplay and map changes

So get ready for some 8-Bit Ninja Action! Click the Link below and try to be the fastest.

Click on Me!

If you want to listen to the soundtrack on its own, check out Interos SoundCloud Profile here: Mega Ninja Hobo Connoisseur OST

Have fun with this little holiday project!

Until next week!