Leave these fields empty (spam trap):
Name
You can leave this blank to post anonymously, or you can create a Tripcode by using the format Name#Password
Comment
[i]Italic Text[/i]
[b]Bold Text[/b]
[spoiler]Spoiler Text[/spoiler]
>Highlight/Quote Text
[pre]Preformatted & Monospace Text[/pre]
[super]Superset Text[/super]
[sub]Subset Text[/sub]
1. Numbered lists become ordered lists
* Bulleted lists become unordered lists
File

Sandwich


Harm Reduction Notes for the COVID-19 Pandemic

Script-Oriented Game Design Patterns?

Reply
- Fri, 21 Feb 2020 15:01:57 EST T/9YlMHx No.38504
File: 1582315317098.jpg -(32683B / 31.92KB, 400x400) Thumbnail displayed, click image for full size. Script-Oriented Game Design Patterns?
I'm having trouble finding any good resources for how to design my game around scripts.

It's not hard to parse an XML file and get data from it. It's even easier to use Java's ScriptEngine on a JavaScript String... Heck, you can even use Java as it's own scripting language with runtime compilation/reflections.
Actually creating script files / reading the data isn't the problem I face.

Thanks to Unity's massive popularity: when I try to look up design conventions for using scripts (in games), all I get is Unity tutorials.
I'm sure there's an obscure video with 2 views on it which answer's my question, I'm skeptical YouTube's algorithm will ever deem me worthy of seeing it, however.

My question is how should I use scripts properly? How do I design my code around scripts?

My goal is to write as much of my game as possible with Scripts instead of code. I intend the actual executable to be more of an engine/interface as a go-between between my scripts and Java / the various frameworks I'm using. I am aware of the extra processing overhead scripts add, but I'll just deal with that in loading screens. Being able to add new scripts at runtime is cool but not mission-critical.

Right now it feels like I could do ANYTHING I want with scripts, and I mean... functionally speaking, yes. But that's exactly the problem. It's exactly how I felt when I first discovered a Singleton. Needless to say, if someone feels like they can do "literally anything" they want, it's a sure sign they're about to do something stupid.

Is there a set of conventions / best practices/design patterns specifically concerning an application that revolves around scripts? I have no idea where to begin.

Any reading/resources concerning Script-Oriented software design would be greatly appreciated, thanks!
>>
Cornelius Donnertudge - Sat, 22 Feb 2020 18:01:15 EST x6K3CZQk No.38505 Reply
>>38504
You probably want a game architecture book http://gameprogrammingpatterns.com/ (you can get this on libgen.is) to cover the best practices of general design that apply to any engine like Unity/Godot even if you're using UnityJS or some other scripting, meaning you want to make a change later and not have to update a hundred scripts to do so. Depending on what you're doing you may want to check out Godot engine too, because IIRC Unity has an IPO this year, this means investors will want returns and more and more Unity things will be 'cloud' or pay access after the IPO.

'Script oriented design' is basically the same as any architecture design really except you may have to inline performance optimizations, which there are tutorials for this on Unity's website that I played around with once but otherwise I have almost no real experience.
>>
Fucking Chadgestick - Sat, 22 Feb 2020 21:53:09 EST CXDAbT7D No.38507 Reply
>>38505
Is the book you link different than the other Game-Programming Patterns books out there? They all just seem to adapt the Gang Of Four's book but with engine specific use-cases in a gaming context.

Besides trying to teach an "Observer" in a game context, most of the books i've looked at it's still an Observer / Client at the end of the day. Just with a game-specific example.

Also, my appologies, I shouldn't have mentioned Unity at all in my comment. I am programming my game in libGDX & apache for Java 8.

I brought up Unity because that's all you find if you type the words "game" and "script" into youtube nowadays.

(I have no strong positive or negative feelings about Unity. It just doesn't meet my functional requirements, too much overhead, monowindow etc.)

I'm not asking how to write Scripts for unity.

I'm asking how to write a program that handles scripts properly.

I'm technically building a set of devtools / workspace ontop of libGDX, and have several small games planned at each stage of this engine's development. Building from simple casual arcade stuff to the final game that has me trying to build an engine in the first place.
>>
Fucking Chadgestick - Sat, 22 Feb 2020 23:15:05 EST CXDAbT7D No.38508 Reply
1582431305534.png -(23891B / 23.33KB, 537x849) Thumbnail displayed, click image for full size.
This is essentially what my stack will look like if it helps.
>>
Polly Geffingwater - Sun, 23 Feb 2020 07:47:51 EST u6kjJlMz No.38509 Reply
From Game Engine Architecture:

>Script code can play all sorts of roles within a game engine. There’s a gamut of possible architectures, from tiny snippets of script code that perform simple functions on behalf of an object or engine system to high-level scripts that manage the operation of the game. Here are just a few of the possible architectures:

>Scripted callbacks. In this approach, the engine’s functionality is largely hard-coded in the native programming language, but certain key bits of functionality are designed to be customizable. This is often implemented via a hook function or callback—a user-supplied function that is called by the engine for the purpose of allowing customization. Hook functions can be written in the native language, of course, but they can also be written in a scripting language. For example, when updating game objects during the game loop, the engine might call an optional callback function that can be written in script. This gives users the opportunity to customize the way in which the game object updates itself over time.

>Scripted event handler. An event handler is really just a special type of hook function whose purpose is to allow a game object to respond to some relevant occurrence within the game world (e.g., responding to an explosion going off) or within the engine itself (e.g., responding to 16.9. Scripting 1143 an out-of-memory condition). Many game engines allow users to write event handler hooks in script as well as in the native language.

>Extending game object types, or defining new ones, with script. Some scripting languages allow game object types that have been implemented in the native language to be extended via script. In fact, callbacks and event handlers are examples of this on a small scale, but the idea can be extended even to the point of allowing entirely new types of game objects to be defined in script. This might be done via inheritance (i.e., deriving a class written in script from a class written in the native language) or via composition (i.e., attaching an instance of a scripted class to a native game object).

>Scripted components or properties. In a component- or property-based game object model, it only makes sense to permit new components or property objects to be constructed partially or entirely in script. This approach was used by Gas Powered Games for Dungeon Siege. The game object model was property-based, and it was possible to implement properties in either C++ or Gas Powered Games’ custom scripting language, Skrit (http://ds.heavengames.com/library/dstk/skrit/skrit). By the end of the project, they had approximately 148 scripted property types and 21 native C++ property types.

>Script-driven engine. Script might be used to drive an entire engine system. For example, the game object model could conceivably be written entirely in script, calling into the native engine code only when it requires the services of lower-level engine components.

>Script-driven game. Some game engines actually flip the relationship between the native language and the scripting language on its head. In these engines, the script code runs the whole show, and the native engine code acts merely as a library that is called to access certain high-speed features of the engine. The Panda3D engine (http://www. panda3d.org) is an example of this kind of architecture. Panda3D games can be written entirely in the Python language, and the native engine (implemented in C++) acts like a library that is called by script code. (Panda3D games can also be written entirely in C++.)
>>
Basil Sillernane - Sun, 23 Feb 2020 23:04:11 EST CXDAbT7D No.38510 Reply
>>38509
Yeah that looks like it could be a good read. I'll just shoplift it from my library instead of libgen tho. (I don't like e-books if there's a hardcopy alternative)
>>
Esther Sovingdidging - Mon, 24 Feb 2020 03:11:53 EST u6kjJlMz No.38513 Reply
>>38510
Well you are a Java programmer. Keep making bad decisions.
>>
Cornelius Gullystone - Wed, 01 Apr 2020 15:45:41 EST S0dGIlDe No.38545 Reply
>>38504

Jesus christ, I can't stop laughing at that cat.

Thanks, OP.
>>
Ian Duckdale - Thu, 02 Apr 2020 20:36:05 EST 5B13wTGc No.38548 Reply
>>38504
Scripts are still code. Maybe you meant data vs. code? Like a game which mainly consists of data and only a small amount of code?

Report Post
Reason
Note
Please be descriptive with report notes,
this helps staff resolve issues quicker.