INTRODUCTION

Sylvain Seccia is an independent creator whose unique career spans the worlds of code, image, sound, and storytelling. Trained in software development, he chose early on not to follow the well-trodden paths of salaried employment or mass production. He prefers to experiment, create his own tools, and explore his ideas to their fullest extent, alone if necessary. For him, each project is a handcrafted work, an ecosystem he designs from start to finish with one obsession: to remain true to his vision.

This quest for independence was evident from the early 2000s, when he founded his own development environment in C++. There, he designed engines, libraries, interfaces, and 3D games, often going against the grain of current trends. His philosophy: to build solid, lightweight, and understandable foundations, rather than piling on opaque technological layers. He sees programming as a language in its own right—a means of expression, as precise as a paintbrush or a pen.

But as time went on, technique alone was no longer enough for him. He felt the need to tell stories and convey emotions. This is how, in 2012, Désiré was born, a 2D adventure game that is at once melancholic, tender, and unsettling. Far removed from commercial logic or expected formats, Désiré is a personal, black-and-white narrative inspired by lived experiences, memories, silences, and fragments of imagination. Sylvain wrote the script, composed the music, designed the environments, developed the mechanics… and above all, created the tool that would allow him to bring this world to life: seccia.dev.

Originally conceived as an in-house solution, seccia.dev has become much more than an internal tool: it's a storytelling-centric creation software. A clear interface, accessible scripting, and a logical structure for scenes, dialogues, and triggers—everything is designed to keep the author in control, without getting bogged down in technical details. It's this vision—that of a developer serving the storytelling—that has allowed Désiré to reach a wide audience, with over three million downloads worldwide.

Today, Sylvain continues on his path with the same exacting standards. He continues to develop seccia.dev, not as a purely commercial product, but as a creative partner. He works on new narrative projects, explores hybrid formats, and imagines interactive stories where the technology fades into the background. His driving force is the same as at the beginning: the desire to tell stories differently, to evoke emotion through simplicity, and to remain free.

This book, like seccia.dev, is an invitation to create freely, to reclaim the means of production, and to tell stories without betraying oneself. It's not for seasoned programmers, but for curious storytellers, methodical dreamers, and creators seeking structure to unleash their imagination. If you're looking for a way to code less and tell more, then you've come to the right place.

Unity

Games created with seccia.dev can be deployed on multiple platforms thanks to a runtime developed with Unity. In practice, this involves generating Unity builds from the project included in the software's installation folder.

To simplify this often tedious step, seccia.dev includes an automatic compilation tool for Unity projects, as well as a system for integrating generated builds. This architecture complies with Unity's general terms of use, particularly regarding the requirement for each developer to have their own Unity license.

To enable rapid prototyping and facilitate testing, pre-compiled versions of the runtime are provided for Windows, Android, and WebGL. However, it should be noted that these versions are intended exclusively for development use and must not be used for any final commercial or public distribution.

Software Installation

Before you can take advantage of the software's features, you need to follow a few instructions to ensure that all components are correctly installed.

The software requires:

• Windows 11 preferably up to date

• A Full HD resolution or higher

• And ideally an SSD to optimize frequent disk access.

The Seccia Launcher application installation is available at the following address:

https://www.seccia.com/download/launcher

Updates will be available free of charge. You will be notified by a notification that will appear within the Seccia Launcher application interface each time a new version is released.

License

seccia.dev is completely free. No features are deliberately restricted to limit the software's use or hinder its potential. You are free to create, develop, and finalize your games, whether for personal or commercial use, without any imposed technical constraints.

Only certain additional services, such as personalized assistance or supplementary services, may be offered for a fee. For more information, please visit the official website:

https://www.seccia.dev

Compiling the Unity project

The first step is to download and then install the current version of Unity Hub from the official website:

https://www.unity.com

During installation, ensure you select the modules corresponding to the following platforms: Android (including necessary sub-modules such as SDKs), iOS, WebGL and Windows.

Once Unity is properly installed, launch seccia.dev, open Preferences, select the desired target platforms, and then click the Build selected platforms button to start the build. All you have to do is wait while the builds are generated.

By default, seccia.dev automatically uses the latest version of Unity detected on your machine. However, it is possible to manually specify a path to a particular version in the software's Preferences.

Finally, if you wish to modify the embedded Unity project to add features specific to your game, this is perfectly permitted by the terms of use. However, altering the structure or fundamental properties of the Unity project is strongly discouraged. Such modifications could indeed lead to compilation errors.

Preferences

Preferences are accessible from the main toolbar. If you experience stability issues, you can disable multithreading and GPU acceleration support.

Documentation

All the functions of the seccia.dev language are documented and can be consulted at any time from the software's integrated help page. This central resource is designed to support your progress, whether you are a beginner or an advanced user.

A convenient shortcut allows you to access it instantly: simply position the mouse cursor over the name of a function or keyword in a script, then press the F1 key. The software will then automatically open the corresponding help page, directly linked to the selected item.

This page isn't just about technical documentation. You'll also find links to social media, community content, and regularly updated tutorials. These resources will not only help you deepen your knowledge but also allow you to participate in the growth and dynamism of the community.

Remember to check this page regularly, whether to familiarize yourself with the subtleties of the language or to discover the latest new features available.

My games created with seccia.dev

Désiré — 2016 https://www.seccia.com/game#desire

Long Live the King — 2017 https://www.seccia.com/game#viveleroi

GAMEPLAY

Before embarking on the creation of your first video game project, it's essential to understand what truly constitutes a game, and even more so, what characterizes a narrative adventure game. Too often, we rush into the visual aspect or the writing of the story without grasping what forms the very backbone of a game: the gameplay. It's the gameplay that defines the rules of the world you create, but also the degree of freedom you give the player. In a narrative adventure game, this structure takes on particular importance, because it doesn't just frame the action: it becomes its language.

What is a video game?

A video game is primarily based on an interactive system centered on gameplay. This term refers to how the player interacts with the game and how the game reacts to their decisions. It's neither pure mechanics nor simple improvisation: it's a balance between structure and expression, between constraint and creativity. It's through gameplay that the player becomes immersed, takes ownership of the virtual world, experiments, and builds their own adventure.

Designing good gameplay requires time, patience, and numerous adjustments. It's not enough to simply imagine appealing features; they must be tested, refined, and balanced. A game can be artistically simple, even rudimentary, and yet captivating if the gameplay works. Conversely, the most beautiful graphics will never save a shallow or flawed gameplay experience.

That said, video games are not just about gameplay. They are also composite art forms, drawing on multiple disciplines: drawing, architecture, music, writing, photography, directing… All these elements enrich the experience, create an atmosphere, and add depth to the game world. But they only serve to flesh out a basic game structure. Without this structure, the work remains inert. The priority, especially at the beginning of a project, must therefore be what makes the interaction come alive: the gameplay.

What is a narrative adventure game?

In a narrative adventure game, gameplay and storytelling are not in competition: they are inseparable. The story is not a backdrop imposed on the mechanics; it is the game's internal logic, its invisible engine. This genre offers a unique form of interaction, where every action is part of an unfolding narrative, every choice resonates within the overall drama.

Contrary to popular belief, gameplay is not secondary. It simply takes a different form. It is not expressed through reflexes or technical challenges, but through observation, dialogue, exploration, and interpretation. The player is not a mere executor: they are an investigator, an active witness, a silent narrator who gradually assembles the pieces of a narrative puzzle.

This type of game therefore demands particular attention to narrative design. If the story is weak, poorly paced, or disconnected from player interaction, the whole thing collapses. The strength of the genre lies in the coherence between narration, presentation, and gameplay. Each element must reinforce the others. In a good narrative adventure game, you don't play alongside the story; you play within the story.

It is this osmosis that gives the genre its richness. More than just entertainment, it becomes a space for interactive expression, an emotional laboratory where the player participates in the creation of meaning.

The four gameplay profiles

If the gameplay of an adventure game has two components that we have just mentioned, namely narration and puzzles, then we can propose an illustrated model of four profiles through the following diagram:

Depending on the level of narrative complexity and the density of puzzles you choose to include in your game, you will obtain one of the following four profiles. Each has its own strengths, risks, and implications for the player experience:

INTERFACE

seccia.dev offers a page-based interface approach, a method uncommon in application development software. In contrast, the window-based, asset-based model is widespread in IDEs, as it is generally practical and efficient in many situations. But is it suitable for all development environments?

For example, in a programming tool, it's inconceivable not to be able to open multiple source files simultaneously while preserving the history of changes. Conversely, in video editing software, working simultaneously on multiple timelines is often unnecessary, or even counterproductive.

Although seccia.dev is more akin to a programming software than a video editing tool, I chose to draw inspiration from the latter when designing its interface. Why? Because this approach, in my opinion, more accurately reflects the production stages of a seccia.dev project. Ultimately, it simplifies and accelerates the creation of your game.

The interface is divided into two parts: the common area and the page area. The common area includes fixed and ever-present elements: the toolbar at the top and the page navigation at the bottom of the window. These shared areas remain accessible at all times and offer functionalities common to several editors. The page area, on the other hand, is dynamic and dedicated to the different stages of the project. It includes tools for managing the scenario, generating executables, accessing educational resources, and accessing the editors. Among these, the scene editor and the role editor will likely be the ones you use most frequently.

The editors are dedicated to the production of assets, that is to say, the creation and modification of essential elements of the game. This includes: objects (including characters), scenes (levels), game logic (graphic code), dialogues (conversations between characters), inventory items, players (control of the main character), cinematics (video in MP4 format) and effects (internal shaders).

Toolbar

The toolbar, located at the top of the window, provides quick access to common software features shared by editors. It is divided into five groups: PROJECT, PUZZLE, PLAY, SEARCH, and IDE.

These icons remain accessible regardless of the page selected, and some are assigned a keyboard shortcut.

	Save the current project
	Display the project folder in Windows Explorer
	Create a new asset (shortcut with the Alt key)
	Access other menus
	Create a new box for the scenario
	Crop the view to the selected Puzzle boxes
	Launch the open scene or a specific scene in Live mode
	Launch the game in Live mode
	Launch the game in Release mode for play_web
	Enable or disable game rendering in editors
	Enable or disable real-time rendering in editors
	Access software settings

Navigation bar

The navigation bar, located at the bottom of the window, allows access to pages and searches within the project.

The pages can also be navigated using a keyboard shortcut.

PROJECT

A seccia.dev project is based on a simple and coherent organization, composed of three main elements:

• A central JSON file, which contains all the game data (scenes, objects, scripts, dialogues, etc.)

• A binary ASSET file, containing most of the resources (images, sounds, etc.) in an optimized format

• External files, placed in specific folders, used for supplementary resources, such as videos or accompanying documents.

This architecture has two major advantages: it simplifies the use of the software for the user, while limiting the risks of corruption or loss of data related to accidental manipulations.

While manually editing JSON or binary files is technically possible, it is strongly discouraged. These files contain unique identifiers that ensure the project's consistency; modifying them carelessly can break these links and cause malfunctions. In other words, you are free to directly edit the files at your own risk, provided you fully understand what you are doing.

Regarding images, seccia.dev exclusively uses the PNG format to store resources in the ASSET file. However, JPEG and BMP formats are also accepted for import: they will be automatically converted to PNG upon integration into the project. Images integrated into a project are automatically processed to optimize the final file size, without compromising visual quality, using the PngQuant library. However, it is important to note that at runtime, all textures are loaded into video memory (VRAM) in an uncompressed format. This ensures consistent display quality but results in higher memory usage.

Project settings

All project parameters are grouped and centralized on the Project page.

Configuration settings

You can create build configurations with different parameters depending on the platform and version to be distributed. By default, there are two configurations required for testing within the software: play_windows and play_web. Platforms have their own specific parameters.

Savegame

Backup-specific settings:

Credits

The credits roll at the end of the game and are also visible from the main menu or when calling the show_credits function. Each language has its own text.

The text color is defined by the Credits color property. To change the color of an entire line, simply add the @ character at the beginning of the line. This color can be customized via the Credits title color property.

You can add predefined keywords to retrieve certain properties of your project. seccia.dev provides a list of constants accessible from dialogs, text fields, and variables in your scripts for this purpose.

PUZZLE

At the heart of the seccia.dev environment lies the puzzle editor. This central tool allows you to define and structure the narrative flow of the game, without resorting to complex programming systems like state machines.

There's no need to manually code the puzzle validation logic: seccia.dev offers a native, simple, and visual solution. You simply add node boxes and then link them together according to the player's progress. During game runtime, a built-in interpreter automatically handles state transitions. The creator's only responsibility is to notify the player that a box has been validated when the corresponding puzzle has been solved.

It's important to clarify, however, that the puzzle editor is an abstract representation of the game's logic. It's primarily designed to organize the narrative, visualize the overall structure of the project, and lay the groundwork clearly and methodically. It doesn't replace the scripts, but rather complements them.

Scripts can only be integrated into role nodes. To view all available language functions, simply click the Help button at the bottom of the main window. There you will find a complete list of commands and their full documentation.

Nodal box

There are five types of node boxes in seccia.dev: puzzle, sequence, or, start, and end. Each fulfills a specific function within the scenario's logic and has properties that are important to understand. To add a box, you can click the [+] button located in the main toolbar to display the list of available types, or use a keyboard shortcut: P, S, O, and E. As you may have noticed, the key corresponds to the first letter of the type. The start box is an exception: it is unique within a scenario.

Puzzle and sequence type boxes must have a name starting with the character #. This prefix is ??used by the engine to identify the active logical points of the scenario.

Puzzle and sequence boxes each have two connectors: one input and one output. The start box, however, has only one output connector, while the end box has only one input connector. The or box has a slightly more complex structure with two input connectors and three output connectors. This may seem confusing at first, but don't worry, we'll go into more detail later.

Each input connector can receive multiple connections, and each output connector can also transmit multiple signals to other boxes. This allows for the construction of branching or conditional scenarios while maintaining clear logic.

Before discussing the logic behind connecting the boxes, it's essential to fully understand the specific characteristics of each of the five types mentioned. It's also important to keep in mind that the scenario progresses in a single direction: from left to right. This corresponds to reading from the past to the future, with no possibility of going back in the narrative structure.

The start and end boxes are mandatory in every scenario. They cannot be completely removed: at least one end box must always remain in the project. When a new game is launched from the game menu, the first box executed is naturally the start box. By definition, no box can precede start, nor follow end.

All end boxes lead to the same outcome: they trigger the credits and permanently end the current game. However, it's important to distinguish between the end of a game and data persistence within the overall game. Some values ??can be retained beyond the current session, allowing information to be maintained between multiple games.

This mechanic opens the door to true replayability: you can, for example, save the endings reached by the player, unlock additional content, or influence new playthroughs based on their previous choices. Thus, although each scenario concludes with an end box, the player's overall progression within your universe can be built over the long term.

The puzzle-box structure is the most frequently used, as it allows you to define the actions expected of the player to advance the scenario. Think of it as a logical loop in which the game remains blocked until the puzzle is solved. As long as the success condition is not met, the scenario cannot progress beyond this box.

The validation of a puzzle box can only be done by the game logic editor via the success action.

The puzzle box, recognizable by its blue color, thus represents a crucial conditional step in the construction of an interactive scenario. It is what makes the player active, by posing a specific expectation to be met before continuing the adventure.

Unlike puzzle boxes, sequence boxes are not blocking. They allow for the automatic chaining of actions or the structuring of the scenario's progression in a fluid way.

Using sequences offers several advantages. They allow for better organization of puzzles, clearly distinguishing their steps and improving the readability of the scenario diagram. This is a good practice for clarifying narrative logic, especially as the project becomes more complex.

Another key advantage of the sequence box is that it automatically defines a logical range around the puzzles it frames. This allows the following functions to be used to query the player's state with respect to this sequence:

These functions offer more precise narrative control, particularly useful for triggering conditional events, adapting dialogues, or offering variations based on the player's progress.

if playing #intro
    // code here
end

It is of course possible to nest ranges defined by sequence boxes, provided that the FIFO (first in, first out) principle is respected. This means that the logical order of entry and exit of the sequences must remain consistent: a sequence started inside another must finish before it can leave the enclosing sequence.

This feature is primarily used to constrain the narrative progression and structure the adventure into clearly defined phases. In theory, the player should not be able to solve a puzzle located outside a beach area until that area is completed. This rule ensures linear or semi-linear progression within a complex scenario.

If this constraint seems too rigid for the type of experience you wish to offer, it probably means that the beach concept is not suited to your narrative needs, and that it would be better to opt for a freer construction, based on independent validations.

Let's take a simple example to illustrate the usefulness of a nested grid: imagine the player falls into an ambush. Until they manage to escape, they are trapped in a closed sequence, limiting their movement and possible actions. This type of situation can be effectively modeled using a sequence enclosing one or more puzzle boxes, ensuring that the player cannot leave this phase until they have completed the required action.

Finally, among the five types of node boxes, the gold box allows the player to be presented with several alternative puzzles, only one of which must be solved to progress. This mechanism introduces a notion of conditional choice, which can produce variations or an impact on the rest of the story.

In this scenario, the player is no longer expected to solve all the puzzles connected to the or box. As soon as one of the puzzles leading to this box is solved, it becomes the selected puzzle, and the others are automatically invalidated. This offers great narrative flexibility for modeling branching paths, sacrifices, or irreversible consequences.

From the editor, it is possible to manually invalidate certain puzzles by marking them as lost. This function is useful for simulating a game state without having to replay everything from the beginning, particularly during testing or adjustments to the scenario's logic.

To use the or box in this configuration, simply connect your puzzles to the first input of the box, then output the signal via the first output. As always with this type of box, the selection condition is set at the input: the first incoming signal determines the outcome. The output is simply the consequence of this choice and introduces no additional conditions.

Keep in mind that the gold box is a valuable tool for structuring non-linear narrative arcs without adding complexity to the graph. Used judiciously, it enhances replayability while simplifying logical construction.

The gold box also allows the narrative to evolve based on the player's choices through the concept of branching storylines. In this mode, it functions as a logic selector, where each input corresponds to a branch of the story and each output reflects that choice.

To implement this, you must use the first two circuits in the box:

• The first circuit connects the first input to the first output.

• The second circuit connects the second input to the second output.

These two circuits are entirely separate: if a signal enters through one input, it will exit through the output of the same circuit, without passing through the other. The first signal received determines which circuit is selected; all others are ignored or considered lost.

This system is particularly effective for handling two-branch forks, for example a moral choice, an irreversible decision, or a success/failure.

But what about multiple branches, when a scenario requires three or more distinct paths while the gold box only offers two circuits?

It is then sufficient to chain several or boxes together, in cascade, to simulate a system with three or more branches.

That's not all: you've probably noticed the presence of a third output on the or box. This actually represents a third circuit, but unlike the first two, it has no inputs.

This behavior may seem confusing at first, but it follows a simple rule: regardless of the input used, if a cable is connected to this third output, the signal will always be sent to it, in parallel with the selected main circuit. It is not a backup circuit or a catch-up mechanism (therefore, it is not a catch-all), but rather a mandatory supplementary output once it is connected.

In other words, as soon as one of the inputs is activated, the motor sends the signal to two outputs simultaneously: on the one hand to the output corresponding to the input used, and on the other hand to the third output, if it is connected.

This gives you very precise narrative control while maintaining the readability of the graph. This subtle feature further enhances the versatility of the gold box, especially in scenarios with multiple branching paths and delayed consequences.

Except for the special case of the or box, when a box receives multiple incoming connections, its behavior changes slightly. Consider the example of a box #P3 connected to two other boxes #P1 and #P2. The signal will arrive in #P3 when the other two puzzles are solved.

To better understand this logic, imagine that the signal coming from #P1 is waiting at the input of #P3 until the signal from #P2 arrives. Only when all the conditions are met can the scenario progress. This rule guarantees perfect synchronization of converging narrative paths, which is essential for sequences dependent on several previous actions.

Best Practices

Given the potentially large number of puzzles in a game, and therefore the significant number of nodes to integrate into the scenario, adopting a structured naming convention is strongly recommended. A simple and effective method is to prefix each node with the chapter number to which it belongs.

For example, a box named #2_open_gate will clearly indicate that it is an action related to chapter 2, which greatly facilitates navigation in the graph and understanding of the narrative progression.

Even if your game only has one chapter, you can still organize the narrative into acts or logical sequences, using a similar system of prefixes. This allows you to segment the development and avoid getting lost in an overly dense linear structure.

This type of organization isn't mandatory, but rather a best practice. It's up to you to decide, based on the nature and complexity of your story, which method best suits your project. The key is to choose a coherent and readable structure that will effectively guide you throughout the production process.

Regarding assets, the chapter number can also be included in the asset names.

S_HOME, P_HERO, I_KEY, C_INTRO, O_DOOR

The first letter, as we saw earlier, is mandatory and defines its type. A short, precise word is sufficient to describe the asset. If you choose to number the chapters:

S1_HOME, P1_HERO, I1_KEY, C1_INTRO, O1_DOOR

There are generally two types of dialogue in an adventure game:

• the conversations, structured and often interactive,

• contextual replies, shorter, triggered by a specific action or situation.

To better distinguish and organize them, it is recommended to use a clear nomenclature that includes the name of the character involved or the location where the exchange takes place. This allows you to quickly identify what each dialogue relates to.

• D_OLDMAN (dialogue related to the old man)

• D_HOUSE (house-specific lines or conversations)

• D_HERO (monologues or thoughts of the hero)

For roles, which define the interactive entities in the scene (NPCs, manipulable objects, active scenery elements), the software needs to link each role to a scene so that interactions can be edited and synchronized correctly during the game.

Here again, it is advisable to use the name of the associated scene or player to maintain a clear logic:

• R_HOUSE

• R_GARDEN

• R_HERO

This approach will help you maintain consistency in your asset tree, especially in projects with a large number of files. It also helps avoid duplicates or ambiguities during the scripting or debugging phase.

In terms of puzzles, the titles of node boxes, especially puzzle-type ones, play a crucial role in the readability of the scenario and the efficiency of debugging. A well-structured name allows for quick navigation within complex graphs, the retrieval of a specific action in the blink of an eye, and ensures smoother long-term project maintenance.

I recommend using the following syntax to name your puzzle-type boxes:

chapter_sequence_label

When the puzzle involves an interaction between several objects, it can be helpful to add a note to the box (comment area) to document this relationship. Use the following syntax for clarity:

I_KEY + O_DOOR or I_WATER + I_BOTTLE = I_FULLBOTTLE

These notes have no impact on execution, but they constitute valuable documentation for you, your collaborators, or anyone who may take over the project.

It is important to consistently implement sequence ranges in your scenario so that you can accurately track the player's progress using associated functions such as started, ended, playing, or unstarted. These functions are even more effective when the scenario structure is well-segmented.

To maintain clear consistency and make the graph easier to read, remember to use the sequence name in each puzzle it contains. This strengthens the project's organization and allows for the logical grouping of actions related to the same narrative moment.

A handy tool accessible via the context menu lets you rename multiple boxes simultaneously after selecting them. This saves you valuable time, especially during the script review or harmonization phase.

Furthermore, you can use the sequence box body (the internal text field) to indicate the emotional mood associated with the current sequence. To do this, it is recommended to first define a list of emotions or moods specific to your game, such as: love, joy, sadness, fear, anger, shame, intrigue…

This purely descriptive annotation is invaluable to artists, and especially to the composer, who can thus better grasp the narrative intent and overall atmosphere of each moment in the game. This type of information strengthens the overall artistic coherence, while also facilitating collaboration between the narrative, sound, and visual departments.

ITEM

In an adventure game, items are central to the gameplay experience. Players collect, examine, combine, and use them to progress through the story. They represent one of the primary forms of interaction in this genre, and their design deserves careful attention. This is where your project's item editor comes in.

An item is a virtual object placed in the player's inventory. It can be a key, a journal, a clue, an ingredient, a broken object, or a mysterious tool. Each item holds a gameplay promise: it triggers an action, a thought process, or an interaction. The item editor allows you to create these objects, configure them, and define their appearance in the game.

The item editor doesn't just dress up a game; it structures its gameplay. It's through these items that the player tests their hypotheses, tries out combinations, and overcomes obstacles. Each item must therefore be designed in relation to the mechanics you've implemented: where to find it, what it's used for, how it evolves, and when it should be used.

For example :

• A rusty key will be able to open a specific door if it has been cleaned with another item.

• An old book can reveal important information if the player has read it in the right context.

• A precious stone can be placed in a sculpture to trigger a hidden mechanism.

The editor gives you all the flexibility needed to manage these interactions, whether through a system of scripts, conditions or combinations between items.

Icon

Each item can have a maximum of four icons, numbered from 0 to 3. These icons are used to visually represent the object in the user interface, particularly within the inventory bar.

The default icon, essential for displaying the object's purpose, always has the number 0. It must be present if you want the item to appear in the interface.

The following function allows you to dynamically change the icon currently in use:

xxxxxxxxxx
set_item_icon I_KEY 1

The optimal icon size is 256×256 pixels, in 32 bits (with alpha channel). To preserve performance, an icon's texture is only loaded into GPU memory if it is actually displayed in the inventory bar.

Title

This is the item's name, as it will appear on screen when the player hovers over it, selects it, or interacts with it. It should be clear, evocative, and sometimes intentionally enigmatic if the gameplay warrants it.

The pipe separator | allows you to define multiple titles for the same item. By default, only the first title in the list will be active, but using the set_item_title function, you can choose another title by specifying its index starting with 0.

State

In an adventure game, a single item can change state as the player progresses. Rather than creating multiple separate items for each variation, the software allows you to assign multiple titles and icons to a single item. This feature offers great flexibility and significantly simplifies inventory management.

An object can thus evolve without losing its identity. For example:

• An empty bottle becomes a full bottle after being filled at a fountain.

• A closed can becomes an open can after being used with a can opener.

• In a more whimsical vein, a crumpled document becomes a readable document after being ironed or slightly moistened.

These changes are not merely visual: they reflect a transformation in the game's logic. The player understands visually and textually that the object's function has changed, which can unlock new interactions or dialogues.

I know what you're thinking: creating a new item for each state might seem tempting, but it unnecessarily burdens the project structure and complicates the management of conditions, interactions, and dialogues. Using the same item with variable states maintains internal consistency while reducing the risk of errors (duplicate items, cluttered inventory, redundant scripts, etc.).

In summary:

• The title reflects the role or state of the object at a given moment.

• The icon shows its current appearance.

• A change in one state often implies an update of both.

Here is an example:

xxxxxxxxxx
set_item_icon O_BOTTLE 1
set_item_title O_BOTTLE 1

This approach enhances player immersion while providing you with a powerful tool for designing fluid and consistent puzzles.

PLAYER

The player editor is a fundamental tool in the construction of an adventure game. It defines what it means to "be the player" in your interactive world. Specifically, it relies on two major components:

• The 3Cs

• The inventory of items

The editor's primary role is to configure your Player asset, that is, the set of elements that govern the 3Cs:

These three elements form the basis of the embodiment experience. A balanced configuration of the 3Cs is essential to guarantee an intuitive and immersive experience.

The second role of the player editor is the inventory, that is, the list of objects that the player can collect, examine, combine, or use. This inventory is directly linked to the game mechanics: it is an interactive space where the player's choices materialize.

Each item in the inventory comes from the item editor we saw in the previous chapter, and its use depends on the narrative or logical context you have defined. It is in this interface that you manage what the player possesses to interact with the world around them.

It is entirely possible to design a game with multiple inventories, associating each inventory with a distinct player. You can then dynamically switch players via code or through interactions within the game interface, allowing you to vary perspectives or mechanics depending on the narrative sequences.

Icon

As with items, each player can have a maximum of four icons, numbered from 0 to 3. These icons are used to visually represent the character in the user interface, particularly within the inventory bar.

The default icon, essential for displaying the character's portrait, always has the number 0. It must be present if you want the character's face to appear in the interface.

The following function allows you to dynamically change the icon currently in use:

xxxxxxxxxx
set_player_icon P_HERO 1

However, if your game does not offer the option to switch between multiple playable characters, the icons become optional and can be ignored without consequence.

The optimal icon size is 256×256 pixels, in 32 bits (with alpha channel). To preserve performance, an icon's texture is only loaded into GPU memory if it is actually displayed in the inventory bar.

Scrolling & Zoom

seccia.dev offers a set of simple but powerful tools to control camera behavior, directly related to the character's position on the screen.

Automatic horizontal scrolling of the scene can be enabled or disabled at any time. This is done either by checking the Scrolling box in the editor, or via script using the enable_scrolling and disable_scrolling functions.

For smoother gameplay, you can enable a smooth scrolling effect, which applies a gradual deceleration rather than an abrupt stop when the character stops moving. This significantly improves visual comfort, especially in more cinematic scenes.

The camera zoom can also be enabled or disabled dynamically, by checking the Zoom box or via the enable_zoom and disable_zoom functions.

In addition, seccia.dev offers other features to enhance the staging by manipulating camera movements. For example:

All of these functions are documented in detail on the help page accessible from the software interface.

Integration via code

Managing players in scripting is simple. Since a player represents a playable entity, to assign them a character (object) to control, use the control function. A player can only control one object at a time. The inventory remains associated with the player, regardless of the object being controlled.

xxxxxxxxxx
control P_HERO OC_HERO

To indicate which player is currently active, use the switch function. Only one player can be active at a time.

xxxxxxxxxx
switch P_HERO

If the game has multiple playable players (character switching mid-story, alternating co-op, etc.), you must specify the list of players visible in the inventory bar. Note: the active player is never displayed in this list.

xxxxxxxxxx
set_player_list P_HERO P_FRIEND

Each player must be linked to a starting scene, even if they are not yet active. This allows the engine to know where to locate each player from the start of the game.

xxxxxxxxxx
set_player_scene P_HERO S_HOUSE

OBJECT

The object editor allows you to create objects in the broadest sense of the term and configure them before instantiating them in scenes. The generic term "object" is therefore used to refer to active objects, static objects in the scene, and game characters.

Objects cannot be added directly to the player's inventory; you must use items. If you need to retrieve a key in a scene in the form of an object, you will need the equivalent in the form of an item.

The first column of the interface lists the three default animations STOP, WALK, and TALK, even if they are empty, and just below them the names of your own animations. Each animation has its own parameters.

The second column lists the properties of the object, animations, and sub-objects by category.

The third column is reserved for viewing the selected frame.

The frames of the selected animation are displayed at the bottom of the editor.

Object

In the second column, reserved for properties, you will find the exhaustive list of parameters relating to the object, detailed in the following table:

Animation

Each object in seccia.dev can contain predefined animations as well as custom animations:

• Three default animations are reserved for internal engine actions (STOP, WALK and TALK).

• You can add as many additional animations as necessary to enrich the visual behavior of the object.

An animation is composed of several directions, each containing its own frames (successive images). This structure allows for the precise definition of an object's appearance and movement according to its orientation in space.

The four primary directions are RIGHT, LEFT, FRONT, and BACK. The four secondary directions are FL (front left), FR (front right), BL (back left), and BR (back right). Secondary directions are useful if you want to move in eight directions. If your object only has one direction, it is recommended to use RIGHT by convention. No direction is mandatory: you are free to define only those that are useful to your game.

Each direction can contain up to 250 frames, indexed from 0 to 249. This gives you great freedom in animation while ensuring controlled performance.

Sub-object

Sub-objects are rectangular interactive areas defined within a main object. They allow you to create several independently named, clickable parts within the same object. This is particularly useful when you want to, for example, distinguish different parts of a character's body (such as a hat, a cane, or a bag) without having to create new, separate objects.

A sub-object should not be confused with a rectangular portion. Sub-objects are only used to declare elements that inherit from your object. You must then define the clickable rectangle on all necessary frames. Pixel-level collision detection is also applied to sub-objects.

After creating and selecting a sub-object, new properties are displayed in two new sections: Frame and Sub-object.

Regarding first the identity of the selected sub-object:

Regarding the properties of the selected frame:

Words

You must provide three head tilts so that seccia.dev can randomly select frames, applying constraints based on the selected profile. Good to know: the algorithm will never randomly select the same image twice in a row.

The tilts must contain identical facial poses. If your animation has four poses, then you will need twelve frames in total (i.e., 4 poses x 3 tilts) as shown in the example below.

The images are numbered from 0 to 11 from left to right and top to bottom. The first line corresponds to the normal head tilt. The second to a downward tilt, and the third to an upward tilt. Note that the tilts should be barely perceptible for a natural look.

Special Features

The functions accessible from scripts do not allow modification of an object's properties. Unlike other assets, the object is not instantiated when the game starts, as it is primarily a graphical model used to construct entities. Therefore, an object can only exist through one or more instances created within scenes.

When an object is placed in a scene, it becomes a scene object, since its characteristics then depend on the scene's context. It is therefore important to distinguish between the concept of an object (the model) and that of a scene object (the instance), because the same object can give rise to as many scene objects as there are scenes that use it. Thus, changing the title of a scene object will only affect the instance in question.

The functions listed in the Play section of the help page are reserved for the states of the current scene.

Best Practices

It is important to name animations correctly by classifying them by location or action to prepare for game memory optimization and minimize refactoring, which will negatively impact your deadlines.

If an animation is specific to a scene and the object appears in multiple locations, you can choose one of these three optimization modes.

| Only for scene | Advantage : No latency when playing the animation. Disadvantage : Textures load when the scene opens, even if the animation is not playing. | | ------------------ | ------------------------------------------------------------ | | On the fly | Advantage : Fewer textures to load if the animation is not playing. Disadvantage : Significant latency before the animation plays due to the loading of all the frames. | | Streaming | Advantage : Fewer textures to load (frame by frame) and very little latency before the animation plays. Disadvantage : On some low-performance hardware configurations, the animation may slow down and not play at the correct speed, especially if the animation speed is high. |

As a general rule, it is better to stream large and non-recurring animations.

seccia.dev is clever; it can avoid unloading an item if that item is also present in the next scene being loaded. Therefore, if your main character is in every scene, their resources will never be unloaded during the game.

SCENE

The scene editor lets you compose your game's levels by placing objects, configuring interactions, and orchestrating the visual and narrative elements that make up your adventure's world. You'll likely spend most of your development time on it.

One of the great strengths of seccia.dev lies in the simplicity with which you can define the character's movement area (walking range), while associating actions with complex behaviors, without having to write a single line of code. For example, when a player clicks on an object to pick up in the environment, the engine can automatically move the character to the object and then trigger a contextual animation (such as crouching or reaching out). This logical sequence is managed visually using grids and cells, tools that we will detail in a dedicated section.

The scene editor also allows you to design in-game cinematics without leaving your workspace. To do this, you can use timelines and insert shots (shot values) to control the camera, movements, dialogue, and synchronized actions.

Scene

A scene in seccia.dev consists of several visual and interactive elements, organized to create a rich and vibrant environment. It includes:

• a main setting,

• foreground or background layers,

• stills (fixed or decorative elements),

• interactive objects,

• and clickable areas defining possible interactions.

When you create a new Scene asset, the first step is to replace the default background with an image of your choice. This image must be in PNG format to support transparency.

Right-click the Back icon in the Scene toolbar, then select a file to import. Once imported, the image becomes the main background of your scene and serves as the basis for arranging objects, layers, and interactions. The image dimensions define the scene size and, consequently, the number of grid cells. If the scene size differs from the game's resolution, black bars will be overlaid or horizontal scrolling will be applied, depending on the project settings. The cell size is fixed at 16x16 pixels regardless of the game's resolution.

There are two types of layers: backgrounds (FAR) and masks. You can add a maximum of four backgrounds and four masks per scene. The display order of the nine images, including the main background, is as follows, from foreground to background.

If the main background is completely opaque, distant backgrounds will not be visible. Layers can be enabled or disabled via code by adding crossfade effects.

For performance and graphics compatibility reasons, seccia.dev automatically splits layers when they exceed certain sizes. Images are transformed into textures with dimensions that are powers of two (512, 1024, 2048, etc.), in accordance with modern graphics card standards. This process ensures better memory efficiency and faster data access. This splitting is transparent to the user: the on-screen rendering remains smooth and accurate, regardless of the internal texture splitting.

Scene Properties

When no element is selected, you can access the scene properties in the list located at the top right of the editor.

Scene Actions

In the role editor, certain synchronized actions are specific to the scenes we briefly list below:

Stage Conditions

In the role editor, certain conditions are specific to scenes, which we briefly list below:

Events on the scene

In the role editor, some events are specific to the scenes we briefly list below:

Still

Stills are fixed graphic elements that visually enrich a scene without adding complexity to the management of interactive objects. They play a crucial role in visual composition and depth of field, while also providing an efficient solution for reducing the number of objects to be created in a project.

Unlike interactive objects, stills:

• are immobile and non-interactive,

• are not shared between scenes (each scene contains its own stills),

• do not induce any external dependencies, which facilitates the portability and modularity of scenes.

Like objects, all images are stored in a texture atlas, optimized for performance.

You can insert stills into a scene in two ways:

• Via the context menu: right-click in the scene, then choose Add stills to import one or more images.

• By drag and drop: if still mode is enabled, you can drag your images directly from Windows Explorer to the scene. This method is fast and particularly well-suited to artistic workflows.

If the imported image has the same dimensions as the main background, it will be automatically cropped and placed in the exact position within the scene. This allows the artist to prepare visual elements in separate layers and then easily export them without having to manually reposition them in the editor.

Once imported, each still can be individually configured according to the needs of the scene.

The properties of still

Stage prop

We already developed the concept of a scene object in the previous chapter. To summarize, it is a version specific to the scene that possesses its own particular characteristics.

Scene object properties

Scene Object Actions

In the role editor, certain synchronized actions are specific to scene objects, which we briefly list below:

The conditions of the scene object

In the role editor, certain conditions are specific to scene objects, which we briefly list below:

Scene Object Events

In the role editor, some events are specific to scene objects, which we briefly list below:

Label

A label allows you to either define an interactive rectangular area without adding additional graphic assets to the scene, or to integrate text on the screen.

Label properties

The label's actions

In the role editor, some synchronized actions are specific to the labels that we briefly list below:

Label conditions

In the role editor, certain conditions are specific to the labels, which we briefly list below:

Label Events

In the role editor, some events are specific to the labels we briefly list below:

Shot

Shots (or camera angles) allow you to define the camera's position, so you can apply transitions either through code or via timelines. When a shot is selected, a grid appears to help you compose your image according to the rule of thirds. Holding down the Alt key while selecting a shot will hide all guides except for the selected grid.

The position and width of the shot can be changed manually, while its height adjusts automatically according to the display ratio defined in the project properties.

It is possible to activate a shot or transition between two shots using roles via the shot box, with parameters that customize the effect. However, a more intuitive, flexible, and elegant method is to use timelines, which we will discuss in more detail later in this chapter.

Shot properties

Shot Actions

In the role editor, certain synchronized actions are specific to the shots we briefly list below:

Wall

Walls allow you to define shadow areas that interact with dynamic lighting. Invisible on screen, they must follow the lines of the scenery to accurately simulate obstructions to light. Their position is fixed and cannot be modified by code.

The properties of the wall

Grid & Cell

The grid allows you to define movement zones as well as possible interactions with scene elements (objects, labels, etc.). Only objects can contain one or more grids, up to a limit of eight per object.

Each grid is composed of customizable cells. To edit a grid, simply double-click on the object in question. In edit mode, you can switch between grids using the numeric keypad (from 0 to 7).

To change the active grid using code, use the set_grid function.

In edit mode, the entire scene is displayed in black and white, with reduced contrast except for the selected object. Lines then appear to visually delimit the cells.

To add an active cell to the grid, hold down the Shift key, then left-click on the desired cell. Similar to using a paintbrush in a drawing program, you can click and hold to fill multiple cells with a single click. You can also select a larger brush size from the toolbar.

To select already defined cells, choose the selection tool that suits you, then simply click on the cells: they will appear in white to indicate that they are active.

Once selected, cells can be deleted using the Del key, or copied/cut to the clipboard with the shortcuts Ctrl+C/Ctrl+X. It is also possible to delete cells by holding down the Ctrl and Shift keys, then clicking with the left mouse button.

Finally, the arrow keys on the keyboard allow you to move the selection. When one or more cells are selected, a list of specific properties appears in the upper right corner of the editor. We will detail these properties later.

Cell properties

Cell Actions

In the role editor, some synchronized actions are specific to the cells we briefly list below:

Cell conditions

In the role editor, some conditions are specific to cells, which we briefly list below:

Cell Events

In the role editor, some events are specific to the cells we briefly list below:

Path & Spot

There is another way to move objects by following a predefined path, either curved or straight. Similar to grids, seccia.dev offers eight paths per object, which can be activated using the set_path function. To edit the paths, select the object and then Edit paths from the pop-up menu.

By holding down the Shift key, you can left-click to add spots to your scene and thus draw a linear path. Paths have properties, and like cells, each spot has its own properties.

To select a spot, simply click on its point with the left mouse button. If you click on a spot while holding down the Ctrl key, you will select or deselect the spot depending on its state.

For faster and more convenient selection of multiple elements at once, simply hold down the left mouse button to display a white circle on the screen. All spots touching this circle will be automatically selected. To maintain the current selection, press Ctrl before the circle appears, then release the key. To invert the state of a spot, hold down the Ctrl key while dragging.

Use the arrow keys on the keyboard to move the selected spots one pixel in the desired direction.

Use the PageUp and PageDown keys to move to the previous or next spot. The Home key will place the selection at the beginning and the End key at the end of the path.

It's possible to apply a curve to your path to break the linearity of movement and make it more natural using the Spline property of the path. In this case, the position of the spots in the game will be defined by the position of the points on the curve.

Path properties

Spot Properties

Spot Actions

In the role editor, some synchronized actions are specific to the spots we briefly list below:

Spot conditions

In the role editor, certain conditions are specific to the spots we briefly list below:

Spot Events

In the role editor, some events are specific to the spots we briefly list below:

Drag & Drop

Drag and drop plays an important role in creating mini interactive puzzles, allowing you to enrich the narrative of your games with simple and intuitive gameplay mechanics.

The principle is as follows: by clicking and holding the left mouse button on an object, you can drag it to another object or to a label in the scene. The action ends when you release the button over a valid target. On a touchscreen, the functionality is identical: simply drag the object with your finger to another interactive area.

First and foremost, you must define the object's behavior by assigning a value to the Drag property in the scene editor. Three options are available:

When a drag-and-drop operation fails to reach a target, the on drop object event is also triggered. To achieve this, set the Target property to False.

This configuration allows for the design of various mechanisms, such as:

• assembling objects to create a new one,

• insert a key into a lock,

• combine ingredients,

• assigning elements to specific characters or areas.

• move a puzzle piece

This system is ideal for introducing natural tactile interactions, enhancing immersion and promoting storytelling through action, without burdening the script logic.

Drag and drop events

In the role editor, some events are specific to drag and drop, which we briefly list below:

Timeline

Timelines have two main uses in seccia.dev: they allow the creation of in-game cutscenes and scripted transitions, orchestrating visual, audio, and scripted elements using shots. This system offers precise control over the staging while maintaining a logic fully integrated into the project structure.

One of the major advantages of timelines is the ability to attach music and add synchronized subtitles, while ensuring perfect alignment with other elements such as animations, camera movements, or script executions. This synchronization guarantees a smooth and immersive narrative, without any breaks in rhythm.

The timeline editor consists of three parts:

• The left column allows you to add and manage the different timelines associated with the scene. A single scene can contain as many as necessary, depending on narrative or technical requirements.

• The central part offers a detailed view of the timeline itself, in which you place and organize the temporal elements (shots, subtitles, scripts, effects…).

• The right side is used for real-time preview, allowing you to immediately test the rendering and write your scripts in a synchronized visual context.

To start a timeline during a game, use a timeline box in the role editor. If you wish to interrupt its execution prematurely, simply use a stop box.

This system allows you to insert narrative or cinematic sequences with the same nodal logic as the rest of the project, while benefiting from careful and precise staging.

Shots

You must first add your shots to the scene and position them precisely, just as you would a label. Each shot corresponds to a camera frame, which you can then use in a timeline to create transitions, staging effects, or cutscenes. Unlike other visual elements, you cannot directly change the frame height of a shot: it is calculated automatically based on two essential parameters:

• the width of the shot, which you can adjust,

• and the game's resolution ratio, which determines the format visible on the screen.

When you select a shot in the editor, a geometric ruler appears within the frame: this is the rule of thirds, well-known in photography and filmmaking. Without going into the theoretical aspects, this rule recommends positioning the main subject (or a point of interest) on one of the lines or at an intersection of the grid. This enhances visual clarity and improves the composition.

You can insert as many shots as needed into a scene. It's recommended to give them short, descriptive names to make them easier to find later. Think of these shots like rushes in video editing software: you capture them in the game world before arranging them on the timeline.

Transitions

When two shots are placed side-by-side on the timeline, a green bar automatically appears below their join point. This indicates that you can apply a linear transition between the two shots. To do so, simply click on this bar.

Once activated, the transition creates a smooth flow between the two shots: a fluid visual fade that improves the pacing and clarity of your scene. You can adjust the transition's duration by stretching its frame at its edges, just as you would with an editing element.

It's important to note that once the transition is applied, the two shots become visually linked. They can no longer be moved independently until the transition is removed. To do this, right-click on the green bar and select the delete option from the context menu.

This system allows you to manage your sequences with the same flexibility as editing software, while remaining within the integrated environment of seccia.dev. It offers precise control over visual storytelling without the need for code.

Spline Interpolation

Note that it's very easy to independently adjust several camera settings within a timeline, including the X position, Y position, zoom, blur, depth of field, focus, and fade to black. These settings are accessible directly from the editor's left sidebar, where each setting has its own control button.

The first button, symbolized by a chain, allows you to link several parameters in order to animate them together in a synchronized manner.

By default, the interpolation of values ??between two states is based on a linear mode, defined by two endpoints that you can reposition vertically on the y-axis. This creates constant movement, without any change in speed.

To achieve a more natural animation with gradual acceleration and deceleration, you can activate spline interpolation. Simply add intermediate points by left-clicking on the curve at the desired location. Right-clicking allows you to delete a point.

The number of intermediate points is limited to eight, resulting in a maximum of ten points per transition (including both ends). This provides ample room to fine-tune the pacing of an animation without complicating the timeline.

Music and subtitles

To synchronize music to a timeline, there's no need for scripts. Simply add an OGG audio file to the Songs tab of your project. Once the file is in place, you can select it directly from the dropdown list in the bottom right corner of the timeline, for each language if necessary.

This allows you to associate specific music with a sequence while ensuring perfect synchronization with other temporal elements of the timeline (animations, effects, subtitles, etc.).

Subtitles work on the same principle as in video subtitling software. To insert one, simply place the cursor where you want it on the timeline, then type the text in the designated field. Like shots and transitions, you can stretch their time frame to adjust their display duration.

Note, however, that subtitles cannot be previewed in the editor. They will only appear when the game is running. It is therefore advisable to test the sequences in context to adjust their placement.

A significant advantage over pre-rendered cinematics is that subtitles are embedded within the project's CSV files. This allows them to be fully integrated into the localizable production pipeline, greatly simplifying translation and multilingual adaptation.

Events

Another advantage of timelines is the ability to insert events at any point in the sequence, allowing you to trigger actions in a scripted way: launch an animation, play a sound, modify a variable, validate a puzzle, etc.

To do this, simply click where you want on the timeline—just like for a shot or a subtitle—then enter an event name and value in the text fields below the preview. The event will be intercepted by the on timeline box in the game logic editor.

These events are executed at the precise moment the cursor reaches their position during timeline playback, ensuring perfect synchronization with other visual and audio elements.

This system allows you to centralize the narrative and technical logic of a sequence within a single editing space, without having to scatter the code across different editors. This improves readability, consistency, and production speed.

Scene Manager

The scene manager is accessible from the software's main menu. It is designed to facilitate the duplication and management of elements between scenes, saving you valuable time when creating similar levels or setting up recurring structures.

With this tool, you can:

• quickly copy elements from one scene to another,

• or conversely, remove specific elements from a selected scene.

The types of elements concerned are stills, objects, labels, shots, walls and timelines.

To duplicate information:

• Select the source scene in the left column.

• Check the items to copy (for example: objects, shots...).

• In the right-hand column, check the target scenes you want to modify.

• Click the launch button to perform the copy.

Note:

• If an element with the same name already exists in the target scene, it will be overwritten by the version from the source scene.

• Exception: stills are never replaced, new elements are automatically created in the target scene.

This system guarantees flexible and secure management, while maintaining consistency between the different scenes of your project.

Best Practices

Here are some practical tips to optimize game performance:

• Merge the layers beforehand using your preferred graphics editing software.

• Limit the number of effects applied to the scene, especially for mobile devices. You can also use texture adjustments during app generation as an alternative method to find the best compromise between quality and performance.

• Limit large static objects by merging them with the background and layers if possible, or use stills to create depth. The more objects there are to display in the scene, the slower the game will become. Remember that stills are grouped into a single texture.

• Limit the number of frames in animations or use Streaming mode in the object editor.

• Limit the number of lights and activate the Baked lights option if applicable.

DIALOGUE

The dialogue editor allows you to write, organize, and structure the interactive conversations in your game. It's an essential tool in a narrative adventure game, where progression relies as much on verbal interactions as on the player's actions.

In practice, you will often need to work simultaneously on the scene, role, and dialogue editors to manage the changes in state triggered by certain lines of dialogue or player choices. This coordination is essential to ensure a coherent and responsive narrative.

That said, using this editor is not mandatory. If your game relies solely on object puzzles without textual narration—as was the case for Vive le Roi—you can absolutely do without it.

For consistency and to avoid state conflicts, the player cannot save their game during a conversation. They must exit the dialogue, usually at a point where a list of choices is presented, to regain access to the save functions.

Finally, the editor includes quick access to the current language, allowing you to translate or proofread texts directly within the interface, without needing to export CSV files. This speeds up the localization process and simplifies multilingual testing.

Dialogue

A dialogue consists of a tree of choices in blue and replies in red.

Dialog Properties

Actions of the dialogue

In the role editor, certain synchronized actions are specific to dialogues, which we briefly list below:

The conditions for dialogue

In the role editor, certain conditions are specific to dialogues, which we briefly list below:

The events of the dialogue

In the role editor, some events are specific to dialogues, which we briefly list below:

Red "Choice" Box

The red boxes allow the player to choose from different dialogue options at various points in the conversation. These options are assigned to the current player.

The properties of choices

The actions of choices

In the role editor, some synchronized actions are specific to the choices we briefly list below:

The conditions of choice

In the role editor, certain conditions are specific to the choices we briefly list below:

The events of choices

In the role editor, some events are specific to the choices we briefly list below:

Blue Box “Sentence”

The blue boxes allow you to give a line to a character present in the scene.

Properties of replicas

Conditions for Aftershocks

In the role editor, certain conditions are specific to the choices we briefly list below:

The events of the aftershocks

In the role editor, some events are specific to the choices we briefly list below:

Interface

You can move a box in the scenario editor by selecting it and dragging it to another box, with or without its children. The movement behavior can be modified using the Ctrl and Shift keys to give you precise control over the graph's organization.

Here are the different combinations available when you release the left mouse button:

These combinations allow you to precisely rearrange your scenario without having to manually disconnect everything. This is particularly useful for restructuring a sequence, changing the narrative order, or moving entire subsets without losing the logic of the connections.

| BRANCH | BOX | BRANCH | BOX ||||||| | :----------------------------------------------------------: | :----------------------------------------------------------: | :----------------------------------------------------------: | :----------------------------------------------------------: | | Ctrl+C | Ctrl+Shift+C | Ctrl+X | Ctrl+Shift+X |

Copying and pasting dialog boxes to the clipboard works the same way as manually moving them, and can be done via the context menu. When you copy dialog items, they are saved in JSON format, which allows you to:

• paste them into any Dialog type asset,

• transferring them between projects,

• or even share them between different instances of the software opened simultaneously.

It is important to note that during this operation, the unique identifiers will be regenerated. This ensures that no conflicts arise when inserting them into a new environment, but it also means that the direct links to these boxes (by name) may need to be manually recreated if necessary.

Regarding the Mutual show property, it allows choices to be dynamically unlocked based on the progress of the conversation. It's a very simple way to make a choice visible after one or more lines of dialogue have been read.

Here's how to proceed:

• Select the choice you want to make visible later.

• Click on the icon located at the top right of the replica box which will trigger the appearance of this choice.

• Upon clicking, the Visible property of the choice automatically becomes False, and the link is established.

At runtime, the behavior is handled without any lines of code. The choice simply needs to appear on the screen once all linked boxes have been read. This system allows you to:

• to build conversations with progressively branching paths,

• to conceal certain choices until narrative conditions have been met,

• or even encourage a linear reading before opening up new interactive branches.

Style

seccia.dev introduces four formatting templates designed to help you effectively structure and style your dialogue. These templates provide visual clarity, allowing players to better understand the dynamics of the exchanges and writers to better organize narrative intentions.

It is essential to clearly distinguish between two fundamental components of any interactive conversation:

Each formatting model therefore acts as a visual guide, allowing you to recognize at a glance the type of content displayed on the screen, its function, and sometimes even its tone.

The replicas

seccia.dev offers four visual styles for dialogue lines, each corresponding to a different aesthetic or narrative mood.

Inspired by LucasArts games, the default style displays the dialogue above the speaking character. It is recommended to assign a TALK animation to the character to visually accompany the speech.

To distinguish between the speakers, you can:

• Assign a different color to each character.

• Limit the colours to two or three to maintain visual consistency.

This style is ready to use.

The Comics style is inspired by comic books. Each line of dialogue is contained in a speech bubble. You must provide a DIALOG_COMICS_TALK image (with or without transparency) on the Project page. The software automatically adjusts the bubble size based on the text. Margin coordinates must be specified in the project properties via the Dialog tab interface.

This style reinforces a graphic atmosphere.

The Movie style displays dialogue at the bottom of the screen, like movie subtitles. To activate it, check the Movie style property in the object editor for the relevant character. This style can be combined with another style within the same conversation, depending on the active character.

Ideal for a serious, sober or dramatic tone.

Finally, the Visual Novel style adds an avatar during the conversation. The text's position will depend on your interface, defined in the Dialog tab of the project properties. This style requires creating a new object containing a STOP animation and optionally a TALK animation, so that you can then select this object in the character's Avatar property via the object editor.

The TALK animation plays when the character continues speaking, and the STOP animation plays when the player is prompted to choose a response. The STOP animation is used instead of the TALK animation if the latter is absent. If the STOP animation does not contain any images, no avatar will be displayed.

The choices

For dialogue choices in seccia.dev, two visual styles are available, each corresponding to a specific narrative and game-like approach.

The default style displays choices per line at the bottom of the screen and follows the conventions of traditional point-and-click games. If the sentence is too long, it will scroll horizontally as the mouse cursor hovers over it. This mode is ideal for developing your ideas.

The Visual Novel style presents choices as customizable boxes. This more graphical approach is better suited for offering players short choices, such as brief discussion topics.

This style requires the DIALOG_VN_CHOICE image to display the choice frame.

Bubbles can contain an icon instead of text by specifying the object name in the Icon property of the choice.

Integration via code

To start a conversation, simply add a talk box, specifying the Dialog asset type and optionally the IDs of the start and end replies. Adding a stop box or calling the shutup function will prematurely end the conversation.

xxxxxxxxxx
shutup

Three other functions that will be very useful for controlling the visibility of choices.

xxxxxxxxxx
show_choice D_BOB 5
hide_choice D_BOB 8
if choice D_BOB 8
end

The said function allows you to know if a line has already been said, as its name suggests.

xxxxxxxxxx
if said D_BOB 8
end

If a red box contains several lines of dialogue separated by a blank line and you want to know the player's choice, you can use the variable $_choice in the on say box's script like this:

xxxxxxxxxx
if var _choice 0
    // first choice
else_if var _choice 1
    // second choice
end

This variable will be accessible in the on say event of the reply.

GAME LOGIC

The game logic editor allows you to visually program synchronized actions, conditions, and events in your game more intuitively than by writing code. It facilitates the implementation of complex interactions while making the logic more readable.

It is possible, and even recommended, to associate a game logic with a scene to allow direct interaction between their respective editors. This association makes the creation process smoother and more consistent. To do this, simply use the same name for the scene and the game logic.

At runtime, the game logic associated with the scene is automatically launched when it loads, and then stopped when it closes. This automation ensures clear management of contextual behavior without additional intervention from the creator.

Language

The game logic editor offers five distinct types of boxes, each represented by a specific color: system boxes in green, action boxes in red, conditional boxes in blue, event boxes in purple, and finally script boxes in brown.

Each type of box fulfills a specific role in constructing the interactive logic of a scene. This visual distinction allows for the immediate identification of the nature of each action or condition in the graph.

The connections between the boxes operate according to the same principles as in the scenario editor. When a box accepts multiple input connections, it will only execute if all expected signals have been received. This ensures strict synchronization of events before they are triggered.

start

The start box is automatically called when the game logic is launched. It constitutes the logical entry point of the execution.

It is possible to define the order in which the different start boxes within the same game logic are called by modifying the value of the Execution order parameter. The boxes will then be sorted in ascending order of this value, allowing you to prioritize certain initializations or actions.

update

The update box is called once per application frame, or approximately 60 times per second for a game running at 60 fps. This box allows for continuous response to changes in the scene, but you cannot modify its execution frequency.

To create actions spaced out over time, it is recommended to use the on repeat box, which allows you to define intervals based on a duration, or the wait box, which inserts a pause expressed in milliseconds.

As with the start box, it is possible to define the order in which the different update boxes are called using the Execution order parameter. The boxes will be executed in ascending order of this value.

When launching a game logic, the update boxes will always be called after the start boxes.

task

The task box is called by the task function and serves as a link between scripts and game logic. It allows a portion of logic defined in the game logic editor to be executed from a script, thus providing a flexible bridge between the two systems.

You can use them as actual routines, which avoids duplicating code. This approach promotes a clearer and more modular organization of complex behaviors.

gold

The or box allows for a flexible logical condition. If one of its inputs receives multiple connections, a single signal is sufficient to trigger the box's execution. It therefore offers an alternative to the full validation requirement inherent in other types of boxes.

The output of the or box has no special features. It simply transmits the received signal, like a standard output.

random

The random box allows you to randomly select a single signal from among the available output connections. Each time it's activated, one output will be chosen at random to transmit the signal.

schedule

The schedule box allows you to precisely plan the order in which its outputs will be activated. The number of outputs can be modified according to your needs, with a minimum of two outputs required.

You can absolutely connect multiple cables to the same output to combine several actions with a single trigger. It's also not necessary to use all available outputs, which allows for some flexibility in structuring your sequences.

skip

The skip box allows you to skip a frame of the program. It acts like a very brief pause, equivalent to a single frame.

This box is useful when it is necessary to slightly defer the execution of an action, for example to allow time for a change of state to be applied before chaining another operation to the next frame.

restart

The restart box allows you to restart the role by resetting all internal states. It is useful when you want to reset all actions, conditions, and sequences defined in the current role.

end

The end box allows you to stop the role.

script

The script box allows you to execute code and dynamically determine the output to use with the out function. By default, if no output is specified, the first one will be used.

The out function also allows you to specify other outputs if necessary by calling it multiple times, which offers more flexibility in managing logical branches.

The box can return a value other than 0 to maintain its execution from one frame to the next. In this case, no signal is transmitted, and the script is simply restarted in the next frame, allowing for controlled loops within the role.

Actions

In the game logic editor, the execution of an action is synchronized, unlike in scripts. This means that the signal only leaves the box when the action is considered complete. The notion of "action completed" depends on the type of action and its parameters.

An action can have only one input and one output. It has a built-in script that allows you to call other functions through code. This script is executed in three different contexts: when the signal enters the box (enter), when it persists over several frames (execute), and when it exits the box (exit). These three cases are handled within the same script. To distinguish between them, you must use the enter, execute, and exit functions directly in the code.

xxxxxxxxxx
if enter
end
if execute
end
if exit
end

The script is executed only once per frame, regardless of the situation. If all three functions return true simultaneously, it means the signal enters and exits immediately.

It is possible to force the premature exit of a stock by returning a value other than 0. However, if the signal is already expected to exit naturally, this value will have no effect.

xxxxxxxxxx
return 1

All actions share a common parameter: Lock game. This parameter blocks interactions with the player until the signal is released. It is also possible to use the lock function, which is independent of this parameter and can be combined with other locking mechanisms.

animate

The animate box allows you to play the animation of an object.

camera

The camera box allows you to move the camera from one position to another without using shots and to apply a zoom to the transition if necessary.

cinematic

The cinematic box allows you to launch a video via a Cinematic asset. The signal leaves the box when the video is stopped.

examine

The examine box allows you to enlarge an object, giving the player the opportunity to observe an important detail of the game. During observation, the game remains frozen until the player leaves the screen. The signal leaves the box when the player resumes control.

interpolate

The interpolate box allows you to interpolate an integer between a minimum value and a maximum value, and retrieve the result into a variable.

jump

The jump box allows you to change scenes by applying a fade-to-black transition. The signal leaves the box when the screen goes black.

light

The light box allows you to change the properties of a light attached to an object.

path

The path box allows you to start the path of an object.

player

The player box allows you to modify the attributes of a player.

popup

The popup box allows you to display a message on the screen with a choice of responses. Depending on the type of window, several outputs are possible.

logic

The logic box allows you to start a game logic sequence. The signal will be blocked as long as the launched game logic is running.

select

The select box allows you to replicate the click on an object or a label. If both are provided, the object takes precedence.

show

The show box allows you to change the visibility of one or more entities. The signal is emitted immediately after the element's state has changed.

song

The song box allows music to be played on a channel. The signal leaves the box immediately, even during transitions.

stop

The stop box allows you to stop the indicated entities.

success

The success box allows you to complete up to four puzzles at a time.

take

The take box allows you to retrieve up to four items at a time to place them in an inventory or in the trash.

talk

The talk box allows you to start a new conversation. The signal leaves the box when the conversation ends.

timeline

The timeline box allows you to launch a timeline.

wait

The wait box allows you to impose a waiting time in milliseconds before outputting the signal.

walk

The walk box allows you to move a scene object by calculating a path between its current position and its destination. The signal leaves the box when the object has reached its target.

Terms

Conditions allow you to enrich your sequences of synchronized actions without using code, while maintaining the clear logic of visual programming. Each conditional box has a single input and multiple outputs corresponding to the different possible outcomes.

When the signal enters the box, the condition is evaluated, and the output corresponding to the result is activated. If this output is not connected, the signal is lost and execution stops, which can be used intentionally to interrupt a sequence.

A condition can also be used as a loop if the Loop box option is enabled. In this case, the box is evaluated every frame as long as the borrowed output does not lead to another box. For example, to express "as long as the condition is false, the sequence remains blocked," simply connect only the output corresponding to the true condition.

boolean is

This condition allows us to compare the variable as a boolean. The result can therefore only be true or false.

dialog has

This condition allows you to determine the states of a dialogue. The condition will be true if all the provided parameters match.

dialog is

This condition allows you to know the dialogue and the currently executing response. The condition will be true if all the provided parameters match.

object has

This condition allows you to determine the states of an object. The condition will be true if all the provided parameters match.

player has

This condition allows you to determine the states of a player. The condition will be true if all the provided parameters match.

player is

This condition allows us to know the current player and the object controlled by the player. The condition will be true if all the provided parameters match.

puzzle is

This condition allows you to know the state of a puzzle and has four outputs: