top of page
___________________________________________________________
About:
This was the third game I made during my time on The Game Assembly and the first project we worked on in The Game Assembly's own In-house engine.
The player takes control of a little dragon that both shoots fireballs, and carries the unusual ability to inhale enemies and spit them out as special projectiles. You move through levels defeating waves of enemies and avoiding environmental hazards. The game features a mix of "Bullet Hell" styled combat and more "thread the needle" moments where you'll have to fly through narrow spaces inbetween floating islands.
The combat consists mostly of holding down the firingbutton, but to vary the combat we also added the ability for the player to get up close and inhale an enemy and hold them in their mouth and spit them out on comand. Each enemy comes with some extra offensive effects, making them act kind of like special attacks. One enemy might just act as a "bowling ball" barreling through enemies, whereas another one shoots out as a kind of "shotgun blast."
The game has five levels and six bosses to battle through.
Story:
A dark pressence is corrupting the inhabitants of the peaceful forests into ravenous beasts. Help this little dragon in his quest to find the source of the corruption and stop it.
Specifics:
-
Development time: 7 weeks part time
-
Engine: TGA2D
-
Genre: Sidescrolling Shoot-em-up
My Contribution:
For this project, the way we set up the editor and SVN pipeline, allowed us to work on 10-second long segments in each level, meaning multiple designers could work on the same level simultaniously. Because of this, all of our work kind of blends together throughout the entire game. Very few parts of the game "belongs" to a single designer.
The majority of my work was on Level 2, the first half of Level3, Level 5 and I designed the different stages and attacks of The Final Boss battle. I mainly focused on the more "environmental hazard"-heavy parts in each level and created challenges based around these.
We had a "prefab system" which allowed us to design unique enemy patterns that we could re-use throughout different levels, or to more quickly set up complex enemy patterns. All of us made large numbers of these "prefabs" so we easily could throw them together into interesting waves.
Credits:
Programming: Tobias Grönvall - Albin Engström - Hugo Rogmark - Casper Stein
Graphic Design: Lisa Fors - Alice Patel - Sanna Fridberg
Animation: Fei Berg Hulthèn - August Wahlberg
Level Design: Emil Maris - Alexander Sandén - Marcus Tegerhult
Process
"How do we make the levels?"
Once we'd settled on our main mechanic and our enemies, we needed to figure out how we level designers would be able to acctually create the levels in the game, as this was the first game we did outside of Unity. For this project we where making the game in TGAs in-house engine "TGA2D," which doesn't have a native editor for us to use. While there where alternatives we could hook up, like "Tiled", we felt that these weren't optimal for this type of game. Luckily, one of our programmers was very interested in creating his own editor for us to use, and offered to take the role of setting it up for us, meaning we hade some ability to tailor it into something more optimal for working with this genre of games.
Our biggest concerns were source control issues brought on by multiple designers working on the same level without source-control conflicts, an easy way to design enemy patterns and waves, as well as the ability to easily re-arrange large chunks of enemies if we felt they belonged either somewhere else on the level, or in another level entirely.
The editor worked like this:
-Every level is split up into multiple chunks of "10 seconds of gameplay"
-Each of these 10 seconds makes up a separate file located in a folder. This allows multiple leveldesigners to work on the same level without causing conflicts in SVN and allows us to easily re-arrange segments.
-You could save patterns as "prefabs" that anyone could easily drag-and-drop into a scene.
-By pressing F6 you could toggle between the editor and the game, so you could easily try all changes you made on the fly. When toggled, the player will start from the time designated in the editor.
-Enemies are placed through a radial menu and can then have their travel pattern edited, and given designated times to shoot, giving us level designer a lot of control over all enemywaves.
This is how the editor looked. The lines running across the screen are the different enemypatterns. At the bottom of the screen there's a timeline showing the titles of the "segments." Most interactions where done through a menu you could bring up with the right mouse button.
Designing for a SHMUP
We started by playing different types of shooter in order to figure out what aspects we enjoyed the most. The main game we used as a reference was "SINE MORA." The game had a good mix how bullet-hell combat and environmental challenges we enjoyed. Early on we decided that this was the balance we wanted to strike.
When doing paperdesign we would look at patterns we enjoyed navigating and then breaking these down into a few different archetypes that we could easily reference. Enemies that move in a "wave" pattern we'd refer to as "wave motions" and so on, which allowed us to more easily communicate what we wanted in a particular segment.
When planning for levels we made flowcharts in order to figure out the pacing and the different gameplaybeats. They would be simple but allowed us an easy overview of the entire game and, at least on paper, space out the challenges so we had a good startingpoint when we started working.
An example of a flowchart. Of course, over the course of development most of the pacing ended up changing due to itteration after playtesting. Most of the design was done by playing, seeing what was fun and then modifying the levels accordingly. The gameflow might've started of looking one way on paper, but ended up being completely different in the final product as it is difficult to know what's going to feel fun to play, especialy in these types of games.
Bosses
One of the big mistakes we made during development was leaving the bosses for last. While we talked about wanting one at the end of each level, we never really talked about how we would go about making them. We ended up making a branch of the leveleditor that allowed you to design boss movement and their attack patterns by moving bullets in a similar way we would move enemies. This came with a lot of issues, since the editorfiles quickly became cluttered, unreadable and slow. I personally only worked on the final boss in the game, since the level designer that decided to redirect his focus on the bosses for the final two weeks, ran into a lot of issues with this workflow and didn't have time to finish the last boss of the game. While it became a massive pain to work this way, we managed to get it together and ship with all bosses functional.
bottom of page