Game Assets folder structuring approaches and dimension. Introducing the Theatrical approach.

Marzepain · Feb 17, 2021

Abstract and Figure
Game Asset Structuring has great potential to add sense to folders and files, as well as making a mountain of assets used in a game manageable. A preposition of seeing the assets and the code as different specialisms, having different work processes and changing for different reasons, is helpful but not mandatory.
The approaches often used in the field are, "The Functional or Content Type approach" going from the assets themselves to the game systems and "The Domain, Aspect or Component approach" going from the game systems to the assets.
This article introduces the Dimensional approach to structure the files and folders along Dimensions. A Dimension being a level of the folder tree where every folder is an answer to the central question of that Dimension. The path to the asset file forms a number of adjectives that give extra information about that file.
The Theatrical approach builds on the Dimensional approach by having a set of predefined Dimensions. A number specific tot the Theatrical approach are:

A Dimension related to Story Development, denoting whether and asset is constant, a base implementation or an override in a certain part of the story.
A Dimension categorizing by the areas of Core Knowledge in Developmental Psychology, using Theatre and Film industry names for consistency with the Story Development Dimension.
A Dimension categorizing the Scenic Design elements used for the background and the details of the game.
A Dimension categorizing the State, Action or Performance an asset is enacting.

The Theatrical approach is a natural fit for Visual Novels, but can be used with any game having some rudimentary story.
The Theatrical approach feels natural to use, but is distinct from the game mechanics and the implementation assets, making it able to remain correct and performing even under 2 often occurring scenario's:

Mayor changes in game mechanics impacting the assets of the game. This often occurs in early game development, when the search for gameplay happens by trial and error.
Mayor increase in the size of the game impacts the number of assets to manage. This often occurs in late game development, when the game scales up.

The predefined Dimensions of the Theatrical approach could be the basis for tooling that generates code variables, object definitions with properties or other asset-code integrations.
The data of a game can also be divided by the predefined Dimensions of the Theatrical approach into smaller files placed in the folders of the file system, instead of having a massive datafile in a hierarchical format like Yaml, JSON5 or XML.
Data, being Latin for facts, should be in human readable text files, thus they match the normal code repository storing diff's. Assets are binary files interpreted as audio, video or images, thus they match the LFS repository storing whole files. As such, assets and data should be in their own specific folders. This would also simplify reuse of assets and data. To simplify ease of navigation the structure of those folders should mimic each other.
Data management is important for all games. Data driven games are more aware of this fact, thus they are more likely to adopt a Dimensional approach to their data. The Theatrical approach, taking the Dimensional approach further, may simplify the development of data driven game engines, making games easier to develop and scale.

You don't have permission to view the spoiler content. Log in or register now.

------------------------------------------------------------------------------------------------------------
Table of Contents

Intro
Approaches
1. The Functional approach
2. The Component approach
3. The Dimensional approach
4. The Theatrical approach
The Dimensions of the Theatrical approach
1. Release version dimension
2. The Story Development dimension (Act/Scene/Base/Static)
3. The Core Knowledge dimension (Characters/Props/Locations)
4. The Scenic Design dimension (Supernumerary/Costumes/Décor/Scenery)
5. The State-Action-Performance dimension (Emotions/Activities/Processes)
6. The Component dimension (Expanding on the previous Dimension)
7. The Functional dimension
8. Self describing filenames
9. Related file dimension indicated by filename prefix (Cut-out naming)
10. Incremental animation still numbers by filename postfix (Animation numbering)
11. Denote the filetype by dot extension filename postfix (filetype extension)
Considerations
1. Do not create folders with too little content
2. Do not have too many assets in 1 folder
3. Managing folders with too little content by moving descriptions from the folder to the file
4. Managing folders with too much content by creating a folder based on adjectives and move matching files into it
5. Support quick comparison
6. Support consistency by putting things that belong together near each other
7. Functional folders are of limited use
8. Consider using English for your file and folder names
9. Consider mimicking your working folder with your game folders
10. Consider stripping or converting your working assets into game optimized assets when putting them in game folders
11. The Game Asset Structure should support multiple artists collaborating
Technical issues
1. Ignore the file path length unless it's cumbersome
2. Use LFS when putting binary assets in a Version Control System
3. Take note of build in change tracking
Tests
1. Assets of Lust Town
2. Assets of a Master of Magic a Civilization clone with 4X and RPG elements
3. Asset management with 2 Git Repositories and an ID-Asset list
Experience
1. Seeing professional at work
2. Checking out game asset folders
3. Some Indy developers are aware
4. The Open Game Asset Structure is a fact
5. The field contains some painful situation
Observations
1. Rendering figures with a standard set of emotions and poses makes the story less rigid and could be more efficient
2. Have an idea of the size, scope and context of the game to determine your Game Asset Structure
3. Know if the first released version of the game is a PoC, a Pilot, a Feature or a Statement
4. Manage your energy level
Acknowledgements
Conclusion
Edits
Ps.

1. Intro
This article is what at a conference be called level 400, "Expert" or "Mastery", but what others might call "nit-picking". Read at you own peril!

Assets are the parts that make up a game, like images, video and audio. The assets of a game are created and maintained in other applications and therefor have an industry standard format. These can be open standards like PNG, JPG, MPRG or OGG, but some proprietary formats associated with commonly used tools are also considered industry standard.
The business definition of an assets, as something that helps the bottom line, holds also true as game assets help the game be successful. The accountancy definition of an asset, as something of value that is left when the business liquidates can also be satisfied. Many of the assets are specific to the game, but could be used on another project with some rework. There have been many reports of cancelled games having their assets reused in another game or sequels maintaining lots of assets from the first game.

There has been some discussion on for a, about how to structure the assets folders of a game. Generally, the advice has been, do whatever you like. I think I might add some helpful hints for game developers or at least some talking points for experienced developers.

There are also some game making development environments that provide predefined folders. Those are generally arbitrarily chosen. Those folders might have helped some developers manage their assets, but they lack any rationale.

Assets go through a number of stages. The Theatrical approach is meant for the Finished assets and the related assets in the Working folders.
The stages an asset can go through are:

Working - The asset is being created and changed
Finished - The asset is ready for use in the game and is then put in a folder that indicates its readiness.
Identified - The asset has been identified or pointed to by the contents of a variable in the game code.
Packaged - The asset is packaged together with the other assets for transport in one of the following
- Archived in an open format like Zip or Rar together with the game scripts and code. Unarchived the game executable archives the files directly
- Archived in an open format like Zip or Rar first then archived again with the game scripts and code. Unarchived the game executable uses the assets in the archive by unarchiving them on the fly. A library like
  You must be registered to see the links
  can help with this.
- A game specific compression format like
  You must be registered to see the links
  ,
  You must be registered to see the links
  ,
  You must be registered to see the links
  ,
  You must be registered to see the links
  generally for 3D. The archiving can be done in 2 ways
  - Similar to a archived files like a Zip or Rar
  - As memory dumps. These need no processing past the read of the data. If reading is slower than decompressing, this may actually be a slower option overall.
- A system specific packaging for instance for Steam, AppStore, Xbox, PlayStation generally for download and updating by download.
Indexed - There may be a list converting the ID of an asset either to the path of the asset on the OS filesystem or in the archive filesystem. Alternatively, there may be a pointer into the blocks of a memory dump archive.
Replaced- the developer indicates in the game that the package is valid, but the specific asset file is replaced by another file. This is done to avoid having to download a new whole package, where most has remained the same. This can be done in 2 ways
- By changing the path in the ID index so the game will read the replacing asset instead of the original.
- By heuristic, meaning that the game has a way of finding out that an asset is replacing another asset in the archive. An example of a simple heuristic is that an asset placed in the folder where the archive resides replaces a similarly named asset in the archive. A slightly more secure heuristic is one that takes the folder structure into account, so the name and the path must both match the replaced one in the archive.

Sometimes there is a claim that the predefined folders give a performance benefit to the game, but any performance claim without taking the situation into account is doubtful. The disk fragmentation issue is hardly relevant these days. Compression done by the development environment on the assets, may benefit performance. It is common that a CPU can faster decompress data, then read from a HD and can do the decompression on an underused core. Often a closed compression format specific to a game engine is used leading to a suboptimal result. Many times, it would be better to simply use Zip. It would be best to view the folder structure as separate from how the compression is done.

My starting point is the assets themselves, the story and the simulation of the world, not any programming language, game engine or Integrated Development Environment (IDE). This way of structuring is intended to work with every engine, so taking any single engine's limitations as the basis for it, could render it valueless for others. Programming languages are extremely flexible so they are expected to work with this structure. Game Engines and IDE's vary in their flexibility and some can be rigid in their structure. If one gives trouble, please let me know and it will be included here, together with a workaround.

2. Approaches
There are a number of approaches an asset folder can be structured. I created the Theatrical and Dimensional approach, but there may be more, please let me know if you think so.

Name: The Functional or Content Type approach
Description: This is a bottom-up approach going from the assets themselves to the game systems.
This approach is about putting all the files that function in a certain way in the game, in the same folder.

The very basic approach is about very basic functional categorizations like audio, video and image assets.
A more advanced way of is having functional categorizations, Content Types, related more to the game mechanics, then just the basic ones, whiteout having a specific component or part of the game in mind. For instance, categorizations of images that are more related to game use are LocationBackground, CharacterStatue, CharacterBust and CharacterFace. For audio this might be BackgroundMusic and SoundEffects.

Note:

The video folder may also contain images, but only images that function as a part of a video.
This approach is the most often used way of grouping files, especially when starting out. Also used for websites as the ratio of image, CSS, html and JavaScript files is much more equal.
This approach is also seen in the Content Type managers can define when using Content Management System (CMS). The Content Type can be used in multiple parts of the managed website and is not limited to a specific part of the website.
As progress is made the Functional Approach moves to the Component Approach as the animations get split off from the video, the images get split up in folders like fightImages, dialogImages, menuImages, audio in folders like worldBackgroundAudio, menuAtmosphericMusic, fightSoundEffects.
Grouping of multiple images into a single overview image can work for this approach as the overview image is still an image, thus the overview image also belongs in the image folder. It is ill advised as the game code has to cut the individual images from the overview image, thus it has to know the coordinates of the individual image areas. This makes reuse impossible and updating an image forces an update to the overview image thus touching all other images. It is actually a form of archiving images and negates the normal name plus path structure. For an overview of the images a tool like an image viewer with folder view is better used.

Example: audio, image, video

You don't have permission to view the spoiler content. Log in or register now.

Pro:	It's easy to implement.
Con:	It's seriously lacking as a method of dividing assets in smaller chunks as most assets in a game are images. It's redundant, because most assets have a type extension. It's cumbersome to have to go down a folder, that adds little information to the assets.

Name: The Domain, Aspect or Component approach
Description: This is a top-down approach going from the game systems to the assets.
This approach is about putting all the files that are related to a certain Domain, Aspect or Component of the game, in the same folder.

A Domain is a part of the application or game that is so different that it has a specific vocabulary. For instance, the map part may have functionality for "travel", while the world part may call the same functionality "walk" and the fight part may call it "advance". While these are essentially the same functionality. these Domains differ so much that they have evolved different Mindsets. This could occur on the largest games with many teams working on them, but could also happen on games that have a client and a server team. The assets of a certain domain should logically be separate from the rest of the game assets, by having their own folder.
An Aspect is a cross cutting concern of an application or game. The quintessential application example is logging that happens on all locations of the code and can be can be weaved through an application by containing it in an aspect. For a game this is a part like the fight system that may spring into action many times during the game and is thus weaved into the story of the game at various points. The fight aspect of the game is tightly woven into the game, having interaction with the rest of the game on various levels like the high story level as well as the low detail level of resource management. The assets of a certain aspect should logically be separate from the rest of the game assets, by having their own folder.
A Component is a part of the application or game that differs from the rest of the game, but can be defined on any level of the game, be it high level like story or details like resource management. A component can be a part of another component, so you could see the game as hierarchy of Components. The assets of a certain Component should logically be separate from the rest of the game assets, by having their own folder, but the Component folder can be a subfolder of a parent Component folder in the same way as the Component is part of another Component.
A Generic Component is one that could be reused in another game. The assets of a Generic Component should logically be separate from the rest of the game assets, by having their own folder, so that folder can be lifted from the game into another game.

Note:

When moving from the Functional approach the Functional folders are generally maintained, but become subfolders of the component folders. This occasionally happens when for instance UI is moved as a component from one project to another, encapsulating all that is needed to function.
The Domains off this approach are related to Domain Driven Development (DDD), where domains communicate with each other, but are their own separate entities. The popular Microservices Architecture takes the separate entities to the max, by making them separate applications, thus DDD has become popular for the 3de time, hopefully this time to stay.
The Aspects of this approach are related to Aspect Oriented Programming.
The Components of this approach are related to Object Oriented software development, specifically Unified Modelling Language (UML) Component Diagrams. It is more an engineering approach to game development.
The Generic Components are related to reusable Components created by game developers over multiple games.
Grouping of multiple images into a single overview image can work for this approach, if the overview image contain only images from the same component, thus the overview image also belongs in the component folder. An example would be an image with all the terrain tiles available on the map. It is ill advised as the game code has to cut the individual images from the overview image, thus it has to know the coordinates of the individual image areas. This makes reuse impossible and updating an image forces an update to the overview image thus touching all other images. It is actually a form of archiving images and negates the normal name plus path structure. For an overview of the images a tool like an image viewer with folder view is better used.

Example: map, world, character fights, character dialog, dialog boxes, reports, cut-scenes

You don't have permission to view the spoiler content. Log in or register now.

Pro:	It's easy to replace a component in a project with another one or move it to another project as everything related is grouped together. It's easy for a specialist in a component, for instance, the specialist for cut scenes or the fight action, find "his" folder, but this is only relevant on extremely large projects.
Con:	When things like a hero should be consistent across the game, components make that difficult because they are essentially their own little world. Also adding and removing characters is difficult as they have to be added or removed in multiple places.

Combining approaches: Functional and Component combinations

Component folders with Functional subfolders	This is the regular ok combination.
Functional folders with Component subfolders	This does not have the advantage that a component is easily moved. This tragedy can easily develop, because when starting out an Artist knows nothing about Game Components, thus starts out with the Functional approach. Upon learning more about Game Components the Component folders are added under the Functional folders creating a working, but suboptimal result.
Integrating the Component name with the Functional name into the folder name	This avoids having to go down a folder and what belongs to the Component can be seen by the sort order of the folders. There may be a combinatory explosion of the number of folders. Searching and scrolling for folders may be common, but on small projects it's fast.
Integrating the Functional name with the Component name into the folder name	This avoids having to go down a folder, but the sort order of the folders does not indicate what belongs to the Component. There may be a combinatory explosion of the number of folders. Searching and scrolling for folders may be common. The sort order does not help, so this is workable only on the smallest projects.

Name: The Dimensional approach
Description: The assets of the game form a mathematical tree as the folders are nodes and the files are leaf's. The Dimensional approach uses the answers to a question about the assets, as the names of the folders on that level of the folder tree. The assets are sorted into the folder matching the answer to the question. The answers form a Dimension of the set of assets or alternatively a way of looking at the assets in the game. The effectivity of this approach is directly related to how easy it is to answer the question about the asset. When done right, the path to the asset file forms a number of adjectives that give extra information about the file.
Another way of looking at this approach is related to why folders exist in the first place. Folders LIMIT what you see of all the files, because not everything is relevant to you if you are in a certain context. The context when being located in a folder, is described by the name of the folder and all of the parent folders above that location combined.
Note:

In practice this may simply be, omitting some of the dimensions of the Theatrical approach. For instance, the release question may not be applicable, as you plan to do only one release.
Reordering of dimensions is possible if your set of assets is better sliced in a different way.
Sometimes a dimension has to be multiple folder layers as for instance, Acts contain Sequences and Sequences contain Scenes. Other examples are the Characters folder containing a folder for each character or the Props containing a folder for each property piece or item.
Asking other question dimensions then those in the Theatrical approach is of course possible. A hallmark of a better question is one that YOU can answer more easily and distinguishes better between assets.
- A question like "Is it an asset?" may be easy to answer, but it does NOT distinguish between assets.
- A closed question, a question answerable with Yes or No, distinguishes again LITLLE between assets, because there are only 2 answers.
- IDEALLY you want a number of answers you can see at a glance in a folder, the answers make sense to you and in each answer folder there is a good amount of assets.
- Having a question like "What is my most important asset?" is UNBALANCED as it will yield only 1 answer and the rest of the assets falls outside of it.
- Having a question like "How is my asset called?" or something other unique thing like an ID would be too specific and would mean that every asset has it very own private folder.
Some developers may have noticed here that the Dimensional approach has much in common with relational database theory. Getting to your desired file can be described as an alternative SQL SELECT query. The files and folder are then seen as a more limited version of a Database. Off course this is not just an application of math, because here "Man is the measure of all things" is part of the system.
Grouping of multiple images into a single overview image can work for this approach, if the overview image contain only images from the same dimension answer, thus the overview image also belongs in the dimension answer folder. An example would be an image with all the buildings in the game, instead of each building being a separate image. It is ill advised as the game code has to cut the individual images from the overview image, thus it has to know the coordinates of the individual image areas and the building probably have different sizes, making the coordinates irregular. This makes reuse impossible and updating an image forces an update to the overview image thus touching all other images. It is actually a form of archiving images and negates the normal name plus path structure. For an overview of the images a tool like an image viewer with folder view is better used.
The Dimensions can also be used to slice the Data of a game into smaller files placed in the file system instead of a massive unwieldy file in a hierarchical format like Yaml, JSON5 or XML. A single massive datafile can be loaded in one go while the smaller datafiles must be loaded separately. An IdDataPathList similar to an IdAssetPathList could help with this by providing where to find the datafiles and which files to load together.

Example: A question could be: "To what release could the assets belong too?", the answers, "core", "v002", "v003" are used as folder names. Then as for every asset: "To what release does this asset belong too?" and move the asset to the "core" folder if the answer is "core", move the asset to the "v002" folder if the answer is "v002", move the asset to the "v003" folder if the answer is "v003".

Pro:	No need to use dimensions you think are nonsense or not applicable.
Con:	When omitting or reordering Dimensions, tooling might expect other names on the level of the folder tree and thus not work. When initially not using all Dimensions of the Theatrical approach, your game may grow so big that more, maybe all, dimensions are needed. Adding Dimensions later can make a mess of things and is confusing for collaborators.

Name: The Theatrical approach
Description: Use all the dimensions of the Theatrical approach in your Game Asset Structure.
Note:

Theatrical generally means large, over the top and emotional. At first glance that's not desirable is a Game Asset Structure, but when a game grows big, large is inevitable. It is also important that the dimension is easy to work with. In psychology it is well known, that things that have an emotional connection, are easier to remember then those that have no emotional connection, especially if those emotional connections are embedded in a story.
Another note is that Assets are created and maintained by an Artist and used by a Coder in the game mechanics. In order to maintain the Assets according to the Functional and Component Approach, the Artist is forced to know something about the Game Mechanics. For User Interface (UI) assets this is inevitable, but for Characters, Props and Locations using the Theatrical Approach this is much less so.
Grouping of multiple images into a single overview image can work for this approach, if the overview image contain only images from the same dimension answer, thus the overview image also belongs in the dimension answer folder. An example would be an image with all the animation frames of a character, instead of each frame being a separate image. It is ill advised as the game code has to cut the individual images from the overview image, thus it has to know the coordinates of the individual image areas. This makes reuse impossible and updating an image forces an update to the overview image thus touching all other images. It is actually a form of archiving images and negates the normal name plus path structure. For an overview of the images a tool like an image viewer with folder view is better used. Specifically for the animation of a character, separate images for frames makes it easy to view the animation by scrolling through the images in the folder with the arrow keys or making a slideshow out of the frames. The impact of the area coordinates needed to cut the images from the overview image can be mitigated if they are NOT stored in code, but in a id-asset path list as part of the path. This will still hamper reusability and updating, but decouples it from code, so it's more accessible.
Data, especially in a hierarchical format like Yaml, JSON5 or XML, has a similar problem as multiple images being grouped in an overview image. It is possible to group all data in a single datafile and load it in a single go. Unfortunately this creates a massive unwieldy file where things will be hard to find. It is better to distribute the data in multiple files placed in a similar file system structure as the Theatrical Approach. That way the data for a character, prop, location or scene will be found in the datafile found in the folder of the specific entity. For instance, a characters stats like health and attack, will be in the datafile placed in the characters folder, the layout of a location placing various scenography things together would be in the datafile placed specific location folder and the scene data like the triggers, machinima and dialog would be in the datafile placed specific scene folder. As data is the multiplicity of datum, the Latin word for fact, data is different from assets as assets are binary pieces that represent audio, video and images. Data, being facts, should be human readable and placed in a different file structure then the binary assets. The assets would then be in a LFS repository and the data in a normal repository storing diff's. In practice the Assets and Data folders mimic each other's file system structure as for both the Theatrical Approach is valuable.

Example: See my "Lust town" post, note the scene folders in the "Lust town" post image that are 1 camera shot each, but most contain multiple images.
The image here below is quite big as it shown all folder at once. Although this would not be your normal experience. The whole idea of folders is to hide most of the assets, because they are not relevant to what you are doing. More is explained further below.

You don't have permission to view the spoiler content. Log in or register now.

Pro:	You are set for scaling up. You look like a pro. If "standard" semantic names are used, tooling can generate variables or properties on objects for you, reducing the amount of drudge code you have to write.
Con:	It's more work than doing another approach. It may have more folders then initially needed. It may also take some getting used to.

3. The Dimensions of the Theatrical approach
Doing these asset dives I have started to notice some patterns and dimensions:

Release version dimension
The Story Development dimension (Act/Scene/Base/Static)
The Core Knowledge dimension (Characters/Props/Locations)
The Scenic Design dimension (Supernumerary/Costumes/Décor/Scenery)
The State-Action-Performance dimension (Emotions/Activities/Processes)
The Component dimension (Expanding on the previous Dimension)
The Functional dimension
Self describing filenames
Related file dimension by indicated by filename prefix (Cut-out naming)
Incremental animation still numbers by filename postfix (Animation numbering)
Denote the filetype by dot extension filename postfix (filetype extension)

Name: Release version dimension
Dimension Question: What releases of the game are there?
Asset Question: To what release does the asset belong to?
Description: The version of the assets making up the game and released to testers or the public. These are not Working versions, but the Final assets used by the game.
Note:

As the 0.1 version of a game should have the basics working, it's logical to call it the core of the game and follow that up with releases that are numbered incrementally.
It's convenient if the Working and Final folders mimic each other. The word "core" has the same amount of letter as the word "work", so the path would not differ in length for the Working and Final versions of the assets. Short names are also good here, as the release dimension is in the root of the folder tree and thus traversed or typed many times. Alternatively, "main" is also good, although it does give the suggestion that everything outside of main is less important instead of additional things.
If the Working folders are mimicking the folders in the core and the incremental versions, the relationship between the core and the versions is incremental, meaning that the versions do not contain the assets of the core. This implies the assets of an incremental versions can be copied on top of the core to get a complete version. There could be separate downloads for the complete and incremental version. In order to avoid copying the version folder on top of the core folder, the game could check both the core folder for an asset and the version folders according to a logical scheme. The scheme with v002, v003, etc. is probably the easiest to implement.

Example: core, v002, v003
Shorter alternative: v1, v2, v3
Mayor-Minor release alternative: release_0_1, release_0_2, release_0_3
Series alternative: Episode_01, Episode_02, Episode_03,
Season alternative: S01E01, S01E02, S01E03

Pro:	Easy extension when a game grows large, which most successful games do. Also, easier splitting downloads can be helpful, especially when the ratio of new material gets small compared to the rest.
Con:	The path is a little deeper, making getting to the assets from you programming language slower and a little more cumbersome.

Name: The Story Development dimension (Act/Scene/Base/Static)
Dimension Question: What parts of the story of the game are there, are there assets used in multiple parts of the story, but possibly overridden by others and are there assets that are used, but can never be affected by the story?
Asset Question: Does the asset belong to a particular part of the story or is it used in some parts of the story, but could be overridden by others or is the asset static and can never be affected by the story?
Description: The asset folders are named after when the assets are needed in the story.

The assets in the static folder never change
The assets in the base folder never change, but function as defaults for the ones in the Acts and Scenes.
The assets in the act, sequence and scene folders override the once in the base folder specifically in that specific act, sequence or scene.
The assets in the sidestory folder are unrelated to the main story. Scenes on a TV screen or mini game go here.

Note:

The static folder mainly contains the UI as that does not change during the game, as it's outside of the story.
The base folder mainly contains figures, in general states and emotions used in character dialog.
The scenes contained in the sequences and acts generally contain cut-scenes in images and video specific to that scene.
A game only consisting of game mechanics like checkers or go does not really have a story, although it is possible to imagine one.
An abstract game consisting of abstract figures serving the game mechanics, like chess or card games, does not really have a story. It relatively easy to imagine a story around it, because of the Kings and Queens and the battle the armies enact. When imagining a story about chess for instance, most people will come up with a beginning, about why the abstract battle of the game takes place and an ending telling of what happens afterwards.
Every game that has a prologue, introduction or intro and possibly an epilogue or outro has a story. This is so for the fast majority of computer games. This implies that the Story Development dimension could be used with almost all computer games.
A game simulates a world and is generally much larger than expected, by those beginning with game development. Only the simplest and most basic of games would involve only static parts.
The nature of game development is such, that things get tagged onto the game, while going through the process of developing it. These tagged on pieces or items are often a good fit to put into a specific Act, Sequence or Scene as they only matter there.

Example: act1, scene_001_WakingUp, base, static, sidestory

You don't have permission to view the spoiler content. Log in or register now.

Pro:	Because the relation to the story is used to group the assets, the story functions as a roadmap to the assets.
Con:	The game may not have a story that changes the assets. For instance, a simple chess simulation would have only static assets, because the assets stay the same during the game.

Name: The Core Knowledge dimension (Characters/Props/Locations)
Dimension Question: What Core Knowledge systems are used in the game?
Asset Question: To what Core Knowledge system does the asset belong to?
Description: The Core Knowledge dimensions come from Developmental Psychology. They are the systems humans are born with to make sense of the world.

You don't have permission to view the spoiler content. Log in or register now.

Mapping them to the terms common in Theatre and Film makes it consistent with the Story Development dimension.
There is a split between primary assets that are unique to the story and the rest of the assets that are either secondary background assets or generic helper assets. The Scenography folder holds all these secondary and helper assets.

The Agents system maps to Characters and in Scenography to Supernumerary and Animalia.
The Objects system maps to Props and in Scenography to Ornaments and Costumes.
The Geography system maps to Locations and in Scenography to Scenery, Terrain, Décor, Fixtures, Furniture, Plantae and Effects.
The Social/Hierarchy systems maps to Groups and in Scenography to Elements.
The Calculus/Numbers system maps to Determinations and in Scenography to Elements.
The Shape/Form system maps to Descriptions and in Scenography to Elements.

Note:

The core knowledge folders should contain specific folders instead of dumping the asset in that folder directly. For instance, a hero or antagonist folder under the Characters folder makes it much easier to add assets to the hero or antagonist, although it may start out as only having 1 asset. It also gives a certain gravitas to the characters, props and locations.
In combination with the previous "Story Development" Dimension we should ask the question of the "Core Knowledge" Dimension also in the Act and Scene answer folders. For instance, a scene can have "characters", "props" and "location" folders when those are specific to the scene.
The Scenography folder containing background and helper asset can be found in multiple places.
- The Scenography folder is commonly found in the base folder as it contains elements that can be changed during the story.
- An Act or Scene could have a Scenography folder holding assets specific to that Act or Scene, mostly concerning specific background assets.
- The static folder can have a Scenography folder, when a scene takes place outside of the story. This sounds impossible as a scene is normally part of the story, but many games show the cast of the game in a certain situation, on the title screen as a meet and greet. Some games have a start menu with a landscape in the background that is flown over. Other games have a start menu background where the hero runs and guns an obstacle course as a means of showing of the game. It may even be possible to change the camera and get descriptions, but everything done there is of no effect on the game.
- Some games do have progression and unlocks effecting the start menu, possibly changing the background shown. These start menu's belong in the base folder instead of the static folder. The Scenography is probably already in the base folder, as this type of start menu probably uses assets from the main game.
Characters have agency and almost always have direct influence on the story. A rare exception of indirect influence would be an expected arrival that never comes. For instance, the expected arrival of a king that upsets a household, but chancels at the last moment, thus the king character has tremendous influence, but is never seen.
Props are objects that are used by a character in the story or are specific to the story. Props is short for
You must be registered to see the links
that props up the acting or story. In a game these are generically items that can be put in the players inventory or are items that are interacted with in the story.
- Prop weapons are in film, weapons that look real but are not harmful. In a game these are simply weapons.
- Stunt props are in film, breakaway object like balsa-wood chairs and sugar glass, that are not harmful when used as a weapon. In a game these are simply item props.
- Hero props are props are the more detailed pieces intended for close inspection by the camera or audience. In games these are often
  You must be registered to see the links
  or
  You must be registered to see the links
  's meaning that they move the story along. Examples are the magical sword Excalibur, the Iron Throne, the stolen Persian rug that gave cache to the dude's room.
- The icon of a prop, like a sword in the inventory, create or trade window would NOT be a Prop, because it is not an object in the story. The sword icon would land in the descriptions, determinations or even elements folder. The icon of a prop on the map would be a Prop as it is the Prop, but within a different view. If both the Inventory and the map use the same Icon, the Icon would land in the Elements folder as it is then a generic usable interface element.
Locations generally start out with only having a backdrop, depicting the Scenery or Décor, associated with it. This could change by the state of the location, during story development. For instance, the Scenery might change at night or morning, the Décor may change after a burglary or fire etc.
Scenography contains generic usable set pieces in folders corresponding to Scenic Design. For example, street lamps that are the same in every city the player goes.
Scenic Design folders that are subfolders of Locations, Characters or Props folders are specific to those folders. For instance, when Scenic Design folders are a subfolder of a Location the assets in that folder are specific for that location, like palace lamps that are the same in many rooms of the palace, but are never found outside of the palace.
The Scenography folder contains generic assets usable for multiple Locations, Characters and Props categorized by the Scenic Design dimension.
The Groups folder may have Nations, Factions, Bands, and Races in them. These are all multidimensional and could have colors, flags, mascots etc. Although Nations consist mainly of rules and ideas influencing behavior, they have assets attached to them like a flag or anthem. The group is a weaker means of categorizing assets then Characters, Props or Locations, thus the group folder contains things that do not fit in the Characters, Props or Locations folders. Some caveats:
- A Character from a Nation should not be placed under Groups, but under Characters if it's an important Character or under Super luminary if it's not important. Another way to put it is that the Character is an individual, having multiple dimensions to their personality and being a representative of a group is not the only thing a person is about.
- A specific item like a banner being held by a soldier, may be associated with a Nation, but the instance of the banner is a Prop. The Nation may have a typical banner associated with it and its design would be under Descriptions, but the material object of a banner used is a prop.
- A Location a scene is performed on should be put under Locations. The location can be part of the territory of a Nation and the assets that support that claim like the assets of a map screen could be associated with the Nation, thus under Groups.
The Determinations of the Calculations/Number represents things inside the story like Trade, Creation, Transformation and Mining and about the story like Load and Save. The assets associated to these are generally part of the UI.
- A common example of a Determination INSIDE a story is a Trade Window. The assets of the Window would be located in the base folder under Determinations, because the trade Window may change during the game. For instance, as the location where the trade is done changes or the player's skill in trading improves.
- Determinations INSIDE the story are also outcomes of a story and the associated "Intertitle" screens like Failed, Success, Continue and Completed. The assets of the "Intertitle" screens would also be located in the base folder under Determinations, because those outcomes are generated during a story and may change because of the story. Even the "Game Over" screen would not be the end for arcade games if you had another credit.
- A common example of a Determination ABOUT a story is the Configuration or Save and Load screen. The assets of the screen would be located in the static folder under Determinations, because they don't change during the game.
The Descriptions only give insight into the state of the story of the game. Descriptions do no action and change no state and are therefore save to do as much as you like without endangering anything. The difference between Descriptions and Determinations is that Determinations can or will possibly do an action like trade, creation, transformation and mining. Off course the assets contained in Determinations folder do nothing by themselves, but are used by game actions or options.
The Descriptions and Determinations will very rarely be under the Acts or Scenes folder as it's generally comfortable for a user to keep the UI consistent in various situations. A possible exception to this is a specific scene where the player is made king and gets country Reports and Management Windows at his disposal, while in the next scene he is dethroned, has to flee the kingdom and the story continues without those Reports and Management Windows. This would subvert the expectations of the player massively and be a lot of work for just one scene.
The difficulty of the Shape/Form system is that it is a property of an Object, Agent, Geography or Social construct, thus the assets in the Elements folder should be under those folders. The exceptions are the parts of the game that are not part of the simulated story world, mainly the UI.
The difference between Shape/Form system Descriptions and Elements are that Descriptions contains assets about the whole and elements contains assets about a part or a property of the whole.
- Examples of assets in the Descriptions static folder are the Credits and the Manual, as the they describe the game as a whole and never change during the story.
- Examples of assets in the Descriptions base folder are:
  - Reports, like the Completion Report of how far you are in the game, the Competition Report of how well you are doing compared to you opponents and many others.
  - Screens, like the Map Screen
  - Panels, like the Inventory Panel or the Contact of the mobile phone
- Many assets in the Descriptions base folder are reasonably generic and could be sourced from another project with a similar theme.
- Examples of assets in the Elements static folder are generic fonts, buttons, checkmarks, notifications used in multiple places. They are either used or not used, but never changed by the story.
- Examples of assets in the Elements base folder are the UI icon elements, many of these are on screen buttons and info items part of the HUD that could possibly be affected by the story. Common reasons for these elements changing are a change in time effect the of day to night or enabling the map at some point in the story. Specific examples of these elements are:
  - Your money bar
  - The time-of-day signifier
  - The Map icon for going to the map view
  - The Inventory button for opening the inventory
- Many assets in the Elements static and base folders are generic and could be sourced from other projects.
The reason the Social/Hierarchy, Calculus/Numbers and Shape/Form systems can map to the Elements folder in Scenography, is that the assets in the Elements folder are generally used to identify or describe groups, trades and things. For example, the asset symbol for gold can be used to describe how much gold the player has left, how much gold a faction has stored, the currency of a nation or the cost of a possible trade.
Tests with the Descriptions, Determinations and Elements folders may reveal that many a second look is necessary to see if these folders are in the static or base folder, because that would imply a slightly different meaning. This independent naming scheme does make it possible to reorder the dimensions, because they do not rely on each other, but it may be inconvenient for the user. Although the assets in these folders are just a small part of the game and this naming scheme may just take some getting used to, it is possible to use different specific names to these folders, when they are in the static or base folder. Examples of these specific names are:
- The Descriptions folder contained in the static folder could be named Explanations, because it mainly contains the Credits and Manual about the game.
- The Descriptions folder contained in the base folder could be named Inspections, because it mainly contains Reposts, Screens and Panels of the game being played.
- The Determinations folder contained in the static folder could be named Ascertain, because it mainly contains the Configuration or Save and Load screens about the game.
- The Determinations folder contained in the base folder could be named Enact, because it mainly contains Trade, Creation, Transformation and Mining Windows, as well as "Intertitles" of the game being played.
- The Elements folder contained in the static folder could be named Pieces, because it mainly contains the generic fonts, buttons, checkmarks, notification, etc. used in multiple places in the game.
- The Elements folder contained in the base folder could be named Fragments, because it mainly contains UI icon elements of the game being played.

Example: characters, descriptions, determinations, elements, groups, locations, props, supernumerary

You don't have permission to view the spoiler content. Log in or register now.

Pro:	It's quite a powerful way of organizing your assets as it's quite detailed. It should be easy to pick up for people as it's based on systems every human has.
Con:	Some of the names are quite high level, so it may be confusing what goes where.

Name: The Scenic Design dimension (Supernumerary/Costumes/Décor/Scenery)
Dimension Question: What Scenic Design disciplines are used in the game?
Asset Question: To what Scenic Design discipline does the asset belong to?
Description: The

You must be registered to see the links

dimensions come from theatre, film and television scene design. Scenic designers design

You must be registered to see the links

and scenery that aim to support the overall artistic goals of the production. There has been a consideration that scenic design is also

You must be registered to see the links

; however, more accurately, it is a part of the visual production of a film or television.
Note:

In Theatre and Film every Scene has a
You must be registered to see the links
, meaning a location at a specifically set time.
You must be registered to see the links
are all the items that form a
You must be registered to see the links
of a Scene, including Scenery, Décor, Fixtures, Furniture, Ornaments and Costumes. Set design is the creation of the set of a Scene encompassing all the Scenery and Décor.
The Scenography assets are related to Props and Locations in a similar way as Characters and Supernumerary, in that one category is much more important then the others for the story.
You must be registered to see the links
are actors that are in the scene, but are usually in the background and are there to make the scene believable. Supernumerary is a Theatre term. In Film they are called
You must be registered to see the links
's or "atmosphere", "background performers" or simply "background". They exist and may have multiple assets associated to them, but should not clog up the character list.
The Characters and the Supernumerary generally form together the
You must be registered to see the links
of a film. For a theatre play
You must be registered to see the links
that denotes the characters each actor plays, as it usual for actors to play a big part in the foreground and some small costumed parts in the background. For a game there may be other characters in another release or in a specific scene only used there.
You must be registered to see the links
are pieces that are part of the Character of Supernumerary. Examples are
You must be registered to see the links
for police, militarily or emergency services, doors and windows, but also
You must be registered to see the links
emphasizing comfort,
You must be registered to see the links
for business,
You must be registered to see the links
for
You must be registered to see the links
expression and
You must be registered to see the links
in accordance with
You must be registered to see the links
.
You must be registered to see the links
are pieces that are part of the Décor. These are also called
You must be registered to see the links
, but Ornaments is more distinguishable from Décor. The player can look at these items, but not put them in the inventory. Examples are painting on walls, flower pots, standing lamps and other
You must be registered to see the links
.
- You must be registered to see the links
  that are not intended for display, but not use by the player, like plates, knives and fork on a table are also ornaments. In film this distinctions can give issues. An actor picking up a knife from a table during a scene transforms this ornament to a prop, while the untouched plate and fork remain ornaments. Hollywood (union) regulations demand that the touched knife falls under the
  You must be registered to see the links
  and might be created by a
  You must be registered to see the links
  , while the untouched plate and fork fall under the
  You must be registered to see the links
  . For game development these regulations are not an issue and assets should be put in the folder that has the most cohesion.
You must be registered to see the links
, also called Special Effects or FX, are special things, that are a separate concept or part and not a state of something else. Often these can be used with multiple Characters, Props and Locations. It can be a number of things:
- An item that is separate from the Characters, but are too short lived to be Props. For example, arrows flying from a bow, a boulder slung from a catapult or a firebolt flying from the hands of a mage. In a game, often these items appear, do their thing and disappear again.
- An formless thing that is separate from the Props, Ornaments or Furniture, but has a relation to it. For example, for a heart that gets lit, the fire in it is an Effect. A bauble that get polished may have the effect of "Bling!". A water fountain may have an effect of running water when switched on. These could also be states of the Prop, but is simplifies the design of the Prop, when the thing is considered a separate effect.
- A general concept influencing a Location as a whole, like nighttime, rain, a curse or enchantment. These could also be states of the Location, but is simplifies the design of the Location, when the thing is considered a separate effect.
- An effect may also be defined as something that is not a state of the thing as a whole, but of a part, like the wheels spinning on a bike.
- Multiple Effects can be combined with a Prop, Location or Character, while a Prop, Location or Character can only have one State it is in. States can be refined into specific descriptions of situations like a location that has the state NighttimeRainWithCampfire, but it may be simpler to have a location that has the Effects of Nighttime, Rain and a Campfire going.
You must be registered to see the links
are movable pieces that are part of the Décor and support various human activities, such as seating, storage and sleeping. Examples are chairs, sofas, benches, tables, cabinets, bookcases and beds.
You must be registered to see the links
are not movable pieces part of the Décor and support human interaction. Examples are light switches, lamps, sinks, fountains, bathtubs and windows.
You must be registered to see the links
is the HUMAN MADE backdrop of a location. Examples are interior obstacles like walls, doors and windows, but also the outside facades of buildings, roads and bridges.
You must be registered to see the links
, also called Flora, is all the
You must be registered to see the links
life present in a particular region or time. It is called Plantae instead of plants, because algae, mushrooms and fungi are also part of it. Examples are interior plants like plants in pots, flowers in vases and fruit in baskets, but also the outside plants like
You must be registered to see the links
,
You must be registered to see the links
,
You must be registered to see the links
and
You must be registered to see the links
. Plants that do not obstruct the player by forming part of the walkable area, like grass, flower beds and cornfields are probably better put under Terrain.
You must be registered to see the links
, also called Fauna, is all of the
You must be registered to see the links
life present in a particular region or time. It is called Animalia instead of animals, because fish, mollusks and insects are also part of it. Examples are interior animals like cats, dogs and rats, but also the outside animals like, birds, bears, and deer.
- Note that these animals are part of the Scenery and backdrop. When these animals play a role in the story then they are Characters or Supernumerary. Many
  You must be registered to see the links
  story features animals acting like humans. Some animals may have a big character parts in a story like
  You must be registered to see the links
  and Free
  You must be registered to see the links
  .
You must be registered to see the links
is the horizontal dimension of the background of a location. Examples are the (tile) natural terrain like rivers, grassland, mudflats or desert sand, but also man made terrain like canals, streets or crop fields.
- In theatre, the floor is where the actors play on. A concert or festival is held on the grounds.
- In gaming the importance of the terrain is dependent of the camera angle. In a strategy game the terrain is very visible by the choice of the camera angle high up in the sky. The terrain is probably important for the game mechanics, as it determines what you can do as a player. In many first person shooters the most important thing about the terrain is stopping the player from endlessly falling down, as the camera is hardly ever focused on it.
You must be registered to see the links
is the vertical dimension of the NATURAL OCCURING background of a location, also called a vista, landscape, cityscape, seascape or skyscape. Examples are Forests, Mountains and Hills, but also the urban sprawl, the clouds or an ocean view.
- Scenery can be created by
  You must be registered to see the links
  that use procedural generation to create landscapes.
- You must be registered to see the links
  are painted canvases lowered from the ceiling, also called flats or wings. The things depicted are in the far in the distance, thus there is little difference between the painted and real versions for the viewer.
For all the Scene Design folders in the Scenography folder goes that they can be can be omitted when there are little or no generic assets.
- Many Visual Novels will not have any assets in the Scenography folder, because their menu choices make the player jump to the location where the next scene takes place. When the location is rendered or drawn as a whole there are no distinguishable Scenography objects.
- During development a Visual Novel may have may Scenic Design assets being used in rendering the scenes. These assets are not included in the release, because the game only needs the final renders to function. In that case the working folder structure would be much larger then the release folder structure of the game.
- Point and click adventures will probably have set piece assets as many places have distinguishable objects and places will look similar.
- RPG and JRPG will almost always have them, because they are a walking around simulators that have many places, that look a lot like each other, to make the world feel big and real.

Pro:	It's quite a detailed way of organizing assets, in a way that is in line with the well the established industries of Theatre, Film and Television. It should be easy to pick up for people as many of the terms are in general use and there is plenty of examples and documentation around.
Con:	Some of the names can be confusing for the uninitiated.

Name: The State-Action-Performance dimension (Emotions/Activities/Processes)
Dimension Question: What options has previous dimension answer to be, do or perform?
Asset Question: What is the asset pretend to be, do or perform related to previous dimension answer?
Description:

A State is what someone or something IS.
An Action is what someone or something DOES.
A Performance is wat someone IS DOING.

A State or Performance is enduring and an Action finishes. For instance, the Hero can be in the "drunk" state or perform the action of "having a drink", but the Hero can also do a "drinking" performance keep that up until he is in another state.

The assets in the "drunk" folder should reflect the Hero's "drunk" state and probably consist of Images and Background sound.
The assets in the "drink" folder reflect the action of having a drink and probable consist of an Animation and Sound Effect.
The assets in the "drinking" folder reflect the performance of drinking and probably consist of a LOOPING Animation and LOOPING Sound Effect.

A State is exclusive meaning that a state can NOT be part of another state, so a state folder CANNOT be below another state folder. If 2 states are similtanuasly valid a new state is created. For instance, if the Hero is "drunk" and in "love" the state he is in is "drunkInLove", which probably looks and sounds different from "love" and "drunk".
A Performance or Action can be under a State, but it can create strange combinations for instance, combining the "asleep" state with the "eating" performance, but something like "walk" may be fine.
Note:

The state action dimension is not needed much for most asset folders structures as the dimensions above them are fine grained. The exceptions are usually the Hero, Sidekick and Villain characters, the Home location and the McGuffin prop, if you have them, as these are central to the story and probably have many associated assets.
The states, actions and performances can also function as scaffolding to remind the Artist that these folders should be filled.
Although there are differences between States, Actions and Performances your programming language will only see paths to assets and the assets themselves and the programmer defines what happens to them. The naming of the States, Actions and Performances has to only be so good as to be recognizable by Artists and Coders.
It's possible that a tool could analyze your Game Assets Structure and create variables and objects in your favorite language code, but creating States, Actions and Performances in code would be exceedingly difficult.

Example: drunk, dancing, drinking, fighting, eat, sleep, drunk/driving/eat
In the images below the Protagonist can Fight, Dance while Drunk and Eat while Texting and Driving.

You don't have permission to view the spoiler content. Log in or register now.

Pro:	It's a way of further dividing an overflowing folder.
Con:	It's too much in many situations.

Extra Note:

When everything is opened up a Dimension far in the folder tree like the State-Action-Performance will get lost in the clutter.

You don't have permission to view the spoiler content. Log in or register now.

The image below shows 4 releases as an example a full-fledged structure could be divided.
- Most of the folder remain in the core as things like UI in the unchangeable static folder and the overridable base folder are created up front. The initial version will simply not work without a UI and some base characters.
- However, the Yoda character is added in release v002, as the story progresses.
- In release v003 there is the midpoint, then a lot happens and then there is the final showdown. Note however that starting from release v003 the LoveIntrest character is AVAILABLE, suggesting the she will feature in multiple scenes. Also, the Gym location has been included, suggesting that the Gym is an OPTION starting from that release.
- The v004 release contains the epilogue and a side story, implying that the creator created some extra content and polishing.

You don't have permission to view the spoiler content. Log in or register now.

Name: The Component dimension (Expanding on the previous Dimension)
Dimension Question: Of what parts does the previous dimension answer consist off?
Asset Question: To what part of the previous dimension answer does the asset belong to?
Description: Group assets by the component they are used in. Essentially the same as the Component approach, but inside other folders. Components in this sense are NOT just technical components. The path "assets/core/base/characters/hero" where the answers of the component question would be located actually asks "Off the core release assets, off the base story development, off the characters, off the hero what components does he consist of". The hair of the hero could possibly be a separate part of the hero, the parrot on his shoulder or possibly his clothes.
Alternatively, you could phrase the question of the components dimension as "What is IN the answer of the previous question?" or "What does the answer to the previous question CONSIST off?".
Note:

The component dimension may be moved into the spot of the State-Action-Performance dimension if the state is "normal"
This is related to Object Oriented software development and is a more engineering approach to game development.

You don't have permission to view the spoiler content. Log in or register now.

Example: map, world, character fights, character dialog, dialog boxes, reports, cut-scenes, but also Hero, Villain and McGuffin parts.
The Mentor_Yoda folder in the image below is a component of the characters of Scene 006 of act3 of the core release means that the Yoda character only appears in the game in Scene 006.

You don't have permission to view the spoiler content. Log in or register now.

Pro:	It's easy to replace a component in a project with another one or move it to another project as everything related is grouped together. It's easy for a specialist in a component, for instance, the specialist for cut scenes or the fight action, find "his" folder, but this is only relevant on extremely large projects.
Con:	When things like a hero should be consistent across the game, components make that difficult because they are essentially their own little world. Also adding and removing characters is more difficult as they have to be added or removed in multiple places.

Name: The Functional dimension
Dimension Question: What functions are there in the game?
Asset Question: What function does the asset perform?
Description: Putting all the files of a type in the same folder. Essentially the same as the Functional approach, but inside other folders.
Note:

Most often used way of grouping files especially when starting out. Also used for websites and other small projects.

Example: audio, image, video

Pro:	It's easy to implement. Sometimes useful to divide a mountain of assets especially animation stills, although a folder for an animation is better off with a descriptive name of the animation.
Con:	It's seriously lacking as a method of dividing assets in smaller chunks as most assets in a game are images. It's redundant, because most assets have a type extension. It's cumbersome to have to go down a folder, that adds little information to the assets.

Name: Self describing filenames
Dimension and Asset Question: What would identifiably describe the contents of the asset?
Description: The name of the file says something about what is contained.
Example: Hero.PNG, HeroHappy.PNG, HeroAndAntogonistClash.PNG

Pro:	Makes your life easier when done right.
Con:	You have to think about how to describe the asset. Giving all your assets a number is faster.

Name: Related file dimension indicated by filename prefix (Cut-out naming)
Dimension and Asset Question: To what other file does the asset belong to?
Description: Naming the file after the file it's related to. This is common for cut outs where the smile of the face belongs to the face, but is a separate file that get projected together during the game. By starting with the same name, the related files will be next to each other in the sorting of the files. Skipping between files in an image viewer will give you an idea of where the smile will land on the face.
Example: Hero_Smile.PNG, Hero_Eyes_anim1.PNG, Hero_Eyes_anim2.PNG

Pro:	The files are next to each other and it's clear that the image is related to the other image.
Con:	The filenames get longer.

Name: Incremental animation still numbers by filename postfix (Animation numbering)
Dimension and Asset Question: What number is the asset in the animation?
Description: Appending a number to an image that functions as an animation still. A full animation is a row of image stills.
Note:

Some animation programs will do this automatically for you.

Example: Hero_Jump1.PNG, Hero_Jump2.PNG, Hero_Jump3.PNG

Pro:	Easily done with cut and paste or your animation app. The name of the animation is visible in your image viewer.
Con:	Having a folder, named after the animation containing only stills with a number, might be more efficient, but that's less clear and you need to go into the folder to see.

Name: Denote the filetype by dot extension filename postfix (file extension)
Dimension and Asset Question: What (MIME) type is the asset?
Description: Add a dot with a filetype ID to the end of your file. This is generally automatically applied by creative programs or your OS. You could invent your own extensions to disambiguate what sort of file it is. For instance, you could add ".still" to a PNG image that is intended as a still image of a video and associate that extension with an Image viewer optimized for viewing video stills. This would break stuff on a machine that does not have such association. A more refined strategy would be to add ".still.PNG" or ".cell.PNG" so everything keeps working on all machines, but you know what is meant.
Note:

This dimension competes with the functional dimension, as both try to explain what function the asset has in the game.
For DOS the filetype limit was 3 letters. Linux and current day windows to not have this limit. For all Operating Systems ".HTM" is the same as ".HTML".
Creating an alternative extension for the same file type has multiple examples. For instance, Silverlight apps had a ".XAP" file extension, but where ".ZIP" files to associate them with starting Silverlight. A similar trick is done with ".CBR" and ".CBZ" which are ".RAR" and ".ZIP" files, but should be opened by Comic book readers instead of those that generally handle ".RAR" and ".ZIP".
The email MIME types are the file type standard when sending a file through email. Email is supposed to work across Operation Systems, so MIME has become the general standard.

Example: Hero.PNG, Hero_Walk_1.cell.PNG, Hero_Walk_2.cell.PNG, LightningStorm.still.PNG

Pro:	It's easy and generally automatic.
Con:	The filename is longer. An extension like ".still.PNG" may puzzle some.

4. Considerations
4.1 Do not create folders with too little content
It's generally beneficial to have a wide instead of deep Game Asset Folder Structure. Folders with no or little content should be avoided. As a rule of thumb, also used for .Net namespaces is a minimum of 3 to 5 or more items in a folder, depending on the correlation of the assets. This improves overview of the assets and does not hide things unnecessarily.

An exception to the "Do not create folders with too little content" rule are folders that have high probability that they will be used eventually, like DeveloperCredits, Manual or CompletionStatusReport. They function as reminders of your work.
Another exception is for concepts that are important to the game but you do not have assets for when starting out, like Antagonist, McGuffin or ShowdownLocation. These are also reminders of your work, but do complicate development a little earlier.
Also "standard" folders like those in the Core Knowledge dimension, named "descriptions", "elements", "determinations" or "groups", may not immediately get filled, but they function as scaffolding to your work. As they are clearly defined and there are only limited number of them, they won't confuse anyone.

4.2 Do not have too many assets in 1 folder
It's generally beneficial to NOT have so many assets in 1 folder that you can't view them at one glance. If you have tens or even hundreds of assets in 1 folder you be searching like a mad man.

4.3 Managing folders with too little content by moving descriptions from the folder to the file
When a folder has too little content, consider integrating the name of the folder into the filename as a prefix and move them to the parent folder, so the folder can be removed. The name of the folder is the answer about a Dimension of the assets and thus can be seen as an adjective to the filename. The prefix will keep the files together in the sort order of the parent folder

4.4 Managing folders with too much content by creating a folder based on adjectives and move matching files into it
The reverse of the solution for a folder with too little files can be done if the folder has too much files. To declutter the folder, cluster the files with the same adjectives into a new folder named after the adjective. This reduces the number of files seen at once and moves the description out of the filename into the folder path.
It's common that the filename has no adjective to cluster around. Then one has to examine the files and come up with one or more adjectives to divide and conquer.

4.5 Support quick comparison
The sort order in the folder is important as that enables quick comparisons. Grouping files by prepending something to their filenames is a common practice.

Being able to compare file versions side by side and thus quickly judge if the changes are an improvement, is most easily done by having multiple versions of the file worked on saved with a postfix version number. For instance, figure_v01.png, figure_v02.png, figure_v03.png in the same folder can be put into a slideshow to see the progress of the figure.png file, much faster than any the UI of a version control system can. The folder with the multiple versions may be considered a "Working" folder and the final version may end up in its parent folder or somewhere else.

4.6 Support consistency by putting things that belong together near each other
Often an artist has to keep a Character consistent throughout the game. This concern is simplified if all things related to that character are put in the same folder. In another case the Scene is distinct from the rest of the game making it the nucleus where all related things should cluster around, thus everything related to the Scene should be in the same folder.

4.7 Functional folders are of limited use
File extensions identify the type of the file quite clearly making functional folders like audio and image redundant as an indication method, although it can work as a division of labor for the Sound Technician and Graphic Artist.

4.8 Consider using English for your file and folder names
Artists are generally internationally oriented and the game business is very international. Amateur and Indie game developers live partly on the internet, because it's unlikely that somebody sharing their interest is located locally. Therefor English is used extensively.

As your asset folder is essentially open to many eyes, it would be better to use English to name your files and folders. It better to accept reality and be proud of your work then to cower away and hope no-one notices what you are doing.

Security by obscurity is generally a bad idea. Using the big alternative languages like Spanish, Italian, French and German will not give you security. Languages such as Russian, Chines and Japanese are also common in gaming. For most languages there are translators like Babelfish to overcome the obstacle you erected.

Off course you can do whatever folder and file naming you are comfortable with, but using English would scale better. You simply increase the change someone can help you out when you are stuck or need some extra development power.

4.9 Consider mimicking your working folder with your game folders
It makes sense to keep Working and Final versions separate. This will prohibit you accidently messing up or destroying work that was already Final. It does double your game assets, but disk storage is cheap and plenty these days. Although if your saving multiple work versions of your asset, the ratio of working and game assets improves, but your disk use will be even greater.

Separating your working assets from your game assets could be done by:

separate folders - subfolder for working versions of the file
mimicked folder structures - root folder changed from core to work the rest the same
separate branches - Hides other assets on another branch. Fine for code, unnatural for assets as you want an overview of the assets.
separate repositories. - The same as the mimicked folders, but stored differently

Of these mimicked folders is preferable. This can be done by having a "core" and "work" root folder while the folder structure in those 2 folders is the same. This has the advantage that you know for sure where you have to put your final version of your work asset. There is also a lower risk of accidently including working files in a released game.

4.10 Consider stripping or converting your working assets into game optimized assets when putting them in game folders
Working versions of drawings generally have much more features than a final version. Final versions are generally optimized for display and stripped of all baggage. Common features in Working versions are:

For working images, a layer with colored boxes functioning as a color pallet is common among designers.
For working images, it is common to have layers that can add or remove features of the image, to see what looks better together.
Working 3d models generally have a high polygon count, while those put in a 3d game have a reduced poly count. This is because in a 3d game multiple models have to be shown at once and rendering is time constrained. In a prerendered Visual Novel there is no such constrained, but then just the images instead of the 3d models should be included.

4.11 The Game Asset Structure should support multiple artists collaborating
There are specialists for audio, video and graphics design in game development even at the amateur level. This gives a natural division of labor in game development. However generally there is much more image work in a game than anything else, creating a need to further divide the image work. When artists are collaborating there will arise some logical scheme, around components, scenes, characters or something else, to not be in each other's way.
Ideally the Game Asset Structure should support that by having folders that can clearly be identified as belong to the work of a particular artist. Having guidelines and using the answers to the Dimensions as shown in the path to the file to determine if the file should be changed or created by which artist.
For example, one could designate all the images in the acts and scenes as the task for the render specialist, designate everything in the base folder for the figure dialog specialist and everything in the static folder for the UI specialist.
Alternatively, if you have someone who is really good with figures and another with inanimate objects, the first could be limited to the base characters folder and the Acts and Scenes folders, the second could do the locations and props. This would create a handoff if the locations and props are also needed for the Acts and Scenes.
Another alternative is to have a division between the Scenography and the rest. The Scenography is mainly background and less important for the story, but contains a lot of assets, thus a lot of work that can be of lesser quality. The Scenography is ideal training ground for those who want to practice creating assets.

5. Technical issues
5.1 Ignore the file path length unless it's cumbersome
A file path, the filename plus all its parent folders prepended, can be 255 chars long on Windows, but there is no such limit on Linux or Mac. The contents of ZIP or RAR files is probably not limited to 255. The variable name length in you programming language is probably limited to 255.

Normally the length limit of a file, path or variable is not something you will hit, unless you're doing something special. The only time it was a problem was a TFS C# build street with CI/CD and even for that was solved ages ago. This means you do not have to truncate or hash your names like we did in the DOS days. The esoteric knowledge of the names may make you feel special, but it will start to hinder sooner than later.

Adding some adjective to a folder name like Hero_Tom or McGuffin_Scepter may clarify a lot. Overdoing it like Bob_the_policeman_you meet_in_act2_scene34 is cumbersome and unwieldy. The same goes for a too deep folder structure too.
Being critical of the naming scheme can keep the assets making sense, when your game gets large.

5.2 Use LFS when putting binary assets in a Version Control System
Binary files like Assets in a Game differ from text files like code and data formats, because it's hard to diff them. Storing diffs in a Version Control System like Git is pointless as graphics and sound change greatly by tools and automatic compression. Git and GitHub support the Large File System (LFS) repositories who do not diff the files, but store them as a whole, making them more useful for assets and could be thought of as asset specific repositories.

5.3 Take note of build in change tracking
Many formats have built in change tracking and layering, like for instance, Adobe Photoshop files. Putting these files in a Version Control System could be unhelpful as one type of change tracking gets in the way of another. Artist may simply prefer using the Adobe system over the "Code" git system.

The files with change tracking are generally complex working files and should be converted to a striped format before being put in the game folders. These striped files are generally more optimal for in game use, as the complex options are not available for the game.

6. Tests
6.1 Assets of Lust Town
I have tested my ideas on the "Lust Town" assets, as the creator of that game is deceased. The game holds more assets and the assets are more diverse than originally expected, even though the expectation was that it was large. The game did not look particularly larger than other successful visual novel games, so my deduction is that Visual Novel games are deceptively simple, but the successful ones are quite big.

Although Lust Town may not be representative of a typical Visual Novel, as the author started out with RPGM and moved to Ren'py it does give an indication of a full-fledged game. I believe the author wanted to do something cinematic, by using many rendered images in Ren'py, but he started out with generic "playing doll" figures doing dialog. A fully cinematic rendered Ren'Py game may not have any generic figures in the base folder. A game with only figure dialog could omit the Acts and Scenes. Most JRPG games will cinematically render key scenes and leave the not so intense ones to figure dialog, as this saves space and effort.

You don't have permission to view the spoiler content. Log in or register now.

Because this was a reverse engineering effort the number in the scenes is low. When developing a game one would probably not split things up so small. Also, I was not able to move scenes out of Act 3 as it was not clear how the story progressed.

6.2 Assets of a Master of Magic a Civilization clone with 4X and RPG elements
The ideas of the Theatrical approach are also tested on an asset repository for Master of Magic (MoM) a classic Civilization clone with 4X an RPG elements, first released in 1994. It has a cult following, so much so that it recently received an update after more then 25 years. The sources of the assets are the extensive wiki with enhanced graphics and a multiplayer rewrite called Master of Magic - IME with the original graphics.
I expected the amount of assets to be huge and they are, but it generally conforms to expectations. I originally intended to convert the bitmaps to infinite scalable SVG files, but tests revealed that doing the steps in the asset pipeline takes quite a bit of time. The expectation is that converting all the assets is such a large body of work that it's not a fit for a an amateur anymore.
The not confuse the asset sources multiple root folders where introduced in the assets:

the 2svg folder containing the assets converted to SVG
the 2vox folder containing the assets converted to voxel 3d
the comw folder containing the assets from Caster of Magic
the core folder containing the core assets of the game,
the ripped originals from MoM-IME and OpenMoM
the cvzd folder containing the ripped assets from Civezard the Japanese only remake
the wiki folder containing the blurred and resized assets of the wiki
the work folder containing the complete backup of all the other folder, plus the working versions of the SVG files.

Those folders mimic each other's folder structure, so a change to the folders done in one has to be also done in the others. This is cumbersome when reordering the files and folders of an existing project, but once the assets are structured in the Theatric approach they are less affected by changes in the game and much easier to find.

You don't have permission to view the spoiler content. Log in or register now.

The genre crossing of MoM makes the assets span a wide variety of vantage points. The originals are named with a terse DOS naming style and the rewrites use a Component approach with descriptive adjectives like map and overland map.
The Theatrical approach puts assets from components like the map, isometric fight scenes and cityscapes together. This is great for consistency, because the different views of the characters, locations or props can easily be compared. The components do need a way to recognize the assets usable by them. Therefor a specific naming scheme with adjectives for the images was devised that centers around the viewpoint of the image. The adjectives for the specific vantage points used are:

iconic – the icons that replaced projections – map view cartography screen
looking from a satellite things are too small to see so icons are used
perpendicular – the top-down oblique projection – overland view
it is perpendicular to the ground looking downward used in the main map screen
aerial – the isometric orthographic projection – oversight view
it oversees the units when fighting
panorama – cabinet oblique projection – cityscape view
it overlooks the buildings of the city
scenic – elevation orthographic projection – scene view
it looks at a scene like exploring a cave from an upright position
portrait – elevation orthographic projection of a character – communication view
it looks at characters from the bust up, also used for selections
mugshot – elevation orthographic projection of a character – details view
it looks only at the face of the characters for identification, also named headshot
zoomed – dimetric orthographic projection of a character – cut scene view
close-up in intimate or intense scenes like an intro or end

You don't have permission to view the spoiler content. Log in or register now.

Master of magic - IME is a game that has been going from at least February 2006 according to the Forum. This explains the massive size of all the code as it has been added on during the years. The images ripped from MOM make up the bulk of the client, but are relatively small compared to todays images. Putting the assets in an archive would have made sense in this case. The many small images being used in the game mechanics has to lead to a refined folder structure otherwise it becomes a maze.
It does not become immediately apparent that the assets must be divided over alternative folders when reordering the assets by simply shoveling the folders around from the original Component approach to a structure more inline with the Theatrical approach. When looking at the assets one by one, it becomes clear that a more refined structure is needed. This especially so around spells and their effects as these are tied together by the game mechanics, but that can land in a number of places:

The spells themselves are choices in a wizards spell book, falling under determinations
spell effects that are ranged, like lightning and firebolts, fall under effects
spell effect influencing the attributes of a unit, hero, city or global lands, like enchantments and curses, fall under descriptions
spell effects that summon a fantastical creature fall under Supernumerary, as creatures are not unique units thus treated as extra's
spell effects of call hero or champion fall under Characters, as hero's and champions are Characters.
spell effects that summon an item, like a magic sword fall under Props, as items are Props.

It seems that the creator of Master of magic - IME got in trouble over the spells as the ordering is less consistent even for the Component approach. It's probable that the devil in the details has something to do with the game not being ready after more than 15 years.

6.3 Asset management with 2 repositories and an ID-Asset list
It remains to be seen if I continue with these projects, but they thought me that the folder structure is important. I intend to create asset LFS repositories and code repositories for these games and bind them together with an ID-Asset path list defined as Yaml, Json or XML. This would add a layer of indirection effectively decoupling the repositories. Changes in the asset folder structure would have no effect anymore on the game, although tooling analyzing the asset structure would still break. Coders and Artists would no longer be in each other's way. As all files are binary the difference between code and assets is mainly the standards followed. Adding an open standard to convert ID's to an asset path, so it would work for all game engines, would logically be the next step to open standards like PNG or Webp.

7. Experience
7.1 Seeing professional at work
I've been programming for decades and involved in Multimedia and Games for some of that time. I'm not a full-time artist, so there will be people that know things better than me, but I have dabbled in that trade and watch them work.

7.2 Checking out game asset folders
I've also been looking at plenty of game asset folders from this site.
Reasons I have had for checking the assets are:

Many times, it's faster than trying the game to see if it's any good
Some games are broken or won't start
Some games have an unplayable UI or illogical puzzles
A rebuild or engine port may be in order
I was curious about how it's done or the experience level of the developer.

I know many other people are doing this too and most developers know it is something that is watched.

7.3 Some Indy developers are aware
On a related note, I saw a friend of a friend, state on LinkedIn that he decrypted the assets from the Noita Linux version encrypted with AES because they left the key somewhere in the game files. He contacted the game developers, waited with publishing his findings until 6 months after the games release. The 6 months when the game has to earn its investment back. He got his name in the credits of the game and a goodwill package. It also happened to a number of other hackers of that game.

7.4 The Open Game Asset Structure is a fact
Game developers should consider their asset folder is open for many to see. A fact I call the Open Game Asset Structure. This is so weather they like it or not.

7.5 The field contains some painful situation
I regularly see painful situations in the asset folder of a game. Not that I'm judging anybody on how they organize their folders. Certainly, amateur or beginning developers can be held accountable for what they don't know. I hope to help developers with this article, in order to making creating a quality game easier.

8. Observations
Some observations of and about doing Artistic work. Skip if you are an experienced artist or developer. Artists who have a different opinion or things to add, please let me know!

8.1 Rendering figures with a standard set of emotions and poses makes the story less rigid and could be more efficient
Changing tasks takes time jumping from rendering a character to a prop to a location and back to the character because he needs a different emotion or pose is more cumbersome then rendering the character in different poses and emotions, then switching tasks. Having a folder for each character that contains them in a number of standard poses and emotions, makes them more like actors that can be instructed to behave in certain way. This makes the story also less rigid as a change in story can be supported by a set of standard poses and emotions.

Facial expressions, while not very common in Indy and VN games, the odd exception here and there, are
You must be registered to see the links
. Depending on the research limited to
You must be registered to see the links
,
You must be registered to see the links
,
You must be registered to see the links
or
You must be registered to see the links
expression, but there are
You must be registered to see the links
like
You must be registered to see the links
used in AAA games.
Posing figures are common in Visual Novels, but generally a limited set is used. Search for
You must be registered to see the links
and you will find a many examples, same for
You must be registered to see the links
. For photography poses there are
You must be registered to see the links
poses,
You must be registered to see the links
for
You must be registered to see the links
, and for women
You must be registered to see the links
,
You must be registered to see the links
,
You must be registered to see the links
situational poses and some basic ones, like a basic
You must be registered to see the links
.
There is also a distinction between Full figure statue, bust and face determining how intimate a character is. In Visual Novels the full figure statue is used most of the time.

On the whole, picking a set of standard poses for each character and creating those in advance may be more efficient then going back and forth.

8.2 Have an idea of the size, scope and context of the game to determine your Game Asset Structure
Having an idea of the size, scope and context of a game will influence which approach to take with your asset structure. It may also do wonders for efficiency and artistic work would be no exception.
To make your vision of the game EXTREMLY clear, so you can do some estimation, do the following steps:

Write a
You must be registered to see the links
. A line consisting of a protagonist, inciting incident, setting, antagonist, a conflict and a goal. A TV guide is great for having many examples. For a game a second line may be added labeling the genre, detailing some of the game mechanics, describing the feelings it tries to elicit and possibly its impact on the gaming world.
Create a
You must be registered to see the links
to show that the story has forces propelling it forward. A story also has connection between the parts instead of just being a situation with a number of separate episodic moments. A story may also be thematically pulled together or the protagonists character flaw may be interesting to addresses. Many may think this is highbrow, but many may also realize that, when they tell a factual account of what happened to an authority figure they go point by point and when they tell an entertaining story they probably leave out what they ate and when they went to the toilet, because it's not relevant to the story and boring for the audience.
Flesh out your idea in short easy to change form. (So, you don't have to murder your beautiful descriptions or brilliant dialog because it doesn't fit the plot.)
1. For those who like to keep it simple, write a
  You must be registered to see the links
  with plot points.
2. For experienced writers, do an
  You must be registered to see the links
  to not get lost in the woods and to have something that can be read and judged by stakeholders. Possibly done with a canned method like
  You must be registered to see the links
  or a more lose method like
  You must be registered to see the links
  .
3. For a more by the numbers approach use a
  You must be registered to see the links
  (
  You must be registered to see the links
  ).
4. Although common after the story is done, you could write a
  You must be registered to see the links
  or
  You must be registered to see the links
  half way through.
If you're interested in the scenes and dialog write a
You must be registered to see the links
script in
You must be registered to see the links
using the open source
You must be registered to see the links
or the more pro
You must be registered to see the links
and
You must be registered to see the links

You must be registered to see the links
.
1. If you intend to do something cool with the camera, which is common in Manga, Anime and work influenced by them like the Matrix, consider creating a
  You must be registered to see the links
  with for instance,
  You must be registered to see the links
  . Unfortunately, unconventional cinematics is extremely rare in games, whether Visual Novels or games with more mechanics. In one way this could be because Game Engines may not support novel camera angles. In another way it could be that a lot of effort is focused on increasing the immersion, with may be antithetical to a Sci-Fi, Fantasy, Horror, Drug tripping movie intended to show you something wild and strange.
If you're interested in the branching of plot, you could convert your linear story into branching narrative and test it out in a
You must be registered to see the links
or as
You must be registered to see the links
(IF). IF can be written in a story format
You must be registered to see the links
(
You must be registered to see the links
),
You must be registered to see the links
,
You must be registered to see the links
,
You must be registered to see the links
. IF can also be written in a format with dialog speaker tags like
You must be registered to see the links
and generally more modern
You must be registered to see the links
and
You must be registered to see the links
. If you like a tool for branching stories there is
You must be registered to see the links
or
You must be registered to see the links
.
When you start working in
You must be registered to see the links
, Gamemaker, RPGM, Fungus or one of the others, you copy all the scenes in 1 go, but close of the scenes that do not have any assets jet as to keep the suspense for the player.
If you want to limit the work needed, determine what assets must be highly detailed, because they are important for the story or cinematics and what assets can be done in a minimalist way, because they are part of the background.
1. Voxel background graphics are a great way to reduce the work needed on the background, while still being viewed as high quality, sharp and modern. There are free asset packs like
  You must be registered to see the links
  that can fill up your background fast. You can create missing things with tools like
  You must be registered to see the links
  (
  You must be registered to see the links
  ),
  You must be registered to see the links
  (
  You must be registered to see the links
  ),
  You must be registered to see the links
  (
  You must be registered to see the links
  ),
  You must be registered to see the links
  (
  You must be registered to see the links
  ).
2. The background graphics could also be of lower quality and have a
  You must be registered to see the links
  applied to it to mimic the
  You must be registered to see the links
  effect. Bokeh is often highly desirable in photography as it draws attention from the background to the foreground. This may also be an effect of the need for bigger and better lenses to create a good Bokeh effect. The "good" Bokeh effect blurs the image in a way that is pleasing to the eye, while the "bad" Bokeh produce distracting or unpleasant blurring.
If you want a consistent art style consider creating a
You must be registered to see the links
to illustrate what sort of style you want in the game or in a part of the game like a level or area. It is very simple to do as it's a collage of everything you can find that you think is relevant to the game. This can also work as a reminder when put on your wall, computer desktop or browser startup page. Creating a
You must be registered to see the links
that contains descriptions and examples is better for communicating with a team as the text conveys your intention instead of just a bunch of examples without context.
If your game has elaborate
You must be registered to see the links
like a Fantasy or SciFi game, consider creating a private
You must be registered to see the links
to maintain all the pieces of the world. A generic notes tool like Scrivener or Microsoft OneNote can also help and a specific world building tool like
You must be registered to see the links
,
You must be registered to see the links
or
You must be registered to see the links
, may do the same with extra guidelines.
To maintain a grand overview, you could put everything in a
You must be registered to see the links
(GDD) that also encompasses game mechanics, story and monetization of your professional game. This is essentially a game specific
You must be registered to see the links
. Having a GDD is good for team communication, but also good for communicating with investors, publishers and Patrons. For a solo amateur developer, it may simply be a checklist for things to think about.
1. An experienced game developer can get an insight in how much potential for success a game has based on what is in the GDD and what is NOT in the GDD. There are many templates for a GDD out there as the templates are viewed as helping the industry and helping publishers. Filling in a GDD template is answering questions about your game and that gives you a better understanding of what is needed in order to create a successful game. A GDD may not give you game development experience, but it may give you an inkling in what is important for game development. You can read a number of templates especially those that are similar or in the same genre as your game. The templates have much overlap, but may have specific topics and questions the creator found important according to his experience.
Create a
You must be registered to see the links
board if you want to track your progress. Having a physical board on the wall may give you a boost when you see things get completed. Digital boards like
You must be registered to see the links
,
You must be registered to see the links
or
You must be registered to see the links
can be great too as you can access them anywhere via the web. A process like
You must be registered to see the links
or
You must be registered to see the links
may help, because they cycle through iterations, periodically asking "Are we doing the right thing?", "How can we improve" and "What is most important to do next?" among other things.
Keep a
You must be registered to see the links
or
You must be registered to see the links
if you want to let others know what you have done, but also to think about your choices, the things done differently than expected and the you haven't done. This may help get insight in how things are going especially if you did NOT adopt a more formal method like Lean Startup or Scrum. The trick is not to repeat the tasks you finished, as those are on the Kanban board, but take a step back and take a wider view.

The steps to 1 to 5 are mostly writing text and thus really quick and easy to do, although some braincells may be hurt thinking about your story.
The scene closing off should use 2 checks and a global integer (INT) variable for the ReleaseVersion and a global Boolean (True/False) value for TestMode:

A check if the game is in or beyond the scheduled release of the scene. If so, play the scene, if not, do not play the scene as it's not released jet.
A check in the Scene to see if the global testing mode is set. If not, do the release test. If so, play it whether it's release or not, so you can test the whole game without everything having to be finished.

The ReleaseVersion integer checks do not have to be continues, meaning 1, 2, 3, but multiple scenes can check for the same ReleaseVersion 1.
A more sophisticated planning of releases can be discontinues, like 1001, 1002, 1003, 2001, 2002, 2003, so every scene has it's own ReleaseVersion number to check. Scenes release ordering can be rearranged, as there is space to do so. For example, a game with 9 scenes in 3 releases:

The 0.1 version sets the ReleaseVersion to 1000
1. Scene 1 checks if ReleaseVersion is higher then 1, finds it true and is thus accessible for the player.
2. Scene 2 checks if ReleaseVersion is higher then 2, finds it true and is thus accessible for the player.
3. Scene 3 checks if ReleaseVersion is higher then 3, finds it true and is thus accessible for the player.
4. Scenes 4 to 9 check on ReleaseVersion numbers higher then 1000, finds those false and are not accessible for the player.
The 0.2 version sets the ReleaseVersion to 2000
1. Scenes 1 to 3 check on ReleaseVersion numbers lower then 1000, finds those true and are thus accessible for the player.
2. Scene 4 checks if ReleaseVersion is higher then 1001, finds it true and is thus accessible for the player.
3. Scene 5 checks if ReleaseVersion is higher then 1002, finds it true and is thus accessible for the player.
4. Scene 6 checks if ReleaseVersion is higher then 1003, finds it true and is thus accessible for the player.
5. Scenes 7 to 9 check on ReleaseVersion numbers higher then 2000, finds those false and are not accessible for the player.
The 0.3 version sets the ReleaseVersion to 3000
1. Scenes 1 to 6 check on ReleaseVersion numbers lower then 2000, finds those true and are thus accessible for the player.
2. Scene 7 checks if ReleaseVersion is higher then 2001, finds it true and is thus accessible for the player.
3. Scene 8 checks if ReleaseVersion is higher then 2002, finds it true and is thus accessible for the player.
4. Scene 9 checks if ReleaseVersion is higher then 2003, finds it true and is thus accessible for the player.

For comparison, in Hollywood film production they buy a

You must be registered to see the links

that has been worked on for 3 months to 1 year, for some

You must be registered to see the links

it's years, although a

You must be registered to see the links

can be done much faster. They turn it into a movie in about 2 years. The work on

You must be registered to see the links

takes about 1 to 1,5 years, starting with the

You must be registered to see the links

, split up in shot-list,

You must be registered to see the links

,

You must be registered to see the links

,

You must be registered to see the links

, etc. The actual

You must be registered to see the links

with the shooting of the movie take 2 to 3 months. The

You must be registered to see the links

is about 3 to 6 months, with some re-shooting, extra shots and some costly CGI.

The gist is that text and planning are significantly cheaper than actually doing the work and a lot cheaper to change. Also
You must be registered to see the links
costs are generally unavoidable, while the
You must be registered to see the links
costs can be changed to fit the
You must be registered to see the links
.
Another deduction you can make is that however much work op front you do there still will be unexpected things. Having a set of character poses and emotions you can fall back on, to let the actor do what they "normally" do, could be beneficial in such a case.
Consider the list of the least to most costly things effort wise in a game. The relative cost of images seems true for rendered as drawn versions, as the underlaying assumptions are the same. The list including its assumptions are:
- Text does split in descriptive text and dialog, but both need very little to work.
- Generic Items need only 1 drawing or render.
- Generic figures need 1 or more drawing or renders as they can have multiple poses and emotions.
- Generic location backgrounds generally consist of a place and multiple inanimate objects each one creating work.
  - A minimalist approach, like using voxel art, would limit the work needed. This would also give more attention to the Characters and Story, similar to a minimalist version of a Shakespeare play.
- Specific scene images are shot on a generic location backgrounds, where figures in a pose and emotion are placed, combining the work of a generic figure and generic location. If the location backgrounds or the figure have to be customized for the scene it means even more work.
- Complete Animations are shot on a generic location backgrounds, while figures are moving and emoting, implying multiple versions of a figure. Possibly even the background is changing so those customizations are added. Animations adds a level of timing on top of specific scene images. The need to create 25 frames for every second for video level fluidity may not be more difficult than less frames, because the work is in configuring the models for rendering, not the rendering itself. When doing comic book style animation, intermediate cells can be rendered from a start and finish keyframe cell, so the work is in creating those keyframes.
Given these prepositions it would make sense to reserve the costly animations for crucial parts of the story and thus that you should know what those are in advance.
For others, rendering animation is fun and no effort at all. In that case it's tempting to animate the whole game, but consider that not animating the low-key parts makes them more distinct from the intense scenes. Avoid turning your game in a meandering movie and make the important parts stand out. This coincides with Eric Edson of UCLA unit of change definition called the "
You must be registered to see the links
". This is 3 to 7 pages, equal to 3 to 7 minutes as a page in a screenplay is a minute of movie, where a hero pursues a one term physical goal, then the hero discovers "fresh news" and start to pursue his next goal. This in addition to "
You must be registered to see the links
", the start of the story and "
You must be registered to see the links
" the start of the end of the story. This creates a story that has waves of excitement and 2 big waves overall. Translating this to a game on the cheap means that there is an intro and outro for the start and end of the story. A richer implementation has cut scenes when the player hero achieves a goal. Of course, a normal game has the game mechanics between the cut scenes, but a Visual Novel could have figure dialog just as well as low key scenes. Realize that the player
You must be registered to see the links
if the story is good. Alternatively,
You must be registered to see the links
can be used to find the most important scenes. The motivations are like forces on the characters and the characters are bouncing around in the plot. The bounces are probably important for the player, because the character has to start moving in another way.

8.3 Know if the first released version of the game is a PoC, a Pilot, a Feature or a Statement
Knowing your audience and what you intend to deliver to them, influences what will be in your initial version of the game.

A Proof of Concept (PoC) is a business or user test. It's generally done when trying out novel game mechanics.
A Pilot is the first of a series of releases. It's generally done when the focus is on the story and the styling of the assets, but you intend to follow up the story with more episodes.
A Feature is intended as is. It's generally done when the focus is on the story and the styling of the assets, but the story does not develop after the initial release.
A Statement is a game with a message. It's generally done when the game is criticizing something or showing something interesting. The focus is on the message of the game, not on the game itself.

The form of the assets is influenced by the game mechanics and the styling of the assets is influenced by the story. Being aware of the forces working on your assets can focus your efforts and omit producing assets that will not fit the game down the line.
For instance, an initial game has mechanics that are similar to a platform game situated in the jungle. The obstacles must be big enough to jump on because of the mechanics and the obstacles are styled like jungle features because of the story. Later into development the platform game mechanics are transformed and become more akin to a maze runner. The size of the obstacles must now change, because the player may no longer jump on them. To better fit to the action the game is no longer situated in a jungle, but is changed to a dungeon setting. The story can relatively easily incorporate a change in setting, because it's just text. The assets however, will need a lot more work than the story, as their theme and size does not match the game anymore. This either leads to the assets having to be redone or the assets being thrown out and new assets need to be created.
The assets of a PoC can be bad as long as the audience knows these are placeholders for the coming assets and the gameplay is fun enough for them to come back.

When the first version is a PoC for the gameplay, the assets have to be good enough to support that gameplay, but are not the main focus. The assets can change wildly while tweaking, tuning, adjusting and replacing game mechanics. In order not to throw away most of your work, minimal effort should go into the assets.
A

You must be registered to see the links

(POC), also known as proof of principle, is a realization of a certain method or idea in order to demonstrate its

You must be registered to see the links

, or a demonstration in principle with the aim of verifying that some concept or theory has practical potential. A feasibility study aims to objectively and rationally uncover the strengths and weaknesses of an existing business or proposed venture, opportunities and threats present in the

You must be registered to see the links

, the

You must be registered to see the links

required to carry through, and ultimately the prospects for success. In its simplest terms, the two criteria to judge feasibility are

You must be registered to see the links

required and

You must be registered to see the links

to be attained.
A PoC is defined in business terms like "Concept", "feasibility" and "practical potential". Games are in the business of entertaining players, so a PoC generally is about the player interacting with the game. The definition of a Poc is closely related to that of a

You must be registered to see the links

, but differs from it because of its business connotation. A Unit Test, used to verify a code unit, like an object or function, is not a PoC, because it's purely a technical test. An Integration Test, used to verify code components and units are properly integrated into a working whole, is closer to the business then a unit test, but it is not a PoC, because it's also intended to just test technical things.
For a game multiple types of PoC's can be defined:

A PoC can be used to test if the technical aspects of a game, related to the player directly, are feasible.
A PoC can be used to test if a single gameplay concept works for the game.
A PoC can be used to test if a number of concepts work together in a basic game.
A PoC can be used to test if game is fun for the intended audience.

In the initial stages of a game, technical and single concept PoC's are common, while in later game development stages, a PoC's would test if a number of concepts work together in a basic game or if a basic game works for the intended audience, verifying that the intended audience has the same ideas about what is fun to play.

When using well know game mechanics, because they adhere to the standards in a genre or they are reused from another game, a PoC is not needed. This is similar to using an off the rack camera for a movie. If a game developer doesn't want to endlessly test and adjust mechanics or simply thinks the value of the game is not in the game mechanics, the emphasis will be on the story and styling of the assets. Other games being similar does mean that comparing them is easy, so your story and styling will have to hold up against the others. An example of this is taking a standard engine like Ren'Py, adhering to the Visual Novel genre and focusing on the story and styling of the assets. Another example is taking an engine like Gamemaker or RPGM, adhering to the JRPG genre and also focus on the story and styling of the assets.

The difference between a Pilot and a Feature is that a Pilot will continue with the story in follow up versions while the Feature will only do bugfixes in follow up versions. A Pilot game, generally called the 0.1 version, is akin to a Pilot episode of a series and is intended to test the interest of the audience. A Pilot is intended to captivated the audience by providing an engine in the story to move it forward. A Pilot also has an open ending to be able to continue the story, similar to a TV Series. An example of an open-ended story in a Pilot is the hero being chased by the villain during the initial release and the hero having close calls at the end of the initial release the hero is still being chased by the villain. The engine moving the story forward is in this case the chase.
The assets of a Pilot can be sub-par as the audience will return to the game and see the improvements made, but not bad as the Pilot is judged by the audience for further interest.

A game Feature is intended as tight up story and closed to further developments in follow up versions, similar to a feature film. The game developer has finished his vision and only needs to improve the details and fix the errors that are found. Captivating an audience may be interesting for a sequel, but the game is intended to stand on its own. An example of a closed story in a Feature is the hero being chased by the villain during the initial release and the hero having close calls at the end of the initial release makes it to safety and the villain gives up the chase. The engine moving the story forward is in this case the chase, but it is closed off at the end of the story.
The assets of a Feature must be up to spec as the audience will not return to the game and see improvements made.

A game being a Statement is a game trying to say something, either about the developer themselves, about the genre or about the audience. It is intended as a message from the game developer to the world. The audience is not intended to participate in its development or even enjoy the game. The quality of such games is generally not very high as enjoyment is optional. Parody games fall in this category, as well as artistic statements, but also technical demonstrations.
A collage of stolen assets lends itself as an art style for such a game, although for instance, a technical demonstration of raytracing could shed a new stunning light on those assets.

8.4 Manage your energy level
Managing your energy level is essential for creative work. An asset structure like anything, should be estimated beneficial, tried, judged and if not quite fitting abandoned or improved. In no way should you do something that doesn't fit your work style especially if you do it for fun.

9. Acknowledgments
This article was created after I had some doubts about a long update post I did in the Lust Town thread. The hint from CookieMonster666 about using spoiler panels helped and him agreeing that structuring the folder for assets could warrant a new thread. I'm sure he didn't mean to go even more overboard than my original post, but it happened.

Sorry that this is a long post. I tried to be concise, but there is much that is related to this topic and it grows over time. I realized after a post by Volta that the content was interesting for some people, but the format was a hot convoluted mess. I have improved the format since, but there still is much to improve.

Thanks to ririmudev for making me see that the acts in my examples could be confusing. Every story has a Beginning, Middle and End, thus every story has at least 3 Acts, but many have defined more. It depends on how you define an Act. Whether you dump your Scenes directly in the Acts or use Sequences to manage Scenes is also up to the creator.
I think it's useful for a game to have "

You must be registered to see the links

", because generally the player has goals he needs to achieve in order to further the story. The Writer makes it a little easier on himself it he uses Sequences. When starting out to write you generally construct the story from ending backward. It is important to know how the story ends, as that is the feeling the player is left with after the story. Although games are often not finished by the player, so the beginning must be good too. Figuring out how a story should start is relatively easy, if you have the ending. The middle of the story is where the actual story happens. Unfortunately, in the beginning of writing the middle part it generally considered "traversing a massive empty dessert", that somehow has to be filled by your creativity. Dividing up the middle in Sequences, makes it a little easier to handle and also helps with pacing your story.

10. Conclusion
In this essay I have tried to convince game developers of the need of structuring their assets in a semantic way. I have shown multiple approaches and explained the theatrical approach in detail. Tests have shown that the theatrical approach works over multiple games stretching multiple genres. It has the benefit that assets can more easily be found and exchanged.

11. Edits
This article gets updated regularly. When multiple days go by without updating it, I consider it v1.0. This article is fully functional as the updates are mostly related to the form instead of the content.

This is a "Living" document, as it keeps on changing. A little magic happens when I press the Preview button, some more magic happens when I press Save, a day after that I again am hit with something I missed, wrote wrong or misspelled.

I changed some examples and clarified explanations after ririmudev comment.
I changed the "Functional Approach" to "Funtional of Content Type Approach" and "Component Approach" to "Domain, Aspect or Component Approach" and tried to define and explain them better.
I added the "Know if your games first released version is a PoC, a Pilot, a Feature or a Statement" chapter.
Switched the order of the Component dimension and the State-Action-Performance dimension.
Finally got around to spell check the sentences by copying the text to Word instead of relying on the browser spell check.
Expanded the stages an asset can go through.
Added the MoM assets description.
Added the optional folder for Scenery, Flora, Fauna, Décor, Fixtures, Furniture and Ornaments to the Theatric dimension for generic usable set pieces. Less applicable to Visual Novels, but very usable for RPG and JRPG's.
Created the Scenography folder in the Core Knowledge dimension to host the generic Scene Design folders. The Scenery, Flora, Fauna, Décor, Fixtures, Furniture, Ornaments, Costumes and Supernumerary folders now fall under Scenography and form the Scene Design dimension.
Based on experiences with reordering the assets of Master of Magic - IME: renamed Flora to Plantae and renamed Fauna to Animalia, because the names where confusing. Split of Terrain from Scenery for better separation. Had to add the Effects folder for separate things that are short lived or generic concepts, such as arrows and magic bolts.
Added a number of steps to get the vision of the game clear including Kanban, Mood board, Wiki and Journal.
Explained the differences and similarities of data and assets. Implications like mimicked folder structure and normal versus LFS repositories are named.
Changed the names of the specific vantage points in the Assets of MoM and added some asset folder descriptions.

12. Ps.
If you have and alternative for this article or you found a similar article please let me know. Any comments are welcome.

If you use the Theatrical approach or know of a game that does, I would love to see it. Just point me to the game and I'll crack open its asset folder.

ririmudev · Feb 21, 2021

I like the theatrical example foldering. I think it would fit a good amount of VN use cases. I'd depart somewhat, as I probably wouldn't make a VN. My ideal would be to leverage SVG for all the visuals (except maybe backgrounds). Accordingly, I wouldn't need subfolders for states like `driving` and `drunk`, since they could be applied programmatically to all characters.

Of course, my big caveat is that I'm not working on a game, because there's no guarantee that anything I've started in this realm will reach completion, or even come close. But if I were working on something that would eventually be a game, the SVG stuff is an absolute requirement. I have the proofs of concept done already, but there's a long way to go.

Um... back to the foldering, it is interesting that the folder structure would try to enforce Act X, Scene Y, as well as rising action, denouement, etc. I don't have any particular complaints, but I wonder how it would play out in practice.

Marzepain · Feb 21, 2021

ririmudev said:
I like the theatrical example foldering. I think it would fit a good amount of VN use cases. I'd depart somewhat, as I probably wouldn't make a VN. My ideal would be to leverage SVG for all the visuals (except maybe backgrounds). Accordingly, I wouldn't need subfolders for states like `driving` and `drunk`, since they could be applied programmatically to all characters.

Great reply, greatly appreciated.
Departing from the suggestions in the article is expected. Simply pick what you need and run with it. Doing a little can already help a lot.

As for SVG, I think much more games should use it especially in the amateur field. The main argument for it is that it explicitly reduces details, thus the costs to make a game. Although there are stories of vector graphics being taking much longer to make then bitmaps, due to inexperience and tooling.
Also making it unlimited scalable, not just in pixels but also in emotion. A smile keeps being a smile whether on 720P or on 8K, whether today or over 10 years. Disney movies are a great example of this. What amateur games lack in funds, they make up in time, so SVG could be a good choice for a game you intend to work on and off on.
Unfortunately Flash was the champion of Vector graphics and it is now even dumped by Adobe, it's owner. Also Mobile devices are closer to PC's now, so the Vector graphics, being a less taxing technology for a machine is less needed.
That said I think there are great things in store for SVG. The Blocky graphics from my Amiga are now Cult and

You must be registered to see the links

graphics are now a staple of Indy games. The modern timeless look of Vector graphics will come back into fashion as an Art statement sooner then later.

ririmudev said:
Of course, my big caveat is that I'm not working on a game, because there's no guarantee that anything I've started in this realm will reach completion, or even come close. But if I were working on something that would eventually be a game, the SVG stuff is an absolute requirement. I have the proofs of concept done already, but there's a long way to go.

Having proof of concepts is great. I have them with a game owned by Slitherin. Those assets took a while to do and the estimate for the complete game would be huge. That in itself is bad, but not owning the IP could mean that it was all for nothing.

Your predicament is simple. Start small.
In the chapter "Have an idea of the size, scope and context of the game" I lay out a number of steps to get to a game.
Maybe I should add some more hints on how to do that, but it comes down to having your ideas written down in such a way that they make sense. Then start cutting until you find your absolute minimum of the game. It doesn't matter if it's a VN or a game with more mechanics, just get it down to something you can make fairly quickly. (Then cut it some more as estimates are generally wrong.)
It's important to follow a process, so "

You must be registered to see the links

", but just do the work. Love the profession and the success will follow, as you can force yourself to be better in a profession, but you can't force success. Although in the end, when your really, really good, only fools will not recognize your skill and you don't need fools in your life.
I you don't have a process it helps if you have a Personality Disorder called Obsessives Compulsive Disorder (OCD). Unfortunately that either means that your seeking success like a junky a fix or feel like you have to do everything and more otherwise the world is going to end. The secret "

You must be registered to see the links

" is compassion with yourself. Just have fun with it. Don't worry if it's perfect, because it never is. Just try your best, learn everything you can learn and do better the next time.
There is of course a difference between amateur's and professionals and most people think it's the skill and quality of the work. In practice it is most of the time, because professionals do whatever they do more then amateur's and thus become better at it, but it doesn't have to be that way. The real difference is in the word profession being a derivative of "to profess" and similar to "profit" and "prophecy". As a professional you are trying to convince someone by "professing" to be skilled at a certain craft and delivering a "prophecy" of good quality results. A Professional does this to gain something, thus to "profit". An amateur does not need to convince anyone, because the profit he gains is the work and the result itself. There are many examples of amateur writers, poets and painters who where way better then professionals. You could even argue that Vincent van Gogh was an amateur, as during his lifetime he didn't convince many people that he was a real painter. That points to a general a problem of an amateur. In order to work with people, for instance on game or movie, you need to convince them that you are any good to work with. So even on an amateur project, it may be better to confess to being "a Professional that is still looking for success" or use the more normal term and call yourself a Student.

That said, the initial core version is still a big hurdle to take, so beg, borrow and steal as much as you can. Especially UI elements and sound effects are prime candidates for reuse in your project. Props and Locations can be borrowed and a cameo of a previously used character is an option. For instance if you need a Supernumerary cop giving your hero a ticket it might be fun to use the Hero cop of a popular VN for that. As always ask nicely, at least at first.

Strangely, many projects are abandoned after the v0.1 version. I think this is because they run out of ideas. If you have slashed a lot of your originally intended game you will be busy implementing that for a while. Also if you have the abstract stuff like the Log Line and the Nutshell schema, it will help you think of new and better things, while not messing up your main story.

Another tip is to split your game making effort into sensible tasks and put them on a physical

You must be registered to see the links

board. For normal people that means Post-It's on your wall. Do not cheat be having 1 Post-It with "make game" on it. The idea is that you see your board everyday so you know how far you are. Moving your Post-It to the done column is a physical thing giving you an energy boost. You have my blessing to cheat yourself and make tiny, tiny tasks that you can move to done quickly so you can keep running around like the Duracell Energy Bunny.

ririmudev said:
Um... back to the foldering, it is interesting that the folder structure would try to enforce Act X, Scene Y, as well as rising action, denouement, etc. I don't have any particular complaints, but I wonder how it would play out in practice.

Ah, good of you to say. Enforcing the acts was not my intention. The acts should match whatever you think the acts should be. I thought this was clear because of NOT using the 3 act structure that is common in Hollywood. Stupid me. I should have known better. I will try to make this clear in further updates.
Their are many ways to

You must be registered to see the links

and games generally follow a structure used in TV series where each Episode has it's own screenplay and the season has overarching plot. Also consider a structure followed by

You must be registered to see the links

's as those are about emotions in quite the same way as Visual Novels.

Edit: added the believe in the process link
Edit2: added give yourself a break and don't look up to professionals stuff

ririmudev · Feb 23, 2021

Marzepain said:
It doesn't matter if it's a VN or a game with more mechanics, just get it down to something you can make fairly quickly. (Then cut it some more as estimates are generally wrong.)

Hehe, I've said similar to my direct reports.

Marzepain said:
That said, the initial core version is still a big hurdle to take, so beg, borrow and steal as much as you can.

I "found" music from an old Sonic game to use in one of my p.o.c's

Marzepain said:
Strangely, many projects are abandoned after the v0.1 version. I think this is because they run out of ideas.

I don't mean this as negative as it may sound, but I'd say most games here are by amateurs, and not finishing things is to be expected (out of ideas, misjudging scope, lack of follow-through, whatever). F95 simply makes it more visible. I'm not casting judgment here - I include myself as amateur at best with respect to game-dev specifically.

Marzepain said:
Another tip is to split your game making effort into sensible tasks and put them on a physical
You must be registered to see the links
board. For normal people that means Post-It's on your wall.

Agree; preaching to the choir in my case (I have a self-hosted OpenProject instance on my network, used as a lightweight JIRA)

Marzepain said:
Ah, good of you to say. Enforcing the acts was not my intention. The acts should match whatever you think the acts should be. I thought this was clear because of NOT using the 3 act structure that is common in Hollywood. Stupid me. I should have known better. I will try to make this clear in further updates.

Eh, one can only clarify so much without writing a dissertation. Actually, I cared less about the 3-act structure being imposed, and more about any given structure. Either way, getting people to align on putting things in the right place is a thing unto itself (even if I'm the only person... the judgment call could have a different result Friday than Monday).

Marzepain said:
The modern timeless look of Vector graphics will come back into fashion as an Art statement sooner then later.

In a sense, I'd say it's always had a place. Fundamentally, vector graphics give us a good abstraction. Little/no focus on things we don't typically care for (blemishes, asymmetry, etc), and more focus on things we do care about (eyes, simple shapes and colors, etc).

Of course, it's currently more productive to pose figures in DAZ and Honey Select, then export the results. It's still an uphill battle to unlock the potential of SVG.

Marzepain · Feb 23, 2021

ririmudev said:
I "found" music from an old Sonic game to use in one of my p.o.c's

I think it's ok, but Sega may think otherwise. In order to keep their Intellectual Property (IP) by law they are obliged to protest against use by others once they found out. You can count on a Cease and Desist letter from such a large company. Privately they may find it a very cool thing you done with it, but their shareholders demand that they don't lose their property. In many cases the lawyer fee is higher then what they will ever make from such an old title, but that's just how the business works.

Imitation is the greatest form of flattery, so an Open Source version of a cult classic can be appreciated by the original devs in unofficial communication like at a conversance. Once there is "proof", meaning that it's reasonable that they would know about it, you force their hand and they have to defend the IP. This can happen even after an OS version has been around.
My guess is that F95 is save, because it's not exactly a prime game developer communication channel like Gamasutra or a Game Developer conference.

ririmudev said:
I don't mean this as negative as it may sound, but I'd say most games here are by amateurs, and not finishing things is to be expected (out of ideas, misjudging scope, lack of follow-through, whatever). F95 simply makes it more visible. I'm not casting judgment here - I include myself as amateur at best with respect to game-dev specifically.

Well, another of my sage like explanations is that "expert" means ex- "peril" and is related to "expertise" and "experience". You have to challenge yourself and try stuff, to be able to explain what the perils are of a certain approach. When creating a Proof of Concept (POC) you deliberately try to weather the perils of the concept to learn as much as possible. The trouble comes when a something like a game incorporates multiple concepts. There is also a difference when doing something in the large compared to doing something small. When someone does a 0.1 version and abandons it, I don't consider it a defeat, but something that teaches, how large a scope, how many ideas, how complicated and how much tenacity a game needs. They could always come back and try again.

On a side note, was involved in a startup that had an application at it's founding, that was build by my co-founder. He thought it was great and ready to sell. I called it a POC, because the code was hideous, the UI was horrible, the conceptual model almost non existent and the process it should have supported not worked out. It did have a working version of Kafka messages projected on a Redis cache "Big Table" database (DB). Turns out we really needed a Relational Database instead of Redis, so we could use Structured Query Language (SQL) and not have to update the relations by hand.
It took me 1.5 years, of working 11 hours a day at the office, plus 2 hours in the train, 5 days a week combined with work in the weekend, to realize that 1 the initial application of my co-founder was not a POC and I was creating a Relational database in Redis and changing to a relational DB we would need to redo 15% to 45% of the code, 2 my co-founder was a lazy moron with a personality defect and I probably have a personality defect too, 3 the business opportunity, had passed because our monopolist competitor was finally replacing their aging stuff.
Compared to "Development Hell" and "Crunch time" in professional game development, this story is relatively mild. However it does stress testing the right things in your POC. Alternatively or better jet as an addition, have something in your process that periodically asks the question "Are we doing the right thing?" like in Lean Startup or Scrum.

I added the chapter "Know if the first released version of the game is a PoC, a Pilot, a Feature or a Statement" to clarify more about a PoC

ririmudev said:
Agree; preaching to the choir in my case (I have a self-hosted OpenProject instance on my network, used as a lightweight JIRA)

I value the online tools like Jira, TFS and Git. I know their current versions and 've been involved in some early versions of them, but nothing beats the physical thing. Although now with COVID a physical board will not work for a team. When you work alone it might work, but then COVID has you locked up with your partner, who will go nuts when you mess up a wall that is in sight the whole day.

ririmudev said:
Eh, one can only clarify so much without writing a dissertation. Actually, I cared less about the 3-act structure being imposed, and more about any given structure. Either way, getting people to align on putting things in the right place is a thing unto itself (even if I'm the only person... the judgment call could have a different result Friday than Monday).

Well I'm a Software Architect by nature so aligning people is what I do... witch explains the dissertation. Not that I expect to make an impact on the good people of F95. It would be extremely nice if it would, but no one is going to change things until it hurts. When it hurts, maybe, just maybe they will look at the ideas laying around and improve...a little.
That said, this article is mostly for me, as my judgment call will also have a different result Friday than Monday. Well at least it did before COVID, when I had a Weekend looking a little different from my Weekdays.

ririmudev said:
In a sense, I'd say it's always had a place. Fundamentally, vector graphics give us a good abstraction. Little/no focus on things we don't typically care for (blemishes, asymmetry, etc), and more focus on things we do care about (eyes, simple shapes and colors, etc).

Of course, it's currently more productive to pose figures in DAZ and Honey Select, then export the results. It's still an uphill battle to unlock the potential of SVG.

DAZ and Honey Select may not have a cell shader jet. I don't know anything about them, but I do know you can take the images created and perform a blur and artistic brush effect on those in Paint.Net and then import those images into Inkscape.
These are extra steps for every image, that may need some specific tweaking, so it does take up significant, but predictable, amount of time.

Edit: I added lines to the part about PoC.

Diconica · Mar 9, 2021

It depends on which of my engines I am using. I haven't updated all of them.
My general 2D and 3D based systems that are games and not VN assets are broken up into the type of assets they are.
In cases like different characters those have their own sub folders.

However, then Visual Novel system I am working with is a bit different.The reason is I built a robust content management system into the asset system that does the work for me. So when I create a character in the game it creates a subfolder for him under the various folders it needs to. Then lets say I import an image or a model the system gives me an opportunity to apply a name to it. It could be something like Jill bathing suit jumping... or whatever that describes the image. So then it imports the image and sticks it in the correct folder. Any time I need to make use of the image I can simply call it by name.

The various types of assets are stored in vectors. Images, music, sounds, meshes...
A hash table is used to associate the name with the location index.
It handles loading assets making sure they aren't loaded more than once. So the same asset can be reused many times.
It cleans up the memory when the game shuts down.
I'm considering putting an end life indicator in for assets. Such as if he last scene an asset is used in completed it removes it.
Thus reducing memory usage and rather easy to do. All it would take it is adding that field to the struct the asset is stored in which inside the vector.

As for performance its fast. Even under the development side. But on the game side it uses the actual index itself rather than the name of the file to access the assets so its direct access with no function call once loaded.

If you haven't figured it out I'm lazy. If I can make the program do the work for me I will. I considered even adding an option in to allow it to target development folders and automatically pull images in by itself. So if I was working in blender for example the images I create or models I create it could pull those in. I would need to either create a naming standard or create a secondary file for describing the assets or to link them to names. That would save me from having to go into the developer side and select the assets and then provide names to them.

Game Assets folder structuring approaches and dimension. Introducing the Theatrical approach.

Marzepain

Newbie

ririmudev

Member

Marzepain

Newbie

ririmudev

Member

Marzepain

Newbie

Diconica

Well-Known Member