Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

Advanced search

1368213 Posts in 64213 Topics- by 56155 Members - Latest Member: Filipe Ferreira

October 23, 2019, 11:43:30 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsAvengers: Global Chaos: Flash and Unity project
Pages: [1]
Author Topic: Avengers: Global Chaos: Flash and Unity project  (Read 6066 times)
Level 0

View Profile WWW
« on: June 25, 2015, 01:04:31 AM »

Note: This project was completely a while ago but it took a while for me to get an okay from to post about the development of this project. Its a pitty that it was done as a flash game in a time when the platform lost its glory. But I hope that you enjoy this write up and screenshot collection of behind the scenes as I think there are several unique techniques and ideas used for the development that I haven't come across myself before elsewhere.

Avengers: Age Of Ultron – Global Chaos is a puzzle/action platformer available online at: www.globalchaos.marveluniverse.com.au. This project turned out to be rather ambitious, which is why we want to share some behind-the-scenes info.

Development on Global Chaos lasted roughly two to three months and involved four people, almost the same team that worked on Gangster Squad, another ambitious Flash game Soap developed two years ago.

The game was built using the Starling framework. Nape physics was used for the engine, and Dragon Bones for the character animations. For the levels we used the Unity Editor that allowed us to export the levels into AS3 code, that would then compile into the game engine.
A special build of ShoeBox repacked Dragon Bones and level sprites into master sprite sheets.

The game features 13 Levels, 13 unique enemies, over 240 sounds effects, more than 170 lines of dialogue and about 250 painted sprites.


Soap initially pitched an idea to Marvel and V-Energy based on two Soap properties:  Wolverine M.R.D. Escape and Tokyo Fury. Unlike these previous games, Global Chaos would feature four heroes from the upcoming Avengers movie as playable characters, and the gameplay would be divided between solving puzzles, battling enemies and exploring the levels.

Early on in development we locked down some of the game’s elements: 12+ levels, enemy designs, boss battles and various level obstacles. Each of the Avengers were supposed to have special abilities that would allow them to overcome certain challenges throughout the levels. We also planned to have a single interaction key that would manipulate elements of the environment, such as doors, elevators and security systems.


The game features four playable heroes: Captain America, Iron Man, Thor and Hulk. In the beginning we planned to have dynamic rim lighting for each character, but this idea was scrapped due to technical difficulties.

The roster of enemies consists of Ultron Sentries, Hydra Guards, and a range of drones, cameras and turrets themed around Hydra and Stark Industries. The game also features three bosses – Ultron Prime, the villain Taskmaster, and the head of Hydra Baron Strucker.

For some enemies we prepared special chunk sprites so that the units could explode into smaller pieces from their standard animation state.


All environment sprites were painted at two to three times the resolution compared to their final size. Since the perspective effect is only achieved within the engine, mockups like these were drawn in such a way that they would show the front and side pieces of an element.

For the Avengers Tower levels we wanted to have lots of lights, transparent materials and reflective surfaces. Cameras and security systems were designed to fit within the theme.

The St James Station levels have a brown color palette and a large tiling texture to fill the edges around the map.

As a special render pass in the engine we used light brushes to give the levels an atmospheric look. All brushes were saved as white sprites so they could be tinted using vertex colors in the engine.

Inside the engine a combination of two blend modes blend the light into the environment.


We used Dragon Bones to animate inside Flash, but exported the animations to a GPU-friendly set of textures and skeleton files. One of the many advantages of this method is that it allowed us to blend any animation clip with another, with the results displaying at a smooth 60 fps.

When preparing the animation rigs we noticed that tracing the painted characters as vector graphics made them easier to manage inside Flash. For example, when there was a need to apply additional volume to body parts to assist with animation, we could simply paint inside Flash using vector brushes.

For the engine we placed events on a timeline combined with labels to trigger animations and scripts that wait for an event before continuing certain elements. This allowed us to sync footstep sound effects with character walking animations, and made it easy to link the release of Captain America’s shield to the exact frame of the animation that fires the event.

Each character has free look controls that override the moving body parts driven by Dragon Bones. This helps to communicate where the player is aiming. For the enemies, we programmed the animations to track the head of the player location, allowing them to dynamically follow the heroes around the screen.

When you put everything together you get very smooth animations that blend nicely when triggering different states. With traditional Flash technology and MovieClips this would not be possible.


Marvel wrote a story synopsis for the game that featured boss battles, humorous moments and plenty of opportunities for puzzles and battles. We used the synopsis to work out level layouts and enemy designs. The synopsis was then developed into character dialogue, which was entered into a spreadsheet.

Custom in-house tools convert the spreadsheet data into C# and AS3 code, making it simple to test dialogue changes quickly inside the game. We placed trigger zones in levels that initiated specific dialogue exchanges. Some lines of the dialogue data are actually commands that instruct the engine to pan to a specific location or end a level.


Before we commenced with level design we created a list of items that we wanted to introduce to the player and use throughout the levels. This gave us a rough idea of level structure, allowing us to block out levels in a very low pixel art style.

A Unity script would then build them into playable levels with the click of a button, allowing for quick iteration of new layout changes.

Once happy with the direction we would start building the real level using path objects, which in turn would be used to create colliders, profiles and 3D surfaces. Next we placed enemies, triggers and prefabs – such as elevators, doors or hackable terminals – throughout the levels. A lot of the complex objects were prefabs that just needed to be dragged into the level.

The last stage involved adding all the additional decoration, lights, and AI nodes.


At the beginning of the project we looked into existing engines for Flash, including a technology developed at Soap for an unreleased game called Ninja-X, and the Citrus Engine, which is built on top of Starling and two physics engines. Neither engine turned out to be suitable for the game’s need. Citrus was initially promising and the first prototypes were built using it, but the framework seemed more targeted to simple games, making it difficult to really modify or change some of the more advanced elements for Global Chaos.

One of the first tests for the engine was to parse level data from Unity and a dynamic trigger system that allows to create doors, moving platforms and switches. After we had a prototype that demonstrated the trigger system we abandoned Citrus Engine as it was not the right fit, focussing instead on developing a system that allowed rendering of 3D elements and custom character handling.

In the end we combined several well-known libraries such as Starling for the framework base, Nape for the physics, Dragon Bones for the character animations, as3libwebp for the texture compressions and SoundAs for the audio manager.

Inside the Unity Editor we were able to place, move and create 3D elements easily. Most elements in the engine are 2D sprites at different parallax depths. For the slopes and 3D faces we used a custom object in Unity that creates a path based slope. Inside Starling we hacked into the sprite rendering classes to support trapezoid distortions of quadrilateral surfaces..

One unique element of the engine is how it separates render passes into layers and composites them into a final result. The Dragon Bone characters are placed like a sandwich between the 3D rendered layers. Additionally there is a light pass that uses two blend modes to create an atmospheric look.

Performance was a big concern as Global Chaos wasn’t always running smoothly on older Apple systems that don’t support certain hardware accelerated features. One optimisation trick was adding Quad Trees that dramatically improved engine speeds in the larger levels.

Beyond that we added support for variable framerates which meant that even when the game slows down to just 15 fps all projectiles and movements still respond as smoothly as they do at 60 fps.

We added a node editor to manage the A.I., using nodes to define the rooms through which enemy bots can travel. To randomize the movement patterns circular volumes for each node location were used.

We used a modified version of the library SoundAs that supports random playback from an array of sounds. The sound file identifiers would have a common prefix like ironman_hit_{1-8}, and every time an event triggered ‘ironman_hit_’ it would pick randomly from eight variations of the sound.

Another modification was to add spatial sound so that sounds from elevators, explosions and guards give the player a sense of their physical location in the world.


The most crucial tool for this project was the level editor – a panel inside Unity that allowed us to convert level data into engine-specific AS3 code, and display or hide specific engine elements.

The triggers can be edited visually and no programming is required to set up events, buttons or certain actions. There are about 12 different trigger types and 6 different actions a trigger can initiate. Through a debug mode in the engine we were able to see the triggersoperate in real-time while playtesting.

The profiles and 3D surfaces were built in Unity with a path editor. A node editor allowed us to place and connect A.I. nodes throughout the levels.

We used a special version of ShoeBox-M for the sprite packing and compression. This new version can read sub-directories and atlases, which it then combines with everything else. Another new feature of ShoeBox-M is the WebP image format. With WebP compression we were able to reduce the PNG file sizes to just 20% of the originals.

Level 0

View Profile WWW
« Reply #1 on: June 26, 2015, 03:50:22 AM »

Great read. Thanks for sharing!

https://itch.io/dx0ne<br />faking gamedev success since 2083
Level 0

South Florida based Animator & Designer

View Profile WWW
« Reply #2 on: June 26, 2015, 11:44:41 AM »

Wow. That was such a great post Hendrik. Thanks so much for sharing it. I didn't know there was a ShoeBox-M. Where can I find it? What are the differences between the regular Shoebox and that one?

South Florida based Animator, Illustrator, Web Designer & Designer. Saving the universe one pixel at a time. http://carlospita.tumblr.com  - http://instagram.com/carlos.pita.art
Level 1

View Profile
« Reply #3 on: June 26, 2015, 12:46:11 PM »

The pixelled levels -> Unity levels is genius!

Level 0

View Profile WWW
« Reply #4 on: June 26, 2015, 02:09:04 PM »

Great post, thanks for sharing! Lots of great info!

Would love to make a game, but where do I find the time?!
Level 1

'allo there

View Profile WWW
« Reply #5 on: July 01, 2015, 12:00:58 AM »

Appreciate the write-up on this, thanks for taking the time to post. With that short of a turn around on the project were you able to do much experimenting from a gameplay side or was the emphasis entirely on assembling gameplay elements known to work well?

Level 0

View Profile WWW
« Reply #6 on: July 01, 2015, 04:40:33 PM »

Appreciate the write-up on this, thanks for taking the time to post. With that short of a turn around on the project were you able to do much experimenting from a gameplay side or was the emphasis entirely on assembling gameplay elements known to work well?

In the beginning of the game design or GDD as we call it (Game design document) we started with a list of obstacles and mechanics in the game that a player would interact with or had to solve. This list was very extensive and had all the typical platformer elements we know today like elevators, switches, timed switches, traps, surveillance cameras, etc.

Before we started however with the level designs we set up some kitchen sink scenarios (I think about 13 or 15 demos) that would demonstrate limits or feasibility on a collection of mechanics, like if it is possible technically, fun to do and or if there are limitations.

Here is a screenshot of a very early stage that shows just some of these kitchen sink scenarios

With these earlier test levels / scenarios we refined mechanics, controls and abilities of the heroes. Several super powers were not even that refined before and so we changed for example the ability of Thor at some point to be able to fly and reach higher elevated areas. Other ideas had to be removed because they did not work out as well and a couple more end bosses didn't make it into the final game.

Some levels were supposed to be more uneven and complex, like the ship level

With changing angled surfaces but it turned that the physics didn't always like angled surfaces with odd results because we didn't have an IK leg system. So we were restricted to make most levels rectilinear and follow even surfaces for the grounds.
Pages: [1]
Jump to:  

Theme orange-lt created by panic