There’s a small update, but this post is mostly to preview an update to the dev tools.

It’s pretty much just me that needed to add content before, so the dev tool to add it is rather complicated. The other thing is that I need to make it open ended for various other games. Since updating the dev tool so that it’s easy enough for anyone create highly dynamic content is the first thing I need to do, I’ve been working on planning that out to make sure I’ve accounted for everything and there aren’t any hiccups.

Just like designing anything – architecture, artwork, mechanics – with programming it helps to sketch things out to get a big picture,
You’re writing bits of code, little by little, and you need to have your end result in mind to make sure these pieces come together correctly.

You can see the old tools at: http://www.playlewd.com/blog/?p=143

Here we go, new tool composite:

Firstly, what were called “Events” are renamed to Scenarios. Why? Because the server and client are both event driven, so calling the content Events was confusing. It made sense at the time to call them Events, because when they were triggered it was an event happening for the player. But in programming… “… event-driven programming is a programming paradigm in which the flow of the program is determined by events such as user actions, sensor outputs, or messages from other programs/threads”. Now that I’m opening up the dev tool so that it can be used to make even more different games, it means that there will be hooking functions on events, so calling the content “Events” is very confusing.

One of the main things is that the parameters (the data that is given along with the function name) should show the array used to be more clear. This’ll also make it easy to just click on one of those boxes and be able to see exactly what you can supply, and even have a GUI to select something rather than typing in potentially unknown things.

The other main thing is that the static variables and ways of binding a Scenario are functions at the top.
I did this because there shouldn’t be an assumption that someone wants content to pop up when someone enters or explores areas on a grid. There’s lots of other ways to trigger them, anyway. And as far as variables, someone might want other basic variables for their Scenarios.
These are things that are run when the Scenario is saved, or the server restarts and is loading them all.
A similar thing would be there for players, items, and so on. For example, a variable would be set in this way for their health, and then you’d have a health variable to reference for that player in other places.

There’s three main things that sort of make a game here go around:

Arguments(args) – These are the “if( hungry === true)” things you may have seen before. This is a sort of question that results in true or false. If it passes, it goes on to the functions.
These can be chained together, so multiple arguments must pass before continuing.

Functions(fns) – This is the logic that makes things happen, which run after argument(s) pass, or simply run all the time if there was no argument.
These can also be chained together, so one function happens after another for the given argument(s). A delay function will add a delay for each function after it.

Events(evs) – These are things like: Scenario loaded to memory, Scenario is being instanced for a Player, Player has moved, Player has sent a command.
These are the events that trigger arguments/functions to be iterated through.

Macros  – This is a saved chain of arguments/functions to reuse, instead of having to select them all manually each time you want to do something.

So this is a way to visually see code, and to be able to create it by clicking buttons instead of typing it.
There’s many reasons to do it this way, rather than writing it all by hand:
-The tool handles the context sensitivity. There’s so many different functions, but only certain ones are pertinent to a particular event. There is also the context sensitivity of the parameters passed to arguments and functions. A lot of the time, you just want to run a function on the current Scenario, Item, Player, Area, etc. Instead of adding a lookup for a particular one, the tool handles supplying its parent.
-The tool is directly connected to the game, and other developers.
With all the other dev tools I know of, when you want to see your code run you have to compile it and relaunch the application(s). With this one I’ve been making, it updates the game in real time.
The changes made can be seen in game right away.
New things that are added can be seen by all the other developers on their own tool.
-The game code that the tool plugs in to is as efficient as possible.
Even for people that can write their own code by hand, using this visual scripting gets rid of poor performance and errors. You can select some functions and be sure they work and are as efficient as possible.
-The tool organizes everything
Games often have thousands of items, and other groups of functions.  The tool keeps it all organized.
-The game all runs on the server.
It’s a simulation of the world that keeps in sync with all the client. That’s just a difficult thing for most people to program.
-The dev tool is open source like the client is.
Though the server the resulting export runs on isn’t, the dev tool can still be modified to suit a particular workflow. Say you add custom functions, and the small space for editing parameters doesn’t work well for them, and the “writing” portion for content is too much, well that’s changeable.

I’m proficient at coding and all, and I’d take the tool over writing things by hand every time. It’s saved me a lot of time over when I was adding content by hand. After I do the hard part of making the code that is on the server and the tool, it makes the rest a lot easier.

I’m only showing the composite for the Scenario editing here.  There will be updates to the other parts as well.  The “Map” editor will contain the spots for binding logic to events called due to Map interaction and manipulation.
The new “Events” section where be where misc and custom event callbacks are controlled.

Problems can arise in the tool not being able to do what is needed for a particular, and requiring hand coding. Yeah, that’s something I’ll have to keep working at to make sure it’s as open ended as possible, but it’s off on a good track.
Some people would like it to simply be open source, but people don’t (seriously) ask that of Photoshop, do they?  If a tool is good enough, that’s not needed.
I do want to add a way to add custom hand written programming, and register it as a function just like the hard coded ones so it can be easily reused in the tool.
For example, a global variable can be registered of an array of data. Then a function can be looping on every tile which references that data to figure out whether it should reduce or increase how much “oxygen” is there, like on a space station with doors opening to a vacuum and it getting sucked out or refilling after doors are closed. Then when oxygen is low, it could select players on that low tile and damage them from being oxygen deprived, and/or send a custom event to their client to notify them of the low oxygen.

The other thing is to make sure it’s easy enough, while still being powerful. I think people should have a working game of their own with their own working content added within a few minutes, or hours at the most. There might be things I need to change on that initial design to make it easier or more intuitive. I’ll see as I get there.

Lastly, the little update:

Game:
-Fixed a crash bug created from the last update.
-Name length is now checked when you try to proceed from the first page, to prevent getting to the end only to see that it’s too short.
-Disabled selecting dialog options until the callback is returned. This stops skipping through options when double clicking.

Content:
-The bBot scene in Outpost 833 is now more complete with a sort of puzzle and a potential bad end.