Friking Shark development status

Intro

For the last few years I've been developing Friking Shark, a 3D remake of the classic arcade Flying Shark on my free time. I really love the original game, and I want to make a tribute to their creators. 

It's really hard to build a game from the ground up, and even harder if you try to develop at the same time a game, an engine, a generic widget system for the game editors, and a lot of other things that are interesting and fun but can be seen as overkilling to make an arcade remake.

It is hard, but it is worth the effort.  Each time I want to make a new GUI dialog and relying on the widget framework i got the job done in minutes, or when it takes 4 days to build a new editor from scratch I know I'm working on the right direction.

The game is under heavy development and I'm just a coder with no artistic skills. I need an artist (modelling and texturing) to complete the game in a reasonable time (I'm learning Blender just in case), if you are one and want to help please do not hesitate to contact me. 

Technical info

FS was originally developed for Windows, but after working 2 years in Linux, I decided to make it multi-platform. It will be open sourced soon and I intend to make it GNU if possible.

Used technologies and libraries:

• Language: C++
• Rendering: OpenGL (WinAPI+WGL /XWindows+GLX)
• Audio: OpenAL
• Small JPEG Decoder Library v0.93b by Rich Geldreich
• No engine and no other library is being used, everything else is handmade.

Important Features

• Staged Rendering (queueing and reordering of the rendering operations to draw the scene faster)
• Shadow mapping.
• Shader support with semi-automatic shader instance generation based on pre-compiler definitions to speed up state changes.
• BSP generation and execution.
• Quite complete Widget system (with label, button, edit, lists, common dialogs, layouts, focus and input control, z-order, modal dialogs, etc ...)
• Fully Interface and Class Factory based.
• Insanely modular for a game of this size (yep, I must admit it). 

Scenario Editor

The scenario editor is used to create the FS levels.

It relies on the Entity Types and Formation Types defined in the EntityEditor and FormationEditor.

A FS level is composed of:

• Terrain
• Terrain model: A simple mesh created in an external tool, commonly by using and elevation map. In the future the mesh will be generated by the editor itself from the elevation map. Anyway, only the mesh geometry is used, all texture information is discarded.
• Terrain texturizing: Terrain can be textured by creating different layers by eight and/or by associating a texture with a color key in a color map.



Height layer terrain texturing panel

Selecting a texture for a color key based texture layer

• Water: Can be composed by up to two sliding textures. In the future it will be a shader to get a more professional result.
• Sun position: Affects lighting position and shadow direction.
• Height Fog: Enables a shader to create the illusion of water deepness

Selecting a color for the height fog

• Play Area
• Determines the playable area, that is a combination of the distance from the camera to the player avatar, the side scroll length, the viewing angle and so on.
• Entities
• Static: Buildings and the like. They can be destructible or not depending on its type.
• Moving: Tanks, ships and so on. They can be assigned a route to follow through the scenario.
• Automatically-Instanced: Any entity type can be automatically instanced by specifying a color key in a color map. That color map will be used to know where to create instances of the specified entity type. The user can specify the separation between entities and the randomness of its angle and position. Very useful to automatically create rocks, palms, and other terrain details.

Automatic palm instancing using the green color in the color map, the same key color
 has been used to apply the grass texture.

• Formations
• Airplane formations are the waves of planes that the player must face in the scenario. They are added from a set of formation types created in the Formation Editor. Is an easy way to create just a few patterns of waves in the formation editor and add them as many times as needed to the scenarios.

Moving a formation in the play area

As said before, the game engine is insanely modular and as a result the game engine is instantiated from the game editor itself so the game can be played while editing!. Actually, the editor is modifying the game objects directly, as they present an edition interface and serialize themselves in the scenario files.

Playing the game in the Scenario Editor

Anytime you can switch from game view to free view to identify and track down bogus behaviours.

Playing the game in free view in  the Scenario Editor

 Formation Editor

The formation editor is used to create and edit  the formation types used throughout the levels. 

It relies on the Entity Types created in the EntityEditor.

A Formation type is basically a group of entities (airplanes) that follow routes through the play area. Each entity in a formation can be instantiated once or more times, and can have an initial delay and a delay between instances.

Selecting a formation type to edit

An entity is selected

Hiding the sample scenario to improve visibility

The formation editor uses the game engine to create a sample scenario to test the formations. This simplifies debugging a lot.

Testing a formation from the formation editor

Testing the formation in the editor from the free view

 Entity Editor

The entity editor is used to create and edit the entity types used throughout the levels. 

When an entity type is created, its behaviour must be selected, a behaviour is a c++ class implemented in the configured modules (.dll/.so).

An entity is composed of:

• Properties: Properties are the basic parameters of an entity like its bounds type (BBox/BSP/None), its alignment (Neutral, Enemy, Player), maximun speed, maximun health and so on.

Adjusting the bounding box of the entity

• States: As said before, an entity type must have a behaviour. Each behaviour exposes its list of states. States cannot be created or removed as they conform the very basis of the entity. One or more animation can be created for each state. How each behaviour selects an specific animation for a given state is totally up to it. Examples:
• Bomber "BaseState" divides the entity current health by its maximun health, so the animations of that state reflect the ammount of damage received by the Bomber.
• Fighter "Destroyed" state selects a random animation to allow different animations for the entity destruction. 
• Animations: Animations are a basic composition of various types of objects that are activated and deactivated at the configured time.
• Models: A model can contain its own animation that is played at the specified fps. Model animations can be looped.
• Particle Systems: Particle systems are used to create special effects like fire and smoke.
• Sounds: Sounds are played at the configured time range and can be looped.
• Events: An animation can trigger an event of the entity, is up to the behaviour to respond to the specified event. 



Moving a particle system in a Bomber

• Child Entities: An entity can contain child entities, in any position and orientation. A child entity is bound to its parent lifespan and its reference system depends on its parent position and orientation and its own position and orientation in its parent. Child entities are very useful to create turrets and complex bosses.

Rotating a child entity (a turret)

Future work


The game is still being built, there are too many things in the TODO list to enumerate them here (I have  no intention to bore anyone).

Greetings

Very special thanks to Raul Pasarín (A.K.A. Campa) for his invaluable help with the models in the past few years (he has made virtually every model in the game),without him is very likely this project had terminated prematurely.