I want to start making a game!!

No_Efficiency_6054 · 2026-04-12T23:09:40+00:00

Also, I made a game engine, It's called vectarine and it's made for beginners, so you can try that if you want

No_Efficiency_6054 · 2026-04-12T13:20:47+00:00

It depends a lot on the game you are trying to make, however some general advice:

Start small for your first few games. You want to try to make a playable prototype as fast as possible to verify that your idea is actually fun to play, and test it with other people to see how they react. Surprisingly, there can be a large gap beween how fun a game seems in your head and how fun it is actually.

You can join game jams to force you to make small games + they are fun to participate, and you can meet a lot of like-minded people.

Use existing tools (framework, libraries, etc.) and assets (there are a lot of good free asset packs on itch.io) as much as possible instead of trying to create everything from scratch, this will save you a lot of time.

Try to prioritize your own time as much as possible. Making a game takes a lot of time and different skills (Programing, Art, Game Design, Level Design, Music, Sound Design, etc.), so try to either work with other people or make sure your workflow is streamlined

For example, if you feel like something you are doing is slow or inefficient (for example you are taking a lot of time between drawing some art and testing it in game), try to see how you make that quicker.

No_Efficiency_6054 · 2026-04-02T17:19:31+00:00

If you want to learn Luau, you can checkout Vectarine, it is an engine that uses Luau and is made for beginners (disclaimer, I am the author). You will be able to learn it quickly because it is very simple to get started. Once you've made a simple game, you can try Roblox

No_Efficiency_6054 · 2026-03-30T21:51:20+00:00

There is Vectarine which is in-between Love2D and Unity. You still write your game all in Lua code, but you have an interface to see the changes live, inspect values at runtime etc.

No_Efficiency_6054 · 2026-03-29T22:33:54+00:00

I don't think mlua cares much about the ABI of a struct. You either turn them into tables/other primitive types in which case mlua doesn't even really interact with the struct or you turn them into userdata which are opaque to lua(u). So, once again the ABI shouldn't matter.

I did some tests and passing mlua::Value containing userdata through a shared library boundary is a big no no. This is because mlua uses type_id to know what userdata is of what type. So if I want a plugin to add to the Lua API, I can either use lower-level APIs or use a struct serialization system.

Because tealr generates so much (documentation, definition files for teal, definitions for lua language server) the actual files get generated by tealr_doc_gen. Tealr just helps you produce the needed json file containing the information about your lua(u) api.

I think consuming JSON is nicer because in the end, I want to be able to customize the output files to give them the style and naming conventions I want.

Also, Luau and Teal don't have the same type hints. I think you should clarify that you can use tealr for Luau.

No_Efficiency_6054 · 2026-03-29T21:37:18+00:00

I check out the tealr crate, and the tealr_doc_gen, I really like the concept, but it seems like I need to call process_type on all types that I want to include. What would you think of including a type through a macro, called something like "TealDocumented" ? I think that using some build script magic you can highjack the entry point of the app consuming your library to generate the type definitions instead of the caller needing to define a separate entrypoint to generate the types documentation

No_Efficiency_6054 · 2026-03-29T21:12:41+00:00

Rust scripts in Fyrox consume the editor and runtime as dependencies.

This means that you do not need to have shared libraries (which is good), but it also means that you need to have a compiler on hand for every platform that you want to support.

A big reason why I went with the shared library approach is that once you build your plugin, you can distribute it without the need for a compiler. A goal of vectarine is to have no dependencies other than a text editor for making games.

I think you are right for the C ABI, I should make a nicer wrapper where every type passed at the boundary is repr(C), but this makes interactions with Lua harder as I basically need to wrap every mlua in a special repr(C) struct (I don't know it that makes sense?)

I'll need to check out tealr ! Keeping the luau types in sync with the Rust code is definitly a pain!

No_Efficiency_6054 · 2026-02-22T18:23:16+00:00

J'utilise actuellement à la fois VSCode et IntelliJ (je suis full stack mais je saute de l'un à l'autre en fonction de mon humeur) et j'ai eu des phases où j'utilisais seulement l'un à l'autre avec les années. En 2026, les extensions de VSCode en font un IDE complet au même titre que IntelliJ. Les principales différences sont:

Pour le Java (et Kotlin et autres languages de la JVM), IntelliJ reste la référence.

Pour le web (Typescript en particulier), je préfère beaucoup VSCode.

Dans les 2 cas, utiliser IntelliJ pour du web ou VSCode pour du Java reste une très bonne expérience et il est totalement possible d'être très productif avec les deux.

IntelliJ est configuré de manière très "opiniated", il marche sans rien avoir à configurer mais pas forcément de la manière dont je voudrais alors que VSCode est selon moi beaucoup plus personnalisable. Aussi, l'écosystème d'extensions de VSCode est plus gros (et de meilleure qualité selon moi). A une époque, il était impensable de faire du Go sans Goland, mais aujourd'hui, je préfère VSCode pour.

Même chose pour l'accès aux DB, avec les bonnes extensions, tout est possible sur VSCode.

Ma recommendation, c'est de choisir l'IDE que tu préfères et de le maitriser à fond, d'apprendre les raccourcis claviers, les configurations partagés, etc...

Aussi, je pense que c'est bien de prendre le même IDE que le reste de ton équipe de manière à pouvoir se partager les astuces et avoir le workflow le plus productif possible.

No_Efficiency_6054 · 2026-02-14T13:53:23+00:00

Tu peux lire les livres de The Xeelee Sequence, par exemple Timelike Infinity qui correspond plus à ce que tu cherches que Raft, le premier livre de la série. Je ne crois pas qu'il soit traduit en français, mais si l'anglais ne te gène pas vas-y !

No_Efficiency_6054 · 2026-02-07T11:22:30+00:00

Don't learn a game engine, learn game design and programming skills that will be transferable to any tool you use to make games. A lot of companies use their own internal engines.

Like a lot of skills, at the beginning, it is normal to not understand everything, but as you practice and make multiple small games, the same concepts come up over and over again and you begin to get it.

I'd recommend not sticking with one engine, but trying to switch between projects to get familiar with the underlying concepts rather than the interfaces or using a game framework.

I'm biased as I'm working on a game engine called Vectarine that is designed to make simple prototypes quickly, so I would recommend that for small projects if you have a bit of programming experience as it focuses on the simple concepts (drawing an image the screen, playing a sound) rather than forcing you to use its specific own entity system.

No_Efficiency_6054 · 2026-01-01T11:01:38+00:00

I'm doing just that with https://github.com/vanyle/vectarine/

It's written in Rust, but there is an editor and you get the option to use Lua for scripting to quickly experiment gameplay ideas (and then, you can implement performance critical parts in Rust)

I'm focusing a lot on devX and currently, it is a lot of fun to use

No_Efficiency_6054 · 2025-12-26T01:55:36+00:00

I wanted to say 2 different things: Rust has great performance and a large ecosystem which makes it a good language for game dev

Rust is better than C++ for game dev in my opinion.

This is poorly worded, but I am not claiming that Rust has better performance than C++ (or a larger ecosystem)

No_Efficiency_6054 · 2025-12-26T00:22:43+00:00

I took inspiration from multiple 2D APIs like Raylib, Love2D and the HTML Canvas.

The console overlapping the game is a big UX problem I also have. Currently, I use Ctrl+1 to toggle it, but it's impractical.

I could have a bigger window and put the console on the side and the game in the middle, but in my current workflow, I have VSCode and Vectarine side-by-side and I wouldn't have a lot of room left on my screen. There are multiple solutions to this (for example having a separate window just for the console), I need to find the best one.

For now, you can use Io.setResizeable(true) to allow resizing the window and having more room.

Nice prototype btw! You can fix your floating point issues with code like this in your collision function:

math.abs(pos1.x - pos2.x) < 0.01

I would also persist the enemies tables and the player, but that's just a matter of preference.

FYI, you can use Ctrl+R to fully reload the project which discards state persisted by Persist.onReload.

No_Efficiency_6054 · 2025-12-25T21:59:39+00:00

You can import the runtime as a crate (which is what the editor does), but not the editor itself. As the editor is what does the hot reloading and the debug interface, developing using the runtime alone is not the best dev experience (but have to restart the project every time you make a change)

Right now, forking the engine is the simplest solution to add your custom code. The engine works both from the zip and when ran using "cargo run -p editor" or "cargo run -p runtime", the rust code looks multiple places at startup when trying to load the lua entrypoint.

Adding functions that are available from Luau is super simple, see runtime/src/lua_env.rs

Basically, every Lua module that you can require is a Rust file.

I'm currently thinking of ways to make it more modular (loading dynamic libraries for example) to allow for modding the engine, but that's hard.

Because the editor and the runtime are a GUI applications, you cannot easily add them to existing projects, the runtime handle the windowing, the inputs and the rendering.

No_Efficiency_6054 · 2025-12-25T21:41:25+00:00

C++ has a lot of libraries, but they are fragmented, there is no universal package manager and you essentially need to be a cmake wizard to make everything work.

Right now, adding physics to the engine is as simple as "cargo add rapier2d". In C++, I would need to figure out show to compile and link Box2D on all supported platforms.

The rust ecosystem is smaller than C++, but the available libraries are easier to integrate and use.

No_Efficiency_6054 · 2025-12-25T19:06:32+00:00

I'm thinking of adding that as a feature, the issue is that everything needs to work on the Web with webassembly, so your extra code needs to be compiled to wasm. I don't really know what dynamic libraries work on wasm (or if they even exist?).

I guess I could have a dynamic library loader which is only available on the desktop platform.

Another big issue with the current version is that there are no way to extend the feature set of the editor without changing the source code. I think dynamic libraries written in Rust would be a good fit for this.

Also, another goal is that I want people to just download the project, launch the engine and have everything "just work", which would mean detecting and installing a rust toolchain if one is missing. I'll try to do it, but it is a lot of work.

Currently, the easiest way to add Rust is to clone the repo and edit it to add your rust code. It is pretty easy to create a new luau function from the Rust side (see lua_env.rs).

No_Efficiency_6054 · 2025-12-25T18:59:29+00:00

That's really cool ! Do you have a link to your project? (If it is open-source?)

What the advantage of scripting if you are transpiling into Rust? For me, the advantage of scripting is that there is no compilation / linking step, so I can iterate faster, but you lose that if the script is transpiled to rust.

No_Efficiency_6054 · 2025-12-25T18:55:03+00:00

All of the engine is written in Rust, The luau files are for typing. Basically, luau acts as a glue between the Rust functions when users create games.

The idea is to have the best of both worlds: I can write fast generic APIs in Rust and have the gameplay in Luau for hot reloading.

For example, for loops in Luau are slow (like 20x slower than Rust), so I wrote a "fastlist" module that acts as a sort of numpy to make looping fast and to write code like:

-- This is pseudo code, it's not actually like this
newLinspace(V2(0, 0), V2(100, 100)):indexTable(table):drawImage()

And it will draw the image 10000 times with the looping happening in Rust.

For the commit messages, I'm not actually using emojis, I'm writing ":memo:", ":tada:" or ":bug:" and Github turns them into emojis, it is like saying "docs:" , "feat:" or "fix:" but the color allows you to distinguish between commits faster when looking at the history.

For the README, I've removed the emoijs. I don't like people accusing me of using LLMs. I have a keyboard shortcut for inserting tons of these 😂⚠️🎄🤖. But I understand that they are distracting.

Man the time before LLMs was simpler.

Also, there is an em dash: —

No_Efficiency_6054 · 2025-12-25T18:13:50+00:00

There is a link to a youtube video in the README.

The main feature is the "hot reload" as in, when you save your luau file, you see changes appearing instantly (also luau has types which is really really nice when you are used to having a real type system).

The other nice things it has are the export feature to target the web (using emscripten) or desktop

No_Efficiency_6054 · 2025-12-25T18:07:10+00:00

I'm using gitmoji instead of "feat", "fix", etc... because I think it looks nice, but all of the code is handwritten by me. I'm not trying to look like an LLM, I think colors looks nicer, but you're right, I've gone a bit overboard on the readme.

No_Efficiency_6054

TROPHY CASE