Hello, i'm currently building a card game and i want your opinion about script code inside entity data ! Some developpers tell me is it's a very bad practices, however i already have seen this kind of thing in many projects.

My script :

“State” is my top class that hold all logic and entities of my game.

And now (transform to data only) :

Unfortunally with this way, i have lost possibility to make arithmetic operation or access to variable like “NUM TURNS” or “HP OF DUELIST”.

This is really a bad practice to access object method inside script and make logic inside ?

This is a wide used practice, for example in Magic the Gathering. They're declaring their cards in XML format and have a section included in every card, which describes the gameplay actions. This however has some drawbacks, especially if you have a bad script processor that runs the code but it also has the benefit to be in a position to add new cards without any recompile of the game.

What I've seen in a game engine tech article some time ago is that they didn't allow any gameplay code at all but offer different predefined actions the designers can use. This might be an option for you as well and also supports some kind of visual scripting card editor

https://www.makinggames.biz/news/building-your-own-engine-part-1-getting-ready-for-the-next-generation,6305.html​

You can also move the code to separate file instead of putting the code straight into entity data (which may not be easiest - you already had to do some effort to inject each line separately, some config formats allow going multi-line a bit easier but it's still messy). Something like:

“OnActivate”: {

   “Script”: “opponent_onactivate.script”

},

“OnAction”: {

   “Script”: “opponent_onaction.script”

}

You could even have single script file, as long as your scripting allows you to find specific “hook” - then you'd be able to have just two functions in that file:

function onActivate() { }
function onAction() { }

Separating into file has several advantages:

1. Promotes code reuse as now you can link the same file to different entities without copy-pasting the code
2. Makes it easier to edit as you can open the script files in your IDE and have them syntax colored easier than when editing some text config format with code inlined

With your data driven approach you can always add support for arithmetic - make a simple parser and allow certain fields to contain math syntax, with a simple variable substution even. I use this approach for my render config where, in a data driven way, I can define dynamic things like:

So it's also some solution - depending on how flexible you need it to be ?

Kubernetes even adds logic to simple YAML, where nesting and different operators are part of the map/list structure - but that's pretty ugly IMO.

If you want to inline script code, I'd suggest doing it only for simple event reactions or very small code snippets - literally single func calls. But if the code has multiple lines I'd move it out to files for readability and reuse.

Scripts and data are programming, too. The difference is who is doing it, along with when and how.

Doing it all in the program executable is viable, especially for single person projects. It is small, and if you must recompile the burden is small because it is what you are doing.

Using data becomes more essential when designers, artists, and other roles rather than programmers must make changes, or when the costs of building the code is more significant than the cost of adjusting data. Artists and animators can fill in whatever data is needed, replacing images and whatnot. Designers can easily adjust numbers and abilities in the cards, this does 5 damage instead of 4, this costs 2 instead of 3.

Both work, both satisfy different needs.

Programs developed by teams generally must take data approaches by the strong need for non- programmers to modify values more than anything else.