Art Bible
by Cristian Palos
When talking about the mood of the game, what must stand out is its old-fashioned style which immediately has to bring the player back to the arcade era. In order to do that, our intention is to keep as faithful to the original art style of Dungeons and Dragons: Shadow over Mystara as possible, which means that new art won't be required except in some specific cases, like:
- Missing assets
- Creating new assets from scratch
- Already created asset needs important modifications
In any other case, original art should not be used.
As stated above, our main intention is to use as many existing assets from the base game as we find it possible. Due to that, our major reference is, precisely, the original game, Dungeons and Dragons: Shadow over Mystara.
(All images taken from "D&D: Shadow over Mystara" (Capcom, 1996))
When creating original art, the process that has to be followed is the following:
Character creation flowchart
1. Brainstorming: First, a brainstorming is done in order to gather ideas. In this step, no idea should be judged or discarted.
2. Idea Refinement: In this step, the viability and compatibility with the project of the previously gathered ideas is analyzed. It is in this step when ideas are first discarded.
3. Concept Art: Ideas are explored by concept artists by creating design iterations until a result that could satisfy the requirements of the project is achieved.
4. Revision: Concept Art created is revised by the Lead Artist. If it fits with the requirements of the art of the project, it is ready to be implemented. If not, there could be two different flows to follow:
- If the problem with the Concept is because of the base idea, we should return to the Brainstorming step, wether to gather new ideas, or to recover ideas that were not developed. This should just be considered after several failures with the results of the concept, as it basically means to start from the very beginning again.
- If the problem is just with the final result of the Concept step, we should just return to the Concept step and iterate again.
Character proportions are fairly realistic, however, there are some considerations and relations to take into account if new characters were added:
-
Male characters are generally quite bulky and heavy-looking.
-
Female characters, on the other hand, are generally lighter and slimmer.
REMINDER: These are just general ideas, they do not have to be followed strictly under any circumstance. In some cases, character designs may break these guides because of the nature of the character. An example of this case would be the Mage, who does not share the proportions of the rest of male characters.
Characters are placed in a 2D environment facing each other. However, the player doesn't have to see the side of the character, but the character placed in a 3/4 perspective. This is the most common way to place characters in 2D fighting games.
How it SHOULD NOT be seen. (Screenshot from Super Metroid (Nintendo, 1994))
How it SHOULD be seen. (Screenshot from Street Fighter V (Capcom, 2016))
The Main palette of each character has remained the same as in the base game, as we wanted to stick to it the most we could and we didn't find any reason to change any of them.
Main palette of the playable characters. From left to right: Warrior, Rogue, Mage and Paladin
As players could select the same character for a match, characters must have, at least, a secondary color palette to easily distinguish one from the other.
Secondary color palettes are created basically by modifying the original sprite using the Hue/Saturation or Color Balance options in Photoshop. However, this is an automatic way of creating new color palettes, so this changes should just be applied to character clothes and not to their skin, as results are usually unappealing.
Secondary palette of the playable characters. From left to right: Warrior, Rogue, Mage and Paladin
NOTE: At the moment, we have just created a single secondary color palette. However, if it is needed, more will be added in the future.
When implementing scenarios, either existing ones or original ones, some considerations have to be taken into account:
The setting of the game is a fantasy-medieval world. The environment of the stages should reflect that setting and not contain anachronisms among its elements.
Example of the kind of scenarios that fit the desired environment of the game
As matches can be up to 4 players at the same time, stages must be deep enough to provide space for the proper development of the playing experience.
Example of a non valid scenario because of its depth. (Screenshot taken from the base game, D&D: Shadow over Mystara (Capcom, 1996)
If the walkable area is too up in the screen, the action will be overlapped by the UI. The disposal of the area the player will be able to use during the match is key to provide a comfortable experience.
As players have to be more focused on the opponent's moves rather than on their own ones, characters must have clear and defined shapes to distinguish as fast as possible each action. Taking that into account, what requires more level of detail is the shape and silhouette of a character.
In these two sprites, the shape is clearly detailed to express the motion.
On the other hand, it is not required for characters to have so much detail on their sprites, as players' attention will be centered in the action of the combat.
Characters' faces are really undetailed but it does not affect gameplay in any way.
Characters have, aside some exceptions, the same amount of animations, which is about 30. Those animations are classified in three different kinds:
-
Movement
- Idle
- Walking
- Forward Dash
- Backward Evasive Move
- Crouch
- Crouch Walking
- Jump
-
Attacks, where we can find 3 different kind of attack animations:
-
Basic Attacks
- Standing Light Attack
- Standing Heavy Attack
- Crouching Light Attack
- Crouching Heavy Attack
- Jumping Light Attack
- Jumping Heavy Attack
-
Special Moves
- Standing Special 1
- Standing Special 2
- Crouching Special 1
- Crouching Special 2
- Jumping Special 1
- Jumping Special 2
-
Super Moves
- Super Move
-
Basic Attacks
-
Other
- Damaged Standing
- Damaged while Crouching
- Damaged while Jumping
- Standing Block
- Crouching Block
- Jumping Block
- Standing up from ground
- Taunt
- Death
As said above, in the Level of Detail section, what most stands out about character animations, is its motion transmission, which will help players to recognize easily which kind of action their opponent is performing and react properly to them.
To see a more detailed explanation about Character Attacks with examples, check this section of the GDD page
Scenarios will have, in general, simple animation, as huge movement on the back could distract players of the match. Animations in scenarios will basically const of Background Parallax and Looping animations.
Example of a Background using simple Looping animtions. (GIF from Street Fighter II (Capcom, 1991))
Photoshop is the main editing tool we will use during the project, as it's quite simple and accessible and all the members of the team are already familiar with it.
Kawaks is the Emulator we will use when extracting sprites. The main reason of using it instead of more standarized Emulators, like MAME, is because Kawaks has the option to disable sprite layers one by one, which really speeds up the process.
ScreenGet is a complementary program we will use alongside Kawaks. It is useful to record the screen while performing animations because it automatically deletes redundant frames.
- IMPORTANT: First, make sure Video→ Correct Full Screen Ratio is set to "Smaller Display" in order to get sprites without deformations.
- In Video→ Disable, Disable all layers needed to leave alone what is intended to extract. In our case, to extract the animation of a character, all layers must be disabled except "Sprite Layer 4".
Background color can be changed if it is similar to one in the sprite by going to Video→ Set Background Color.
-
Now is the moment to turn on ScreenGet. While it is recording, perform whatever you want to export.
-
Finally, press "Save" and all the recorded frames will be saved as separated images, in the same folder where the Emulator is located.
-
Now just edit the image with Photoshop and we are done!
When building a spritesheet we have to know that how we place each sequence of sprites is important. Our goal will be to create a regular sprite distribution, which will require a considerable amount of time but will ease and speed up their implementation to the game. To create a spritesheet that fulfills this goal, we will create a grid that will have:
- Height of the highest sprite as height value
- Width of the widest sprite as width value
Example: Let's use these two sprites taken from the Mage spritesheet to show what's explained above.
First, we take the highest sprite, which is 128 pixels:
Then, the widest one, which is 143 pixels:
Assuming there are no sprites with higher values for height and width, the grid we would create would be 128x143 pixels.
When a spritesheet is finished, it must be exported in PNG format keeping transparency.
In order to organize assets, they have to be named in a certain way depending, first of all, on their type, and then, on their current status:
- Spritesheets & Stages
- Work In Progress: assetname_spritsheet_WIP/assetname_stage_WIP.
- Done but Yet To Revise: assetname_spritesheet_YTR/assetname_stage_YTR.
- Revised and Approved: assetname_spritesheet_RA/assetname_stage_RA.
- Revised but a Modification is Needed: assetname_spritesheet_MN/assetname_stage_MN.
Example of how the name of a file evolves during process:
-
Portraits*
- assetname_portrait.
-
Other
- assetname_type_status.
*Some assets, like Portraits, may not go through an editing process. In that case, they should just be named assetname_type.
You can check all the game art assets in the following folder
The folder will be updated as new assets are extracted or created during the whole development process.