DIV4GODOT

Framework to use DIV Games Studio's syntax in Godot 4.x GDScript, Developed by Pablo Navarro,

Introduction

This is an aberration, yes, but let me explain.

Godot and GDScript are fairly simple and intuitive, but I've been making 2D arcade video games with the DIV Games Studio syntax for many years, and this inefficient little framework helps me tremendously to get a similar experience in Godot.

How it works:

Before we start using it we should prepare the assets in the DIV folder in a fairly concrete way. It is highly recommended to review the actual example to understand it, but anyway here is a brief explanation:

DIV processes

Forget the game development paradigms you know and get ready for DIV madness.

DIVProcesses have two functions: init and process. With init we will set the parameters when instantiating such DIVProcess and process is what is executed from the beginning of the instance until the end of it.

But, is process the same as _process? Not exactly. _process (native of Godot) is a function that is executed in each frame. process (from DIVProcess) is a function that is executed only once and is kept running based on await frame() (similar to await get_tree().process_frame).

Instantiation of DIVProcess processes

To be able to instantiate the DIVProcess processes comfortably, we must save them as scenes in the res://DIVProcesses folder. (This is all very beta and will change in the future). After that, we will have to execute the project once so that the DIV.gd file is precompiled and then we will be able to make the instantiation of these DIVProcesses in a simple way using the global singleton DIV. For example: DIV.bullet(x,y)

The local variables of the DIVProcess

For compatibility, the following local variables are available. Here we show what these variables correspond to:

• x = position.x
• y = position.y
• z = z_index
• alpha = modulate.a * 255 (goes from 0 to 255)
• angle = rotation * 360000
• size = scale.x * 100 = scale.y * 100 (size only applies if size_x and size_y both equal 100)
• size_x = scale.x * 100
• size_y = scale.y * 100
• file = "fpg"
• graph = "id_graph"
• animation = "animation_name"
• action = 0 (used for state machines, but currently also used to flag a DIVProcess as "terminating". For example: if its "action" is less than zero, that DIVProcess won't collide anymore)
• flags = 0 (Add 1 to flip horizontally and 2 to flip vertically. 3 would flip both ways)

FPG folder (FPG stands for "fichero para gráficos", or file for graphics).

In DIV Games Studio the graphics were compiled in FPG files with identifiers from 1 to 999. In DIV4GODOT we use dictionaries comparable to FPG files. These dictionaries are generated with the PNG files inside the res://DIV/fpg/file/ folder. Subsequently, within the code of a DIVProcess node, we can use the local variables file and graph to select the graph to display.

Music and sound folders:

A single music player and several sound channels have always been used in DIV Games Studio. In DIV4GODOT, by habit, I have enabled something similar. We will put the music files in OGG format in the res://DIV/music folder and the sound files in WAV format in the res://DIV/sound folder. To play music we will use play_music("song", repeats) To play sounds we will use play_sound("sound", repeats)

Animations:

DIV Games Studio did not support animations as such, so I created my own "animator". For now I have translated this animation organization to something simple and useful: inside a FPG, from one frame to another with some delay. To add an animation from an FPG we use this function: add_animation(file, animation_name, frame_delay, first_frame, last_frame = 999)

Ideally, the numbering of the graphics should be separated in the FPG in a way similar to this:

• 1 idle
• 11-13 walk
• 21-23 run
• 31 shoot
• 41 jump

Thus, we can add the animations as follows:

add_animation(fpg, "walk", 0.2, 11)
add_animation(fpg, "run", 0.2, 21)
add_animation(fpg, "shoot", 0.2, 31)
add_animation(fpg, "jump", 0.2, 41)

In these cases, because of the file organization, it did not require indicating the final frame.

Collisions:

DIV Games Studio had pixel perfect collisions: it would create bitmap masks and check if they would overlap. In DIV4GODOT I try to do the same automagically. If there's no collider node attached to the DIVProcess node, it will be autogenerated from the sprite selected in the editor.

And how do the collisions work? Instead of using signals and callbacks, we check it on the spot: collision("process_type | process_instance") If successful, it returns the colliding node. We can use this for a type of elements ("enemy") or a certain instance ("enemy23"). We could also check for multiple collisions

Because GDScript does not support to assign in an condition sentence, we cannot do this:

   id_collision.action = -1

And we would be required to do this everytime:

if id_collision:
   id_collision.action = -1

To avoid duplicating those lines, I added a local named last_collided_node, so now we can do this:

   last_collided_node.action = -1

"Families" (son, father, brother, etc...)

Because of how GDScript works, I found no way to replace those behaviours. In DIV Games Studio, if you instanced a process, the locals son and father would be accordingly updated to reference each process. In Godot, you can achieve the same but not automatically, it requires getting the caller node from a parameter.

To be continued

I just started developing this framework. For current Godot users this methodology is probably not very practical, but it has its advantages and conveniences, specially for small arcade games.

Also, I'm the worst documenting stuff. Please check the example project!