July 19, 2019

MyWorld Meetup - 7/6/19


  • The scripting engine is almost done!
  • Almost all language features for v1.0 are complete.
  • Virtual machine is much faster than most existing LSL implementations


  • Q (Zauberin) – Will the scripting language have compile time type error checks?
    • Initially, no – the language is fully dynamic (like Python, JavaScript, and most traditional scripting languages).
    • The language grammar can easily accommodate static type declarations later, and we’re open to adding optional static typing in the future. Also, it’s much easier to add static typing to a dynamic language than it is to add dynamic typing to a static language – since dynamic languages don’t care about types, it’s no big deal to force an exact type at a particular point in the code – it’s much harder to cleanly broaden types in static code where an exact type is expected.
    • We’ve started with a dynamic language for two reasons.
      • Most people expect a scripting language to be dynamic, not static. We really want to avoid surprises as much as possible with the scripting language and make it fast, intuitive, and easy to work with. Static typing doesn’t necessarily interfere with that (a good type system should clarify code and stay out of the way), but since scripting languages are traditionally dynamically typed it’s a good starting point.
      • A good type system is time consuming to implement, and time is at a premium right now. Compilers for dynamically typed languages are much faster and easier to implement, and the dynamic runtime is powerful enough to easily accommodate a statically typed language later.
  • Q (Zauberin) – Since static typing is determined per variable, would the static extensions be determined per-variable with something like an if-def or a pragma?
    • No – If/when we implement static typing, it will work by adding types to variable/parameter declarations… for example a statically typed string declaration would change from “var myVariable” to “String myVariable.”
    • There are some fascinating options for integrating dynamically typed code into statically typed code…
      • You can treat the dynamic object as having a “wildcard” type and automatically allow all calls to that type (this is essentially what TypeScript does).
      • You can disallow dynamic objects in partially-static expressions and require a cast or type coercion to make the expression fully static.
      • Different programmers may desire either warnings that they can ignore or a full error if the compiler encounters a dynamic type in an otherwise static expression.
      • We may take the approach Groovy does – all code is dynamic by default, but annotating methods or classes as static enables and enforces static typing rules only on those sections. This tends to give clean ways to mix static and dynamically typed code.
  • Q (Zauberin) – What string encoding will MyWorld’s script engine use?
    • Internally, it piggybacks off of Java’s strings, which are UTF-16 encoded in memory. However, it’s advisable to use explicit string encoding during I/O to avoid ambiguity. MyWorld uses UTF-8 in virtually all I/O operations.
    • In general, Java supports Unicode very well so this isn’t a huge concern for us as long as we have feature-parity with Java (which we essentially get for free with our implementation).
  • Q (FordLady) – What’s the timeline for release looking like? Are you on track for the planned release date (September 1, 2019)?
    • We’re not sure – I (Daniel) have unfortunately had to take more time off of the project in July than I hoped to. We’ll see how things go in August. At this point, I think it’s likely that we’ll postpone the September 1st date for alpha, but we may still be able to release before the end of September. We’ll see how things go and plan an official date update in early August.
  • Q (Zauberin) – Will the GOAP AI system be for short or long term NPC planning?
    • Both – GOAP planners can be as short or long term as you like. You model world states and a set of actions that the AI agent can take, and the solver finds a (hopefully) ideal sequence of actions to accomplish the goal state. Time is irrelevant to the planning, but if something else (a player, another AI agent, etc.) changes world state in between actions running, it may be necessary to re-plan subsequent actions to fit the new world state. GOAP itself doesn’t care about time, but interference in the world state by other agents may make it necessary to re-plan.
  • Q (Zauberin) – Would it be possible to give NPCs an intelligence stat such that they could be made more likely to make bad decisions?
    • That’s difficult in that characterizing a decision as “good” or “bad” is difficult in AI. GOAP planners typically rely on heuristics for “cost” and seek to minimize the cost of a plan. It would certainly be possible to introduce randomness or some other means of fuzzing the heuristic to make an NPC make “poor” (suboptimal) choices, but it’s difficult to predict how unintelligent your NPCs will really appear to be in general. Heuristics that introduce foresight into how the agent’s actions will influence the future could be limited to utilizing less foresight to simulate a low intelligence stat, although this could also be tricky for making the NPC seem less intelligent to a human observer. Without a characterization of how humans perceive the intelligence of an AI, it’s difficult to come up with a reliable way to make certain NPCs seem more or less intelligent.
  • Q (Zauberin) – Would it be possible to simulate insanity by modifying the behavioral traits of an NPC?
    • Yes – one advantage of simulating attitude/emotion and using that as a means to choose behavior (part of MyWorld’s planned AI system) is that you can alter the perception process so that an NPC overreacts to minor incidents.
    • We’ve planned a system for passing down traits generationally, with the possibility to modify each trait a small amount (stable but drifting slowly) or a large amount (unstable, one generation may be very different from the last). If each trait has its own stability parameter it’s possible to make some traits more likely to be volatile from one generation to the next. This allows the “culture” of NPCs to respond to events and change slowly over time, just as human cultures (and animal populations) do.
  • Q (Zauberin) – Will players be able to chat with NPCs?
    • There are a lot of different chat systems out there (predetermined responses, language processing tied to a knowledge base, etc.) and many games have very specific requirements. It’s possible that we won’t build one in, or that we’ll build in several alternatives. This is an area we haven’t expanded much on yet, but it’s also an area that’s well established and (relatively) easy for an end developer to add as part of a specific game. Once we have time to flesh out the AI we’ll see what folks are interested in for chat systems.
  • Q (Zauberin) – Will NPCs be able to pass on memories from one generation to the next?
    • Yes, we’re planning ways to have NPCs pass on memories across generations, with the possibility for some accuracy to be lost with each successive generation.
  • Q (Zauberin) – Will there be a system to simulate genetics for things like appearance?
    • We’re planning on ways to pass on intelligence traits but not necessarily physical ones – tying traits to appearance is likely to be very game specific. We’ll probably leave that to specific games’ scripting, but if we come up with a way to meaningfully do this in a game-agnostic way we’ll definitely look into it further.