3 ms·

> Start with writing new code in Lua (faster to prototype) and then see if you need REALLY to move this code (or parts of it) to C++. This is the only part of

> Start with writing new code in Lua (faster to prototype) and then see if you need REALLY to move this code (or parts of it) to C++. This is the only part of the article I disagree with. I've found that the biggest problem with using Lua in a C++ game is writing code in the "wrong" language, and the mess that can cause. The boundary between Lua and C++ needs solid validation to keep bugs out, and this makes it neither performant nor convenient, so minimising the boundary is important. As soon as code ends up in the wrong language, you generally need to add a large amount of unnecessary boundary code. An important part of designing a Lua/C++ game for me is having a good mental model of what the "right" language to write any piece of code in is, and only deviating from that when performance mandates.

eliasdaler 4y ago
I think I should clarify this in the article further. What I meant to say is: "after you've implemented the basics, e.g. input handling, basic renderer, file I/O etc. and you've got a basic game running, then you can start with prototyping code in Lua". I feel like I've fallen into a trap of writing the code in C++ first ("because it's fast!") and then porting it to Lua when I realized that I need to write too much "binding" code. For example, if you're writing a very simple AI, you can write a FSM/Behaviour Tree implementation entirely in Lua and then write AI logic directly in Lua. This way, you won't need to write binding code between Lua/C++ for these FSM/BT implementations. And then, after you've written some code with these structures, you can see if you need to port it to C++ for performance or not. And if you do, it will be easier to design API since you already know which parts you need to expose. One thing that makes prototyping in Lua fast is that the code, which looks simple in Lua, can easily become a pretty difficult template meta-programming code in C++.

eliasdaler 4y ago

I think I should clarify this in the article further. What I meant to say is: "after you've implemented the basics, e.g. input handling, basic renderer, file I/O etc. and you've got a basic game running, then you can start with prototyping code in Lua". I feel like I've fallen into a trap of writing the code in C++ first ("because it's fast!") and then porting it to Lua when I realized that I need to write too much "binding" code. For example, if you're writing a very simple AI, you can write a FSM/Behaviour Tree implementation entirely in Lua and then write AI logic directly in Lua. This way, you won't need to write binding code between Lua/C++ for these FSM/BT implementations. And then, after you've written some code with these structures, you can see if you need to port it to C++ for performance or not. And if you do, it will be easier to design API since you already know which parts you need to expose. One thing that makes prototyping in Lua fast is that the code, which looks simple in Lua, can easily become a pretty difficult template meta-programming code in C++.