Hacker News Reader

Comment by golergka | Hacker News Reader

After writing a lot of tools for game designers, I've found a simple rule: if a system you're creating is Turing complete, throw it out and just give them a normal scripting language.

Rationale is simple: game designers will ALWAYS find ways to use the system in the most insanely complicated way, and it's far easier to debug and fix things in a normal programming language rather than another system full of ad-hoc conditions, weird triggers, global variables and other complexity that starts small but always snowballs throughout development.

View on HN

Or, better:

Give them this nice graphical scripting mechanism on one tab.

In another tab, give them a small IDE labelled "RESULTING PYTHON CODE"

Or, give them something as nice as Unreal's Blueprints.

The thing is, unless you're experienced engine development team that has a good track record of creating one of the best engines on the planet, don't expect to create something as good as Blueprints.

I feel like the challenge with stuff like this is that once you edit the resulting code, the original graphical input is no longer in sync. I wish there was a good solution to this.

There are many tools that come close (graphical GUI designers come to mind) by not actually giving you resulting code, but letting you write code separately that interfaces with the graphically designed parts in a well-defined way.

the quick and dirty solution would be that editing the resulting code is a one way street. so, once you edit the code you can't use the graphical interface. it's not a _good_ solution but I guess it's better than not giving the option to users at all

Id use that for baseline boilerplate generation

Id buy that for a dollar

Okay, you got it:

https://developers.google.com/blockly/

When I worked at gamedev, that's how we learned that making several people learn Lua is 10x cheaper and faster then reinventing "visual Lua" from the ground up.

I'm aware this is a stupid reason, but I love that really complex behavior can be programmed in these seemingly simple interfaces because it tricks people that are otherwise uninterested or unaware of what programming is into trying it out. It was part of what 'hooked' me into computer science, to be frank

I recall programming a scenario for AoE2 and becoming increasingly interested in finding the 'boundary' for the most complex stuff (that would still somewhat fit into the design of the scenario I was building).

I also remember using an assisted tool to 'erase' the names of the Triggers in the interface so people couldn't "steal" my scenario. The dumb idiot then lost the version with the Trigger names and now no-one can edit it, at least not with human effort

The scenario is pretty cool though, so at least I still have a playable version to show for it and last I checked it worked in the Steam version of AoE2

It's a wonderful thing, but not something you want in an actual big game project.

I think this would be a fantastic usecase for Scratch, since it is so much more accessible to kids and a good gateway to all-text stuff.

Oh what wouldn't I give to write triggers for AoE2 in Javascript instead of that atrocious UI.

True! So much frustration coming back to me alongside the nostalgia.

On the other hand I don't think I'd ever have actually done any scripting in those days if I didn't have the ability to tinker about with a UI too (same applies to programming in general: it all started with drag and drop coding in Delphi for me).

I can't help but see a similar pattern in my increasing use of functional languages or approaches: While I wish the world of programming was more functional, to the point where I'm willing to give up some lucrative work so I can avoid the alternatives, I also feel that when I was a beginner the OO approach was much more accessible and did a better job at 'pulling me in' as a proper programmer.

If I wanted to do something, well, here's the keyword or pattern. No need to understand functions-as-variables, map/filter/etc. (let alone reduce and recursion).

Reply on news.ycombinator.com