CrossCode Update #49 – Action cutscenes, saving and more

We’re back with another update!

Since last time we have extended the plot with our very first action cutscenes (also featuring a new character), implemented a first prototype of the save system, worked on a concept for the new map menu, create first graphics for new enemies and more! Also, connected to that was a lot of engine work and a very successful application of effing MATH.

A new challenger appears!

The story of CrossCode continues and here is a first preview of what’s to come:

designer-appears

designer-dialog0

Not only did we add this new character (nope, no more information on this guy :P), I also added a couple of new features to create those new fast-paced cutscenes. Firstly, I implemented a zoom feature to get the view closer to the action. We will not only use this in cutscenes but also in certain gameplay situations.

Secondly, I dramatically improved the whole floating physics of the game, harnessing the full potential of (basic) math! Well… You see, floating physics have been around for quite some time, but they have always been kinda hacked. I tweaked values around, adapting the acceleration of the z velocity in strange ways to make it work for specific use cases – and this always broke later on when new use cases emerged. So, after realizing this doesn’t go anywhere I finally sat down, remembered the math I had years ago, did all the derivatives, solved integrals like a boss and finally found the one solution… that worked instantly!!

… Okay, sorry if I’m derailing a bit here, but man, that was one awesome math moment for me. I’d also be happy to share my findings if people are interested *hint* *hint*.

Anyway, floating now works perfectly fine for all the use cases! Alright… more actual content now.

Save Menu Prototype and Map Menu Concept

CrossCode will be an Action RPG with at least 10 hours of play time. Of course you’ll need to be able to save your progress. So it’s about time we add a proper save menu to the game. I spent a little time, polishing the already existing save system e.g. to properly store the currently played music. R.D. then extended the system to support multiple save slots. Then, he went on and created a very “simple” save menu for debugging purpose:

save-menu-debug

… He keeps insisting that this was no work whatsoever.

Anyway, remember that this is only a first prototype which is used for development (saving is such a great feature for testing). The actual save menu will probably look much better. And we will do it soon.

We made even more progress with the menu. The next big thing will be the map menu which provides an overview over the current area as well as the whole world map.

After R.D. did a first layout proposal, I followed with an initial design concept:

map-concept-1

R.D. already started working on the implementation, so hopefully we’ll have some actual running map menu sometime soon (though it will be more work than the item menu).

Some other internal stuff, also done by R.D., was a refactoring of the buff structures and the implementation of an item editor, used to edit the item definitions of CrossCode (there will be plenty of items, yes). Here’s a screen cap of the item editor:
item-menu (If you’re interested in a technical about this too, leave us a comment!)

Graphics and Music

Our new grinding area needs new enemies! T-Free started working on the graphics. They look like this:

HedgehogRun
MeerkatAppear

… AWWWW, AREN’T THEY JUST INCREDIBLY CUTE??? ^////^

Surely you can’t wait to brutally beat them down with balls.

*cough*

Then we have Teekuh who added more graphics to the grinding area, such as this amazing tree:

amazing-tree

Also, Frece is producing a crapload of concept art. No seriously, we could just post at least 6 images here, but we’d be terribly spoiling things. So here have another concept art of the grinding area featuring some new buildings we still plan to add:

autumn2

And finally, Intero is working on the soundtrack. Being the perfectionist he is, he’s currently remixing several old tracks. The new versions do sound really nice, though!

So, plenty of stuff going on.

Until next time, fellas!

MATH

Okay, okay! I’ll stop. :P

20 Comments

  • Great update as allways :D
    One question about the map. Does the map show the different layer the player can be? I mean the container and so where you can jump on.
    The other thing I’m pretty interested in is the floating physics you mentioned, i would be glad to read something more about it ^^

    • Hi there!
      The map display will be very simplified and only show the rough bounds of each room. If a room is high enough, it might expand over several levels, but otherwise you won’t be able to see all the detailed platforms of each level.
      Rather than having a detailed map for assistance, we should make sure that the level design is clear enough so people can see the actual height of things (and the puzzle challenge in the TechDemo++ was a failed attempt at that).

      Yeah. I think I might squeeze in a short article about the floating physics soon. :D

  • Holy shit! This game looks better and better with every update!

    I wanted to personally thank you for this last image. It made my laugh for about 1 minute and saved my morning!

    I just cannot figure out what you mean with “floating physics”. But once I do, I’d be extremely interested in the math stuff. Because of, well, see your last image…

    Applied math is just empowering! ;-)

    • Hi there!

      Yes, yes. Math ftw!

      With floating physics I mean the manipulation of the z acceleration in a way to make the entity float/hover a certain height over the ground. The challenge is to set the acceleration in a way to make the entity smoothly hit the desired height without abruptly stopping. And math really helps a lot to find this acceleration.

      So yeah, I’ll write a small article about that soon. :D

  • Very interesting, we have a NodeJS server for editing all of our items hooked up to MongoDB. Also we use a micro-framework JS library I wrote for linking data IDs (you might find it useful). http://ashblue.github.io/slot/

    Also I was inspired by your animation editor I saw earlier to role an open source lib for our game. Check it out here and let me know what you think http://ashblue.github.io/sprite-animator/#/

    • Hey,

      we actually have a generic json editor we could use to edit items too, much as you do. But the problem is that this gets kinda fuzzy to watch at. There is a lot of data and information and it’s all in one big list. Also you can easily append unwanted data and there was no clear separation for the different types of items.
      Now with the editor for each type, we can hide/show different views that match the item type. This makes it easier to only add the data you need for the type. It also allows for a nice overview, since you don’t have one big list, but multiple ones separated by type. Especially adding and removing modifiers from equipment or adding the properties to the new buff system is so much easier. As said we could show some more of this if people want to see it :)
      But I do like the slot view of you lib. It reminds me of our own json editor :D

      Woa really? we inspired you? That’s great to hear/read! It looks a lot more polished then ours to be honest. I also seems to work pretty much like ours minus the feature to create entities for different parts of the body. We do this for the crab boss. So there are multiple entities working together. But I don’t know it this is useful for you (or for a open source tool in general).

      • Heyo,

        Good feedback on the JSON editor you’re using. We decided on the DB solution because we have a lot of data we’re moving around because of the branching storyline nature of our game. MongoDB is really just a massive JSON file on the backend too (kind of doing the same thing).

        I like the idea of multiple entities working together, was thinking of adding a hitbox generation tool of some sort that attaches to an entity file. Will probably be doing a revision on the tool in August after we have a video up of our newly animated environments.

  • KazeMemaryu on June 24, 2014 at 4:26 pm said:

    Congrats on mastering MATH!

    By the way: does Frece work on his own or with the team’s input and ideas? Cause it would be nice to have a few wallpapers at some point (hopefully I don’t sound demanding).

    Also, that mole is awesome!

    Keep at it! I love your stuff!

    • Whenever Frece is about to draw something we usually discuss the content together, what kind of elements should be seen, colors, what kind of atmosphere we want to achieve etc. Usually Frece tries to show early results to get further input from the team.

      I don’t quite understand how this questions relates to wallpapers. :D We plan to create some clean Artwork for CrossCode that can be used as a wallpaper, eventually.

      • KazeMemaryu on June 28, 2014 at 10:38 pm said:

        Haha, I just wondered if he “applied” with some character work that would pass for wallpapers. ^_^

        Well, keep rocking!

  • Thinking about the zoom effect (that looks really cool!), I wonder why you don’t use WebGL to render your frames. I guess you could reduce the paining operation by A LOT if you do so.

    Is it because right now, you still have available time per frame, even in heavy loaded scenes?

    I always remember this cool presentation when thinking about performance gains in drawing 2D images:

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

    ;-)

    • Hey there.
      WebGL is definitely an option to optimize the drawing, but there are two reasons why we don’t do it right now.
      1. WebGL is not available everywhere yet (especially not on the Wii U)
      2. Implementing the rendering in WebGL is not that trivial if you want to have it fast.

      While the potential for WebGL is much higher it is also much closer to the hardware and there is plenty of things you can do wrong. If you want to actually increase performance, you’ll need to reduce your glDraw calls by combining the rendering of multiple sprites, which in turn might need to access multiple textures, which is again expensive.
      And that’s just one example.

      About 2 years ago I attended a talk from some Google employee about WebGL performance and he described some of the challenges when rendering 2D sprites with WebGL. He showed that going for the most trivial solution with WebGL actually resulted in slower performance compares to canvas2D, for reasons such as accessing multiple textures in if condition branches.

      In my opinion, a more viable option would be the use of a WebGL based 2D render engines, such as pixi.js.

      Anyway: Canvas2D performance is fast enough for CrossCode and I’d rather wait with WebGL for the next Project. :D

      • So, in short, you mean that offloading data (textures, buffers) to the GPU (the wrong way) might be the actual bottleneck, that is not necessarily compensated with the speed improvement by the actual computation on this data?

        I wonder if this is a problem only with WebGL, or with general OpenGL implementations as well.

        You made me curious about the Wii U thing: How exactly is the Wii U able to execute JavaScript? Is the some sort of interpreter for it? Or even a compiler?

        Cheers!

        • It’s exactly the same with OpenGL.
          It’s low level, therefore powerful but also more difficult to use.
          You also shouldn’t forget that canvas2D is hardware optimized as well – it’s just more limited in it’s possibilities.

          You can execute HTML5 games on the Wii U via the Nintendo Web Framework which was release end of last year. It’s essentially a Webkit based wrapper for your HTML5 application that can run on the Wii U. Even the development tools are similar to a Safari/Chrome Browser. As far as I can tell, JavaScript is interpreted and probably optimized as in modern browsers (e.g. JIT compiled), but as far as I can tell the performance doesn’t seem to be on par with V8 (unfortunately).

          • Ah, I see, Canvas2D actually can use hardware acceleration to draw and even linearly transform 2d sprites. And since many of your draw calls are sprites, this may already reduce the drawing time significantly.

            Did you already make some tests on a real Wii U?

        • Well… we did test the game on a Wii U Devkit, which is pretty close to an actual Wii U… I think.

          You can see the result at the end of our 2013 recap:
          https://www.youtube.com/watch?v=gSI0Ssbub1E

          • As far as I can tell, it runs pretty smooth!
            I would clearly prefer to play it on my Wii U! :)

  • Moooooreeeeee on June 29, 2014 at 12:17 pm said:

    Hey. You’re doing great job with the game, but I want to play the content, so when will the next version come out?

    • We will release the first real demo at the end of this year (hopefully).

      It sounds like you didn’t play the TechDemo, so I leave you a link to our proof-of-concept TechDemo. This way you can play CrossCode right away! (At least a small part of it)

      TechDemo: Play It!

One Trackback

Post a Comment

Your email is kept private. Required fields are marked *