In this series of illustrations, a blonde little girl and a cute bear joyfully wander through the festive scenes of the Spring Festival:

Spring Festival Travel​

They carry luggage and backpacks, boarding trains to return home or embark on new journeys;

Red Envelopes​

Holding bright red envelopes, they share the good fortune and joy of the New Year with everyone;

Fireworks​

Fireworks light up the sky and firecrackers sound, symbolizing renewal and eager anticipation for the future. There are details representing programming languages like C++, Rust, and Lua, signifying our continued exploration of different technological fields in the new year, bringing more surprises and possibilities to Dora SSR.

Reflecting on the past year, we have helped each other and progressed together in the community, allowing Dora SSR to grow from an inspiration into a vibrant and evolving open-source game engine. The participation of every enthusiastic contributor, developer, and player is our driving force. Just like the joyful and lively atmosphere in the illustrations, the new year will also be a brand new journey full of opportunities and challenges.

The snake in the Chinese zodiac symbolizes agility, intelligence, and insight. Like a nimble and adaptable snake, we will continue to lead the Dora SSR project forward through continuous learning, experimentation, and iteration in the new year.

Here, we sincerely wish everyone in the new year:

1. Smooth Coding: May your work, studies, and development processes be more efficient and effective;
2. Unlimited Creativity: Whether in game creation or technical research, may you be inspired with endless ideas;
3. Good Health: While programming is important, don't forget to maintain a healthy lifestyle;
4. All the Best: Enjoy the Spring Festival with family and friends, and gather more beautiful moments.

We sincerely thank every partner for their support and contributions, and we look forward to joining hands again in the new journey of the Year of the Snake in 2025, making Dora SSR even more exciting. Let's unleash our wisdom and passion together, bringing more surprises and emotions to the community.

Wishing you a prosperous Year of the Snake, happiness for your family, and a joyful Spring Festival!

I've been following the Wa language team and "lurking" in their community for over a year. I was suddenly inspired by an article they published about the essence of open-source spirit. I've always been interested in the progress and survival of their open-source projects. As a core contributor to the Dora SSR project, I know that we are all the same, open-source authors from the working class, not looking down from above, but struggling like sardines in a can.

So, let me announce it here: we have prioritized the implementation of using Wa language combined with the Dora SSR game engine to develop cross-platform games!

2. Learning a Programming Language is Like Weaving a Cocoon for Yourself​

The goal of the Dora SSR game engine is to create an inclusive and diverse engine ecosystem. Many followers are puzzled as to why this engine supports so many programming languages. Currently, it officially supports Lua, Teal, YueScript, TypeScript, TSX, and Rust for hot update scripts, yet it's still not enough. As someone who has written code and various projects for many years, I understand that no programming language is perfect. If you find a language that seems to do everything, it only means you lack experience and understanding in cross-domain development or haven't been exposed to enough programming languages to develop an aesthetic sense for them.

3. The Experience of Using Wa Language​

Integrating Wa language into the Dora SSR game engine (i.e., providing FFI support) is simple and involves three steps:

• 1. Reuse the C API interface exported by the engine for Rust.
• 2. Import the C API interface in Wa language.
• 3. Manually write and automatically generate wrapper interface code for the C API in Wa language to provide a development experience consistent with Wa language style.

Then you can develop games using Wa language!

However, saying it's simple is deceptive. The actual integration process is as follows:

Dora SSR is a game engine primarily developed in C++. It interprets and executes Wa language compiled into WASM binary code through an embedded WASM3 virtual machine and provides engine call functionality. The Dora C++ interface currently has over 1000 functions selected to perform necessary engine functions. Writing these interface wrapper codes takes a lot of time, and they need to be updated with the engine, so an automated tool is needed to generate these interface codes.

Our automation tool needs to accomplish the following, using a simple example:

• a. I have a C++ interface:

class App {
public:
    int32_t getTargetFPS();
};

#define SharedApplication \
    Singleton<Application>::shared()

• b. Convert it to a C language export interface:

extern "C" {
    int32_t application_get_target_fps() {
        return SharedApplication.getTargetFPS();
    }
}

• c. Then convert it to a Wa language import interface:

#wa:import dora application_get_target_fps
func application_get_target_fps() => i32

• d. Finally, convert it to a mature Wa language call interface:

type _App :struct {}
func _App.GetTargetFPS() => i32 {
    return application_get_target_fps()
}
global App = _App{}

• e. Call it in a Wa language program:

import "dora"

func init {
    println(dora.App.GetTargetFPS())
}

Steps b, c, and d are mainly the ones that need to be automated by tools.

But this example is the simplest case. Everyone knows that C++ has many complex mechanisms. Besides basic data types, we need to pass objects, inheritance relationships, type conversions in the inheritance chain, string objects, arrays containing various data types and objects, callback functions for mutual calls between C++ and Wa language, enum data types, static functions, member functions, class static member functions, etc. After handling object passing, a more challenging issue is managing object lifecycles. C++ manages C++, Wa language manages Wa language, and cross-language references need to manage each other.

There are many details that can't be covered here, so please check the source code (no responsibility).

Due to space constraints, I can't introduce everything here, but I'll share an interesting binding mechanism. It's about cross-language callback functions. In the world of C/C++ (and many other languages), the core of function call parameter passing is through a compiler-generated call stack to pass parameters into the function body and retrieve return values. When crossing languages, the call stacks of both languages usually can't directly access each other. So, can we write a call stack that both languages can access to simulate parameter passing and return value retrieval for cross-language function callbacks? This idea is certainly feasible.

For example, in a game loop, we often need to register an Update function called every game frame. There might be a C++ interface like this:

void GameScheduleUpdate(const std::function<bool(double)>& updateFunc);

We first implement a function call stack:

class CallStack {
public:
    void push(double v);
    void push(bool v);
    double popDouble();
    bool popBool();
};

Provide a C wrapper function:

extern "C" {
    int64_t new_call_stack() { /* Create CallStack object */ }
    void call_stack_push_bool(int64_t stack, int32_t v) { /* Push bool */ }
    int64_t call_stack_pop_f64(int64_t stack) { /* Pop double */ }

    void game_schedule_update(int32_t funcId, int64_t stack) {
        std::shared_ptr<void> deref(nullptr, [funcId](auto) {
            SharedWasmRuntime.deref(funcId);
        });
        auto args = reinterpret_cast<CallStack*>(stack);
        GameScheduleUpdate([funcId, args, deref](double deltaTime) {
            args->push(deltaTime); // Pass parameter to Wa language
            SharedWasmRuntime.invoke(funcId); // Execute callback
            return args->popBool(); // Retrieve return value from Wa language
        });
    }
}

Provide an interface in Wa language to register the Update callback function:

#wa:import dora new_call_stack
func new_call_stack() => i64
#wa:import dora call_stack_push_bool
func call_stack_push_bool(stack: i64, v: i32)
#wa:import dora call_stack_pop_f64
func call_stack_pop_f64(stack: i64) => f64

#wa:import dora game_schedule_update
func game_schedule_update(funcId: i32, stack: i64)

func _Game.ScheduleUpdate(update_func: func(delta_time: f64) => bool) {
    stack := new_call_stack()
    func_id := PushFunction(func() {
        delta_time := call_stack_pop_f64(stack) // Retrieve parameter from C++
        result := 0
        if update_func(delta_time) { // Execute actual callback
            result = 1
        }
        call_stack_push_bool(stack, result) // Pass return value to C++
    })
    game_schedule_update(func_id, stack)
}

In a Wa program, you can use a clean program interface like this:

import "dora"

func init() {
    dora.Game.ScheduleUpdate(func(delta_time: f64) => bool {
        println(delta_time)
        return false
    })
}

In actual operation, the process is more complex than it seems because Wa language runs on a WASM virtual machine, and interactions between the two languages must go through the WASM virtual machine as an intermediary. The actual callback execution process might look like this:

This diagram simplifies some aspects, such as the call between the C++ program and the WASM virtual machine, which also goes through an additional process of simulating the call stack through the WASM virtual machine. So, you can see that the current solution for implementing cross-language function callbacks has some performance overhead. In the future, we might explore ways to directly access and reuse the WASM virtual machine's call stack to optimize performance.

Now, let's briefly discuss the issue of object lifecycle management. If we can't find a mechanism to automatically and correctly manage the lifecycle of C++ objects from the language level, we have to manually manage object releases in the new programming language environment. This means accurately arranging to call obj.Destroy() once to release objects, which can be exhausting for those eager to write game logic scripts.

Fortunately, Wa language has an advantage in that both it and the engine's C++ mechanism use reference counting. They even have very similar semantics for managing pointers to objects through reference counting. So, we just need to do this:

4. Challenges Encountered in Practice​

Let's talk about the challenges encountered in practice.

Challenge 1: Wa Language Author Tells Me Not to Use This Language​

First, let's talk about why I'm so interested in Wa language. In fact, the Dora SSR engine has already implemented WASM bindings for Rust language. For a C++ veteran, Rust language is almost perfect. However, when it comes to quickly developing and iterating on game logic, I have some reservations. It's like trying to write an assignment with a teacher staring at every word you write, constantly criticizing you. Sometimes, due to not understanding the teacher's rules, you end up spending more time arguing and rewriting the assignment.

Wa language goes in the opposite direction of Rust. It has a Go-like design, emphasizing simplicity in language rules.

It doesn't have complex syntax challenges or mandatory elegant coding styles. You can quickly patch together your business logic with a minimal syntax set. I like this style so much that when I initially communicated with the core author of Wa language, I was warned that the project might not be mature, and I shouldn't have high expectations. I said, "If I can eat Rust crabs (Rust logo here), why not Wa?" If I encounter bugs in the language, I'll contribute to fixing them. Then came Challenge 2, where I did encounter bugs and contributed to fixing them.

Challenge 2: The Inevitable Path of Software Engineering​

To be honest, the Dora SSR open-source game engine project has the same issue. Developing open-source software, since it's called software development, naturally faces the realities of software engineering. People used to joke that open-source projects are a novel form of unpaid crowd-sourced testing (labor exploitation). To develop a mature, stable, and powerful software, taking a steady path of requirement design, development, and testing, and investing sufficient manpower and time are essential. As an open-source developer working in my spare time, even a genius who can do the work of ten people can't match the resource costs needed to create the perfect software. So, using open-source co-creation, engaging in a long-term struggle and people's war, is the only way to achieve some wonders and create technical assets accessible to everyone.

During the process of creating Wa language bindings, I did encounter some compiler bugs. Within a few days of getting started, I submitted five issues to the author. One issue was critical because my code couldn't run without fixing it, so I had to read and study the Wa language compiler's source code to find a solution.

So, I submitted this issue: https://github.com/wa-lang/wa/issues/67

And this corresponding fix PR: https://github.com/wa-lang/wa/pull/68

I feel that open-source projects often have a strange pattern: the more issues you see submitted, the fewer problems you might encounter when using the project yourself. Users discovering and submitting issues is also a necessary labor investment in building a software project. The more issues you help an open-source project discover, the fewer long-term problems it will have. This interaction model is healthy and is the charm of open-source software projects. You are not just an irrelevant bystander; even participating in observation and trial use is a significant force in building it. Most importantly, the results of the construction are shared with you.

Challenge 3: Where is the Path?​

Have you noticed that this article hasn't mentioned the popular large language models? Not jumping on the bandwagon?

Because developing a new language today is likely to be isolated from LLM assistance (not really). Fortunately, Wa language is still relatively similar to Go language, so code generated for Go can be adapted for Wa. Many people think that with AI large models, programming development has no value, but that's just a parallel universe that capitalists hope for. As developers who create the real world through practice, the world is what it is through our perception and direct creation with our hands. As an exploration of native languages on WASM, I realize the great value of Wa. For example, I can't delve into how Rust language's complex engineering implements compilation to WASM and interaction, but studying Wa has helped me quickly grasp many WASM knowledge details. With this practical experience, I can personally accept the actual value brought by authors initiating a new language.

So, I call on everyone to join in the wave of creating programming languages. Whether it's creating native, WASM, or Lua VM transpiled languages, use "one person, one language" to build a new world led by individuals rather than LLM automatically generated. If you dare to invent a new programming language, I dare to integrate a game runtime for your work through the Dora SSR open-source project, expanding the boundaries of your work.

5. Related Code Repository Links​

• Wa language development package for Dora SSR: https://github.com/IppClub/dora-wa
• Wa language: https://github.com/wa-lang/wa
• Dora SSR open-source game engine: https://github.com/IppClub/Dora-SSR

There was a time when every major breakthrough in game engines led to significant technological advancements in the industry, such as the transition from 2D to 3D rendering or from basic lighting to real-time shadows and physics simulations. These innovations opened up endless possibilities for game development and propelled the industry forward. However, as technology has matured, such disruptive innovations have become less common.

Today, the focus in game engine development has shifted toward optimizing and improving existing technologies to enhance user experience and development efficiency. Especially in open-source engine projects, the integration and refinement of existing open-source libraries have become increasingly important. Open-source developers often lack the resources and manpower to build everything from scratch, such as physics engines, font loaders, or animation runtime systems. In other words, much of the work in open-source game engine development involves integrating popular third-party libraries.

This approach not only boosts development efficiency but also makes the game engine more flexible, better catering to the diverse needs of game development. By reusing existing open-source libraries, developers can focus on creating innovative gameplay and content rather than reinventing the wheel. In this way, game engine development becomes more like building a service platform, providing developers with the necessary infrastructure to focus on their creative pursuits.

Positioning of the Dora SSR Engine​

Speaking of service platforms, the Dora SSR open-source game engine we are developing is positioned as a user-friendly, cross-device compatible game engine and development toolchain. Compared to the Godot engine, which includes a built-in development IDE, Dora SSR differs in that its integrated game editor is a Web application developed using ReactJS.

This means that Dora’s editor and runtime can run independently across different platforms and even on various hardware devices. As a result, the game under development and the IDE do not interfere with each other within the same process, nor do they compete for resources. Ultimately, it is still possible to package the runtime and development tools into an app or installation package, much like Godot, making it easy to distribute. Preparing a game development environment becomes as simple as installing a mobile app.

However, Dora SSR currently does not fully support 3D rendering. Although the game scene nodes have Z coordinates and rotation attributes for the XY axes, and a 3D camera is used by default, 3D animation models, material management, and a complete 3D rendering pipeline are yet to be implemented. Given the limited resources of the project maintainers, we also lack the capability to create advanced 3D art assets and games, which is a limitation faced by open-source developers without substantial financial backing.

But, does that mean we should abandon what we love just because we can't be the best?

Open Source, Open Source, and Open Source!​

Of course not. We are developing an open-source game engine because of our deep passion for this endeavor. Open-source culture represents sharing, collaboration, and innovation, values that resonate strongly with us. Open-source is not just a development model; it's a belief—a belief that everyone can contribute to technological advancement and the growth of their field of interest, regardless of the scale.

In the gaming industry, the significance of open source is particularly profound. Through open source, more developers can participate, collectively refining and optimizing the engine, and driving continuous technological progress. Moreover, open source provides learning and growth opportunities for all, from beginners to seasoned developers. For me, witnessing open-source projects improve through collective effort and seeing more people finding their dreams through open source is incredibly exciting.

I envision a more open and collaborative world of game creation: a world where everyone with creativity can freely access and use various resources to bring their ideas to life without hindrance. Developers can freely distribute and share their work, receiving feedback and suggestions from around the globe. Such an open environment not only accelerates technological development but also nurtures more talented developers, advancing the entire industry. As a gaming enthusiast, the idea of having more unique and special game choices in the future, thanks to everyone's collaborative efforts, is thrilling.

Let's Talk About Getting Hands-On!​

The current version (v1.5.1) of the Dora SSR engine is structured as follows:

Dora SSR Architecture

In summary, Dora SSR's software architecture is divided into three layers: Hardware Abstraction Layer, Core Engine Functionality Layer, and User Interface Layer.

Hardware Abstraction Layer​

Firstly, the Hardware Abstraction Layer ensures that Dora SSR can run on various operating systems and hardware platforms. Whether it's Windows, Linux, macOS, or mobile devices like iOS and Android, Dora SSR achieves cross-platform compatibility through SDL2 and the Render Hardware Interface (RHI) technology framework, bgfx. bgfx serves as an abstraction layer, providing a unified interface for underlying rendering technologies such as OpenGL, Metal, DirectX, and Vulkan. These technologies address the adaptation to operating system interfaces and graphics rendering interfaces, ensuring efficient performance across different hardware environments.

Core Engine Functionality Layer​

Next is the Core Engine Functionality Layer, the "heart" of Dora SSR. It includes several sub-functional layers, each responsible for different engine functions:

• Rendering Layer: Comprising Line Renderer, Sprite Renderer, VG Renderer, and ImGui Renderer, these renderers handle various graphical rendering requests in batches.
• Feature Layer: Encompassing basic modules like Physics, Assets (resource management), Graphics, Network, Audio, and ML (machine learning).
• Game Framework Layer: Including modules like Platformer Game, AI (artificial intelligence), Unit (unit management), and Action (action management) to support game logic and gameplay.

User Interface Layer​

Finally, the User Interface Layer is where developers directly interact with the engine. Dora SSR offers a powerful Web IDE, integrating the work of other open-source projects like Monaco Editor (frontend of VSCode), Code Wire (visual script editor), Yarn Editor (game script editor), Spine Player (Spine2D animation preview), and TypeScript compiler. These tools are brought together to provide developers with a comprehensive, user-friendly development environment, allowing them to quickly get started and focus on realizing their creativity.

Additionally, the User Interface Layer includes the runtime and language compilers that load, compile, and execute the game scripts written by developers. It supports multiple scripting languages through Lua VM, WASM VM, YueScript compiler, Teal compiler, and various language bindings, offering developers flexibility in choosing languages for game development.

The architecture of Dora SSR is designed with cross-platform compatibility, modular functionality, and user experience in mind. Through its open-source nature, Dora SSR invites more developers to participate and contribute to creating a powerful and flexible game development platform. By organizing its architecture into distinct, scalable layers, Dora SSR simplifies the development process and provides rich feature support, making game development more accessible and enjoyable.

Dora SSR from a User Functionality Perspective​

From a user functionality perspective, the Dora SSR open-source engine is divided into two main parts: the engine runtime and the Web IDE. The engine runtime can operate independently of the Web IDE and external resources. By simply removing the scripts and resources required by the Web IDE from the published engine, you can obtain a pure Dora SSR runtime program, which can be used to load developed games and resources and package them for standalone release.

Dora SSR Engine Execution Process​

The execution process of the Dora SSR engine can be easily understood from the perspective of data flow. Essentially, the game scripts written by users are handling game logic data processing and submission operations. Once this data is submitted to the core engine modules, further data transformation, processing, and merging occur, ultimately generating the data needed by the GPU for rendering. This results in various forms of feedback and interaction, including but not limited to graphical updates and displays.

Showcase of Some Web IDE Features​

• Code Editor

Dora SSR Code Editor

Dora SSR’s Web IDE offers a fully-featured code editor that supports multiple programming languages and file types. In this demo image, we can see users writing TypeScript code and using TSX to define and control the behavior of game objects. The file tree on the left displays the project’s resource structure, including scripts, assets, and configuration files. The code editor features syntax highlighting, auto-completion, and document navigation, enhancing development efficiency. Additionally, the small window at the bottom right shows the real-time preview of the engine runtime, allowing developers to immediately see the effects of their code changes.

• Yarn Spinner Script Editor

Dora SSR Story Editor

The Dora SSR Web IDE integrates the Yarn Spinner script editor, providing a visual and efficient storytelling tool for game developers. In this demo image, you can see the interface of the Yarn Spinner editor, where the user is writing an interactive script with decision points. The central editing window shows the script content being edited, supporting rich text formatting and simple tags like <<jump>> for story branching.

The visual node graph on the right illustrates the script’s flow, with each node representing a story segment, connected by lines to show the story’s progression and decision paths. This graphical script editing approach allows developers to intuitively design and adjust the narrative flow.

Yarn Spinner’s features not only improve the efficiency of game script writing and testing but also facilitate the design and management of complex narratives, making Dora SSR’s Web IDE a comprehensive game development platform.

• Visual Script Editor

Dora SSR Visual Script Editor

The Dora SSR Web IDE includes a Visual Script Editor, primarily aimed at beginners in programming, especially teenagers, to help them transition smoothly into programming and enhance their experience. In this demo image, you can see the interface of the Visual Script Editor, which uses a graphical programming approach, allowing users to create program logic by dragging and connecting different nodes.

The left panel displays variable management features, enabling users to easily add and manage variables. The central workspace shows various nodes, including loops, conditional statements, and array operations. Users can connect these nodes in an intuitive way to build complex program logic. The right panel, which is collapsible, allows users to view the compiled Teal code, which is used by the engine to execute the visual script.

This graphical programming approach lowers the barrier to entry for programming, allowing beginners to grasp and implement basic programming concepts without needing to master complex syntax. For teenagers, this approach not only makes learning more enjoyable but also fosters logical thinking and problem-solving skills, helping more people easily enter the world of programming.

• Spine Animation Preview

Dora SSR Animation Preview

The Dora SSR Web IDE also integrates a Spine2D animation model preview feature. This feature allows developers to easily view and adjust Spine animation models, including switching the model’s skin and playing different animations, helping ensure that Spine animation models are loaded and played correctly in the program.

User Experience of Game Development on Various Devices​

Lastly, let’s talk about user experience. Earlier, I mentioned that Dora SSR aims to make setting up a game development environment as quick and simple as installing and using an app. Can Dora really achieve this?

We have already been experimenting with running Dora SSR on various mobile devices, handheld consoles, and embedded devices, utilizing remote access to the Web IDE for game development and testing. Whether on Raspberry Pi, domestic MCUs, or high-performance SoCs on mobile phones, Dora SSR offers a relatively smooth experience. Even on some niche mobile devices with built-in keyboards and trackballs, we can run the engine and access the development environment locally through a browser, turning game development into an activity accessible anytime, anywhere.

However, to ensure a good user experience, we recommend using at least a larger screen and a keyboard-equipped Android tablet or iPad to remotely access and use the Web IDE for game development on small-screen devices, providing a more comfortable game development experience. Whether at home, in a café, or outdoors, Dora SSR offers developers a game development environment that can be accessed anytime, anywhere, removing the constraints of device and location.

Dora SSR Cross-Platform Development

Join Our Community​

If you’re interested in Dora SSR, we welcome you to join our community, where we can discuss, share ideas, and collaborate together. You can find us at the following locations:

• GitHub: https://github.com/IppClub/Dora-SSR
• Gitee: https://gitee.com/pig/Dora-SSR
• GitCode: https://gitcode.com/ippclub/Dora-SSR

We look forward to your participation in advancing open-source game engines!

Coming Soon​

In the upcoming series of articles, we will delve into the various modules of Dora SSR, giving you a detailed understanding of the internal workings and implementation techniques of this ever-evolving game engine. Stay tuned for our updates!

Today, let’s talk about using Dora SSR—a game engine that supports TSX and runs cross-platform natively. It’s a seamless way to step into the world of game development. Don’t worry, game engines aren’t as inaccessible as they might seem; in fact, they have surprising similarities to the frontend tools we’re used to.

1. Game Client Development as Frontend Development​

First off, let’s define what a game engine is. Simply put, a game engine is a collection of tools and libraries that help developers build games, handling graphics, sound, physics calculations, or collision detection. For frontend developers, think of it as a specialized browser that runs games.

Dora SSR manages game scenes with a tree structure similar to the HTML DOM—quite familiar territory for us. Imagine swapping out HTML div elements with various game objects and replacing CSS animations with game animations. The concepts and even some of the coding practices are not that different. Exciting, isn’t it?

2. From TypeScript to TSX: Applying Frontend Tech in Games​

Many frontend developers are familiar with TypeScript and React’s JSX syntax. In the open-source Dora SSR game engine, we embrace TSX, offering a game development interface similar to frontend programming patterns. Yes, you heard that right—TSX!

Developing games with TSX means you can leverage your existing frontend tech stack—components, modules, and other modern frontend technologies—directly in game development. Moreover, Dora SSR’s performance optimizations ensure smooth operations even in complex game scenarios.

3. Challenge: Craft an "Angry Birds"-like Game in Under 100 Lines of Code​

Enough with the theory; let’s dive into some practical work. Let’s see how to write a game similar to "Angry Birds" using less than 100 lines of TSX code in Dora SSR. Before starting, setting up the development environment with Dora SSR is straightforward: install the package, open the browser, and let’s start coding! For installation and getting started, see: Dora Startup!

Accidentally installed as an APK on your phone? Access it over the same local network for on-device development and debugging

1. Crafting the Simplest Game Scene​

Before diving into the actual code, we can start with a special comment that tells Dora SSR’s Web IDE to automatically hot-reload the code upon saving with Ctrl + S, allowing real-time preview of the code execution results.

// @preview-file on

We then import the necessary libraries and components. Our code editor also assists by automatically suggesting the required modules, which can be included later in the coding process:

import { React, toNode, useRef } from 'DoraX';
import { Body, BodyMoveType, Ease, Label, Line, Scale, TypeName, Vec2, tolua } from 'Dora';

Displaying an image in Dora SSR is simple, just use the <sprite> tag, and then instantiate it into a game object with the toNode() function.

toNode(<sprite file='Image/logo.png' scaleX={0.2} scaleY={0.2}/>);

Now, you’ve pretty much got the hang of most of Dora SSR’s game development tricks. Start creating your own game (seriously).

2. Crafting the Game Box Component​

Next, the colliding boxes in our game are defined by the Box component, which accepts properties such as num, x, y, and children:

interface BoxProps {
	num: number;
	x?: number;
	y?: number;
	children?: any | any[];
}

const Box = (props: BoxProps) => {
	const numText = props.num.toString();
	return (
		<body type={BodyMoveType.Dynamic} scaleX={0} scaleY={0} x={props.x} y={props.y} tag={numText}>
			<rect-fixture width={100} height={100}/>
			<draw-node>
				<rect-shape width={100} height={100} fillColor={0x8800ffff} borderWidth={1} borderColor={0xff00ffff}/>
			</draw-node>
			<label fontName='sarasa-mono-sc-regular' fontSize={40}>{numText}</label>
			{props.children}
		</body>
	);
};

We use a React-like functional component approach to define our box components, where:

• body component’s tag attribute: stores the score of the box.
• rect-fixture: defines the collision shape of the box.
• draw-node: used to render the appearance of the box.
• label: displays the score on the box.

3. Creating TSX-Instantiated Object References​

Use useRef to create two reference variables for later use, one for the bird and one for the score label:

const bird = useRef<Body.Type>();
const score = useRef<Label.Type>();

4. Creating the Launch Line​

The launch line is created by the line variable, and touch (or mouse click) event handling is added:

let start = Vec2.zero;
let delta = Vec2.zero;
const line = Line();

toNode(
	<physics-world
		onTapBegan={touch => {
			start = touch.location;
			line.clear();
		}}
		onTapMoved={touch => {
			delta = delta.add(touch.delta);
			line.set([start, start.add(delta)]);
		}}
		onTapEnded={() => {
			if (!bird.current) return;
			bird.current.velocity = delta.mul(Vec2(10, 10));
			start = Vec2.zero;
			delta = Vec2.zero;
			line.clear();
		}}
		onMounted={world => {
			world.addChild(line);
		}}>
		{/* ...create other game elements under the physics world... */}
	</physics-world>
);

• In the onTapBegan event, record the starting touch location and clear the launch line.
• In the onTapMoved event, calculate the distance moved by the touch and update the launch line.
• In the onTapEnded event, set the launch velocity of the bird based on the touch movement and clear the launch line.

5. Creating Other Game Elements​

Next, we continue creating other elements in the game scene under the <physics-world> parent tag:

5.1 Ground​

First, we use the body component to create the ground and set it as a static body:

<body type={BodyMoveType.Static}>
	<rect-fixture centerY={-200} width={2000} height={10}/>
	<draw-node>
		<rect-shape centerY={-200} width={2000} height={10} fillColor={0xfffbc400}/>
	</draw-node>
</body>

• type={BodyMoveType.Static}: indicates this is a static body, unaffected by physics simulations.
• rect-fixture: defines the ground’s collision shape as a rectangle.
• draw-node: used to render the appearance of the ground.
• rect-shape: draws a rectangle in yellow color.

5.2 Boxes​

Next, we use the previously defined Box component to create 5 boxes with different initial positions and scores, and play their entrance animations upon creation:

{
	[10, 20, 30, 40, 50].map((num, i) => (
		<Box num={num} x={200} y={-150 + i * 100}>
			<sequence>
				<delay time={i * 0.2}/>
				<scale time={0.3} start={0} stop={1}/>
			</sequence>
		</Box>
	))
}

• map function: used to iterate through an array of scores from 10 to 50, creating a box for each score that needs to be hit by the bird.
• Box component: used to create boxes, with the following properties passed:
  • num={num}: the score of the box, corresponding to the number in the array.
  • x={200}: the initial x-axis position of the box, set at 200.
  • y={-150 + i * 100}: the initial y-axis position of the box, incrementally adjusted based on the creation index.
• sequence component: used to create an animation sequence to be played on the parent node, including the following animations:
  • delay time={i * 0.2}: delays the animation playback, with the delay time incrementing based on the creation index.
  • scale time={0.3} start={0} stop={1}: scale animation, from not visible to fully visible, lasting 0.3 seconds.

5.3 Bird​

Lastly, we use the body component to create the bird and set its collision shape, appearance, and score label:

<body ref={bird} type={BodyMoveType.Dynamic} x={-200} y={-150} onContactStart={(other) => {
		if (other.tag !== '' && score.current) {
			// accumulate score
			const sc = parseFloat(score.current.text) + parseFloat(other.tag);
			score.current.text = sc.toString();
			// clear the score on the collided box
			const label = tolua.cast(other.children?.last, TypeName.Label);
			if (label) label.text = '';
			other.tag = '';
			// play the box collision animation
			other.perform(Scale(0.2, 0.7, 1.0));
		}
	}}>
	<disk-fixture radius={50}/>
	<draw-node>
		<dot-shape radius={50} color={0xffff0088}/>
	</draw-node>
	<label ref={score} fontName='sarasa-mono-sc-regular' fontSize={40}>0</label>
	<scale time={0.4} start={0.3} stop{1.0} easing={Ease.OutBack}/>
</body>

• ref={bird}: uses ref to create a reference variable for later manipulation of the bird.
• type={BodyMoveType.Dynamic}: indicates this is a dynamic body, affected by physics simulations.
• onContactStart={(other) => {}}: callback function triggered when the bird’s physics body contacts another object.
• disk-fixture: defines the bird’s shape as a disk.
• draw-node: used to render the bird’s appearance.
• label: displays the bird’s accumulated score.
• scale: plays the bird’s entrance animation.

6. Completing the Game Logic​

With that, we have completed the core logic of our small game. You can further refine the game logic and add features based on your own ideas. The complete demo code can be seen at this link: Dora-Example/Example/Birdy.tsx. Below are some screenshots of the game in action.

Dragging the screen to launch the "Angry Birds

Skilled moves earned me all the scores in one shot

4. A Little Reveal​

1. Deer or Horse​

In fact, the game code we wrote can ensure consistent performance across Linux, Android, iOS, macOS, and Windows thanks to the capabilities of the Dora SSR engine. However, to run this code, our Dora SSR engine doesn’t even support a JavaScript runtime environment... (What did you say?)

Yes, the underlying technology of Dora SSR is actually based on Lua and WASM virtual machines as the scripting language runtime. Support for TypeScript is provided through the integration of the TypeScriptToLua compiler TypeScriptToLua. TSTL has rewritten the backend of the TypeScript language compiler to compile TS and TSX code into equivalent Lua code, allowing TS code to run on Dora. The Dora Web IDE’s code editor helps with TS language checking, completion, and Dora built-in library API hints. In the end, whether it’s a deer or a horse, as long as the code passes the TS compilation check, it will run just the same.

2. Is There a Connection with React?​

The answer to this question is currently: it could be (thus far, it hasn’t been). React’s most important capability is synchronizing the rendering of components and business data states through the Virtual DOM and Tree Diff process, which has not yet been implemented in Dora SSR. Currently, the code written in TSX for game rendering objects is only built once at runtime, and then the underlying C++ engine functionality continues to handle processing. Maybe one day we will provide a React-like mechanism for game UI development, executing Tree Diff to synchronize state, or a mechanism based on TSX like SolidJS for other rendering component state synchronizations. So here, we sincerely invite all frontend developers to join us, play with the Dora SSR project, and explore how to apply frontend development ideas to game development, bringing more convenient tools into the mix.

Moonscript: A Niche Language with a Twist​

Moonscript is a fascinating programming language that compiles into Lua and runs on the Lua virtual machine. Its syntax and features draw inspiration from Coffeescript, offering a sweet spot between expressiveness and readability—minimizing code while maximizing clarity. It's particularly adept at handling frequently changing business logic, allowing developers to slash code volumes significantly when compared to native Lua—sometimes down to a third! This not only saves time but also reduces bugs and troubleshooting headaches. But perhaps one of its quirkiest features, as revealed by a seasoned developer in a Discord chat, is its dedicated global but modest-sized user base and its delightful Sailor Moon-themed aesthetic.

Open Source and Free: A Challenging Sustainability​

The creator of Moonscript has developed commercial sites like the indie game marketplace itch.io and the art-sharing platform streak.club using this language. To maintain stability, he paused the addition of new features and slowed down on fixing issues since 2017. Understandably, life's tough, and the creator has set up a GitHub sponsor page hoping for more support for his open-source efforts. It's unfair to expect continuous free contributions from anyone, after all.

Rewriting on My Own Terms​

As a die-hard fan of Moonscript, I couldn't just stand by. The original Moonscript compiler was written in Moonscript itself, with a core parser built in C using a PEG grammar library to generate ASTs, which were then processed back in Lua. This was a resource-intensive process, particularly for large projects where dynamic loading of Moonscript code could cause noticeable lag. Additionally, the dynamic nature of Lua made it ill-suited for handling strict data types in ASTs—a typical weak point in dynamic language development.

So, instead of building on the existing codebase, I opted for a fresh start in my second favorite programming language, C++ (with Moonscript being the first, of course). This rewrite not only solved several unresolved issues but also reintroduced some long-missed programming features from other languages. Check out the new project here: YueScript.

Transpilers for Lua and PEG Grammar​

Nowadays, compilers that generate code in another programming language are more accurately called transpilers. Lua’s simple design allows for fast compilation with a one-pass recursive descent parser. With diverse programming preferences, many have ventured into developing transpilers from various languages like JavaScript, TypeScript, Lisp, C, Python, Go, and C# into Lua. This enhances Lua's capabilities, driven by aesthetic preferences, personalized needs, and advancing hardware that liberates computing power. Even Python’s creator once used a LL(1) grammar to ensure parser efficiency thirty years ago. With today's better hardware, more complex grammars like PEG that allow infinite backtracking for matches have become viable, improving parser flexibility and future language evolution.

The Advantages of C++ in Writing a Transpiler​

Describing Moonscript as a macro system on Lua isn’t far from the truth, as many of its features are essentially syntactic sugar over Lua. The process involves three steps: parsing the code into a Moon AST, converting this AST into a Lua equivalent, and finally translating that into code. C++ shines in handling ASTs with its compile-time and runtime type checking, which minimizes errors significantly. Since C++17, the language has become even more powerful and expressive. For instance, the use of template metaprogramming allows us to ensure safety and efficiency:

// Checking if an AST node is either Exp or ExpList
if (item.is<Exp_t, ExpList_t>()) {
    ...
}

// Fetching the last matching node for a given AST structure
if (auto variable =
    node->getByPath<ChainValue_t, Callable_t, Variable_t>()) {
    auto varName = toString(variable->name);
    ...
}

// Handling different AST structures with a switch statement
switch (node->getId()) {
    case id<While_t>(): {
        auto while_ = static_cast<While_t*>(node);
        ...
        break;
    }
    case id<For_t>(): {
        auto for_ = static_cast<For_t*>(node);
        ...
        break;
    }
    ...
}

YueScript in Action: More Than Just a Language​

Initially, YueScript was tied to an open-source game engine project, Dora SSR (https://dora-ssr.net ), aiming to elevate the capabilities of the Lua-supported engine with an advanced version of Moonscript. Along with the engine’s Web IDE, YueScript also adds modest code completion and type inference features to enhance coding efficiency.

I particularly enjoy using YueScript during Game Jams, brainstorming with teammates and then diving into coding without overthinking the design—a somewhat reckless yet fun approach to programming. Although we still integrate some programming design using Dora SSR’s messaging system combined with YueScript’s functional style. You can see some of our frenzied Game Jam projects in YueScript at Dora SSR's repository.

So, as a dialect of Lua's dialect Moonscript, YueScript not only holds its ground in theory but has also been battle-tested in real applications within the Dora SSR project.

Ever since I was captivated by the magic of Warcraft III MODs in my childhood, I've held a special fondness for game scripting languages. Reflecting back on those days, using Blizzard's JASS language to create levels in Warcraft III was quite basic by today's standards—being statically typed with no garbage collection—but it represented a bold experiment in the early days of game development standards.

Why Use Scripting Languages for Game Development?​

The main purpose of incorporating scripting languages into game development is to enhance the convenience of development and testing. Using lower-level languages like C++ could mean waiting for lengthy recompilations with every single line of code changed. Scripting languages allow for hot-loading of gameplay code, significantly boosting development efficiency.

Over time, dynamic scripting languages like Lua and JavaScript have become regulars in game development. However, as programming languages have evolved, we have the opportunity to redefine the new standards for game scripting languages—a blend of retro and innovation, namely, the combination of Rust and WASM.

Rust + WASM + Dora SSR: Redefining Game Script Development​

Combining Rust with WASM enables us to conduct game updates and testing on devices like Android or iOS without sacrificing performance and without relying on traditional app development toolchains. Moreover, with the help of the Dora SSR open-source game engine's Web IDE interface, games written in Rust can be compiled once and then tested and run on various gaming devices.

Why Choose Rust?​

Rust offers unparalleled memory safety guarantees and operates without the need for a garbage collector, making it ideal for game development, especially in performance-sensitive scenarios. With WASM, Rust not only delivers high performance but also maintains consistency and security across platforms.

Quick Start Guide​

Before diving into development, we need to install the Dora SSR game engine. This engine supports multiple platforms including Windows, Linux, macOS, iOS, and Android. For specific installation steps and requirements, please refer to the official Quick Start Guide: Dora SSR Quick Start.

Dora SSR v1.3.17 running on macOS

Step One: Create a New Project​

Once the Dora SSR engine is running, open the Dora SSR Web IDE in your browser, right-click on the left-side game resource tree, and choose 'New' to create a new folder named 'Hello'.

Accessing Dora SSR's Web IDE and creating a new folder in the browser

Step Two: Write the Game Code​

Next, create a new Rust project from the command line:

rustup target add wasm32-wasip1
cargo new hello-dora --name init
cd hello-dora
cargo add dora_ssr

Write the code in src/main.rs:

use dora_ssr::*;

fn main() {
    let mut sprite = match Sprite::with_file("Image/logo.png") {
        Some(sprite) => sprite,
        None => return,
    };
    let mut sprite_clone = sprite.clone();
    sprite.schedule(once(move |mut co| async move {
        for i in (1..=3).rev() {
            p!("{}", i);
            sleep!(co, 1.0);
        }
        p!("Hello World");
        sprite_clone.perform_def(ActionDef::sequence(&vec![
            ActionDef::scale(0.1, 1.0, 0.5, EaseType::Linear),
            ActionDef::scale(0.5, 0.5, 1.0, EaseType::OutBack),
        ]));
    }));
}

Build the WASM file:

cargo build --release --target wasm32-wasip1

Step Three: Upload and Run the Game​

In the Dora SSR Web IDE, right-click the newly created 'Hello' folder, select 'Upload', and upload the compiled WASM file init.wasm.

Uploading files through the Web IDE

Alternatively, use a helper script to upload the WASM file within the Rust project folder. Here’s the command, where the IP parameter should be the address shown in Dora SSR’s Web IDE after startup, and the last parameter is the relative path of the directory to upload:

python3 upload.py "192.168.3.1" "Hello"

Using a script for one-click compile, upload, and run

Step Four: Publish the Game​

In the editor's left-side game resource tree, right-click the newly created project folder and choose 'Download'.

Wait for the browser to prompt with a download notification for the packaged project files.

How It's Implemented​

In Dora SSR, implementing support for Rust language development and embedding the WASM runtime was a new technical exploration and trial, involving three key steps:

1. Design of the Interface Definition Language (IDL)​

To embed the WASM runtime in a C++-written game engine and support Rust, it was first necessary to design an Interface Definition Language (IDL) to facilitate communication and data exchange between different programming languages. Below is an example of a WASM IDL designed for Dora SSR, based on the native C++ programming interface with added annotations needed to transition to Rust interfaces, such as object, readonly, and optional. One of the challenges in cross-language interface mapping is the object-oriented interface design of C++, as Rust does not provide complete object-oriented capabilities, requiring additional code in Rust to simulate some object-oriented features. Fortunately, this language difference is not overly large or complex to manage.

object class EntityGroup @ Group
{
    readonly common int count;
    optional readonly common Entity* first;
    optional Entity* find(function<bool(Entity* e)> func) const;
    static EntityGroup* create(VecStr components);
};

Considering the differences between C++'s object-oriented features and Rust's design philosophy, we partially simulated object-oriented behavior in Rust, necessitating additional mechanisms in Rust to correspond to C++ classes and methods. Although this approach increased the development workload, it maintained the cleanliness of the interface and the maintainability of the system.

2. Generating Glue Code​

The second step involved writing a program to generate the glue code that facilitates calls between C++, WASM, and Rust through the IDL. For this purpose, we chose to use YueScript, a dynamic programming language based on Lua, developed as part of the Dora SSR project. YueScript combines the flexibility and lightweight nature of Lua with the rich syntax and features necessary for complex code generation tasks, utilizing Lua's lpeg syntax parsing library to handle IDL parsing and glue code generation. Below is an excerpt from the IDL parser written using PEG grammar in YueScript.

Param = P {
    "Param"
    Param: V"Func" * White * Name / mark"callback" + Type * White * Name / mark"variable"
    Func: Ct P"function<" * White * Type * White * Ct P"(" * White * (V"Param" * (White * P"," * White * V"Param")^0 * White)^-1 * P")" * White * P">"
}

Method = Docs * Ct(White * MethodLabel) * White * Type * White * (C(P"operator==") + Name) * White * (P"@" * White * Name + Cc false) * White * Ct(P"(" * White * (Param * (White * P"," * White * Param)^0 * White)^-1 * P")") * White * C(P"const")^-1 * White * P";" / mark"method"

3. Embedding WASM Runtime and Code Integration​

The final step was to embed the WASM runtime and the generated C++ glue code into the game engine, completing the code integration. For the WASM runtime, we chose WASM3, a high-performance, lightweight WebAssembly interpreter that supports multiple CPU architectures. This choice simplifies the complexity of the compilation chain and enhances cross-platform compatibility. By doing so, Dora SSR can support games developed in Rust running on hardware devices with various architectures, greatly enhancing the accessibility and flexibility of game projects.

During the integration process, we released a crate package for Rust developers, which includes all necessary interfaces and tools, enabling developers to easily develop and republish other game modules written in Rust based on the Dora SSR game engine.

Performance Comparison​

Dora SSR supports Lua scripting as well, currently using the Lua 5.5 version virtual machine. Like WASM3, it does not perform JIT compilation of real-time machine code but interprets script codes within the virtual machine. This setting allows us to make some performance comparisons between these two scripting approaches.

Before delving into comparisons, it's evident that disregarding Lua's garbage collection time, the inherent dynamics of Lua mean that C++ mappings to Lua interfaces must perform runtime checks for input parameter types. Moreover, accessing Lua object properties requires runtime searches through a hash table structure—costs that Rust's static typing and WASM virtual machine either avoid or minimize. Here are some basic performance tests focusing on cross-language calling and parameter passing efficiency, specifically selecting interfaces that require minimal computational processing on the C++ side.

• Rust Test Code

let mut root = Node::new();
let node = Node::new();

let start = App::get_elapsed_time();
for _ in 0..10000 {
	root.set_transform_target(&node);
}
p!("object passing time: {} ms", (App::get_elapsed_time() - start) * 1000.0);

let start = App::get_elapsed_time();
for _ in 0..10000 {
	root.set_x(0.0);
}
p!("number passing time: {} ms", (App::get_elapsed_time() - start) * 1000.0);

let start = App::get_elapsed_time();
for _ in 0..10000 {
	root.set_tag("Tag name");
}
p!("string passing time: {} ms", (App::get_elapsed_time() - start) * 1000.0);

• Lua Test Code

local root = Node()
local node = Node()

local start = App.elapsedTime
for i = 1, 10000 do
	root.transformTarget = node
end
print("object passing time: " .. tostring((App.elapsedTime - start) * 1000) .. " ms")

start = App.elapsedTime
for i = 1, 10000 do
	root.x = 0
end
print("number passing time: " .. tostring((App.elapsedTime - start) * 1000) .. " ms")

start = App.elapsedTime
for i = 1, 10000 do
	root.tag = "Tag name"
end
print("string passing time: " .. tostring((App.elapsedTime - start) * 1000) .. " ms")

Performance Results​

Rust + WASM:
object passing time: 0.63 ms
number passing time: 0.59 ms
string passing time: 3.54 ms

Lua:
object passing time: 6.73 ms
number passing time: 2.69 ms
string passing time: 4.23 ms

As observed, aside from string type interface calling, Lua's cross-language calling performance in Dora SSR is almost an order of magnitude slower than WASM's. The slight difference in string handling is likely due to the bulk of performance loss occurring during string object copying, a minor concern compared to cross-language calling overheads.

User Experience Discussion​

Introducing Rust into game development has offered a distinct boost in productivity compared to traditional approaches, especially when integrating with large language models like ChatGPT for code generation assistance. Unlike C or C++—or even many dynamic languages—where generated code might compile but often contains hidden runtime errors and defects such as memory leaks or misuse of pointers and references, Rust's strict compiler environment provides a more stable and secure coding environment for game development.

Rust's ownership and borrowing mechanisms, along with its design for type and memory safety, allow many potential issues to be caught and corrected during compilation. By supporting Rust in the Dora SSR game engine, I've found that scripting for games is not only safer but also more efficient, transforming game development from a process of debugging to one focused more on creation and realization.

Conclusion​

Opting for Dora SSR + Rust as a game development toolkit is not just about being on the cutting edge of technology—it's a new exploration of the game development process itself. I warmly invite every game development enthusiast to join our community and embark on this exciting technological journey. Visit our GitHub repository for more information and to get involved. Let's start a new era of game development together!

Developing my own games has been a dream since childhood, particularly fueled by my extensive use of the Warcraft 3 World Editor. This sparked a fascination with game engines and development tools. As a student, I delved into programming and soon felt the urge to expand beyond just using various programming languages for development. I started maintaining a programming language called YueScript, tailored for writing game logic. My learning journey in graphics led me to rewrite the Cocos2d-x as a learning project, which eventually evolved into the Dora SSR game engine. Later, as my love for handheld gaming consoles grew, I began collaborating on an open, programmable gaming device called the "Auspice Gear", aiming to achieve the ultimate digital freedom in gaming.

The Fun and Challenges of Game Scripting Languages​

Multilingual Playground!

Programming in various languages is exhilarating, as each language offers unique programming philosophies and design principles. For scripting complex and dynamic game mechanics, I prefer using languages that are succinct and expressive. YueScript, translatable to Lua, fulfills this need beautifully. Over time, as I developed more with my Dora SSR engine, I integrated languages like Teal (which adds static typing to Lua), TypeScript (for enhanced code hints and checks), JSX, and XML (for descriptive, componentized development). Each scripting language shines in specific game development contexts and seamlessly inter-operates through translation to Lua. Beyond Lua-based extensions, the Dora SSR engine also experiments with supporting diverse scripting languages via the WASM virtual machine, such as Rust and upcoming support for C++ and Go, balancing performance with runtime expansibility.

Innovating with Game Engines​

Game creation at your fingertips!

While high-performance graphic rendering and complex scene construction are typically associated with game engines, as an indie developer and enthusiast, I believe many 2D games or those blending 2D and 3D effects can also offer highly creative and unique experiences. Ideally, devices for developing and running games should be unrestricted. Thus, Dora SSR was envisioned to provide an accessible and user-friendly environment, or even a full-fledged game development IDE, on as many devices as possible. Game development has become a part of my daily routine, allowing me to enjoy coding and debugging game features leisurely and sporadically, using whatever devices are at hand.

Dora SSR features a built-in Web IDE server within the game engine runtime, enabling code writing, running, and debugging directly on any terminal device via a web browser. This integration provides visual hints and access to various game development and resource management tools. Presently, Dora SSR supports game development on platforms like Windows, macOS, iOS, Android, and several Linux distributions.

Pursuing the Dream of a Free and Open Gaming Handheld​

Open source everything? Want it for both software and hardware!

Despite the progress, the pursuit of an unrestricted and open gaming development experience is far from over. As a veteran handheld gaming enthusiast dissatisfied with many commercial open-source handhelds, I envisioned a device not just for playing games but also for freely developing, running, and even distributing homemade games. Many manufacturers restrict programmability for profit, so with like-minded hardware enthusiasts, we developed the fully open "Auspice Gear", offering modular customization of its core components and design.

Auspice Gear + Dora SSR

Returning to the Essence of Game Creation​

An open-source indie game project made by the community called 'Luv Sense Digital'

So, did I eventually make my game? Yes, though it's not entirely complete yet. Before the generative AI boom of 2020, we envisioned a future where AI played a central role in games—where humans, having their material needs fully met, engage in games to provide creative and intelligent data for AI training. This data, assessed by futuristic banks, determines an individual's monetary worth. The AI trained with this data helps with all aspects of material production, individual nurturing, and social management. This narrative reflects our ongoing quest to define ourselves through our creations rather than being defined by circumstances into which we were born.

If you're interested in our work on programming languages, game engines, gaming handhelds, or our game project, feel free to star our repositories or join our discussion groups. Although our projects are still in their early stages, they are continuously integrated and iterated upon, offering a glimpse into our progress and processes.

We warmly invite everyone passionate about game development to join us. Whether contributing code, providing feedback, or sharing our projects, your efforts help us collectively realize the dream of freely developing games.

Project Links​

• Game Engine: Dora-SSR on GitHub
• YueScript Language: YueScript on GitHub
• "Luv Sense Digital" Open Source Game Project: Documentation

Behind every great creation lies a story filled with magic. The inspiration for Dora SSR stems from one of my favorite childhood tales—The Wizard of Oz. In this classic story, young Dorothy and her dog Toto embark on a wondrous and challenging adventure alongside their new friends—the Tin Man who lacks a heart, the Scarecrow who lacks intelligence, and the Cowardly Lion who lacks courage.

✨

The journey of the Dora SSR engine mirrors Dorothy’s experience in The Wizard of Oz—a voyage of exploration and discovery. It is not just a technological product but a platform that ignites creativity and brings dreams to life. In this open ecosystem, we yearn for a world of open-source ideals, where everyone can freely contribute and share knowledge within the community. We hope that every developer using Dora SSR will, like Dorothy and her companions, bravely chase their dreams in the realm of game development, overcome obstacles, and discover their true selves.

🚀

In the world of Dora SSR, we encourage developers to seek wisdom like the Scarecrow, explore the depths of love like the Tin Man, and find courage like the Lion. Each game represents a new adventure, and every creative idea is an exploration of the unknown. We firmly believe that through this platform, everyone can find their own “Emerald City”—a place where dreams are realized. More importantly, in this open community, every idea and effort is respected and shared, sparking endless possibilities.

🌍

The strength of Dora SSR, much like Dorothy and her friends, comes from its ever-growing community—a vibrant environment filled with creativity, support, and collaboration. Our community is our very own “Emerald City,” where everyone can find their voice and place. The open-source philosophy allows every developer to participate, collectively building a better world. We believe that true innovation leaps forward only through openness and cooperation.

🔥

Our journey has just begun. Dora SSR will continue to grow and evolve, much like the characters in The Wizard of Oz, constantly learning, advancing, and surpassing themselves. We look forward to witnessing more creativity and miracles emerge on this platform and hope to attract like-minded individuals through the power of open source, together writing the chapters of the future.

🤝

Therefore, let us join hands and strive together to continue our own “Wizard of Oz” story in the magical journey of Dora SSR! On this journey, everyone can become Dorothy, and every creative idea has the potential to become the next miracle. In an open world, we dream together and achieve together.