SeijiEmery

// en.wikipedia.org/wiki/Levenshtein_distance
public static int levenshtein (String a, String b) {
    final int n = a.length() + 1;
    final int m = b.length() + 1;
    int[] d = new int[n * m];

    for (int i = 0; i < n; ++i)
        d[i] = i;
    for (int j = 1; j < m; ++j)
        d[j * n] = j;

SeijiEmery

#pragma once
namespace defaults {
	
// Default impl of an AABB, and vector / matrix math.
// Data structures are implemented as PoDs; operations are defined as statics in a separate class.
struct AABB {
	float x1, y1, x2, y2;
};
struct Vec2 {
	float x, y;

SeijiEmery

// Java is quite a bit simpler (and c++ is more verbose), but I kinda prefer c++ as its method/function
// signatures are much more expressive w/r to memory management (and yes, this does affect java too, since
// you don't want to be constantly new-ing up objects w/ expensive constructors in that language *either*).
// This assumes you're using const-correctness and references instead of pointers, etc.

// Suppose we have a Vec2 type, and we want to define an addition operation (simple example, but bear with me).
class Vec2 {
	public float x, y;
}

SeijiEmery

// Defines the dynamic protocol that everything uses to communicate with each other.
// This encodes a bunch of keys, implicit integer ids (just indices of the keys), etc., as a lookup table
// that is transmitted when clients first establish contact.
// Of note:
//	- each client has their own, independent, and dynamically-defined protocol / packet translation table.
//	  If client A is communicating with client/server B, A -> B does not necessarily use the same protocol as B -> A.
// 	- This *does* mean that each client has to retain/store a lookup table for *every other* client/server
//    that they're connected to for inbound communications. Servers/clients use the same table for all of 
//    their outbound communications (which they broadcast to everyone else).
//  - The *advantage* of this approach is that A and B can be running different versions without being

SeijiEmery

micropacket architecture:
- Instead of sending C structs across the wire (with multiple specialized packet types), 
 we send lists of key/value micropackets for each XXXXX field / property.

To update an entity whose position, rotation, and angular + linear velocity have changed, you would:
 - Send the entity's id  ("Entity.id", entity.id)
 - Send the entity's position, rotation, and velocity:
   [ ("Entity.position", entity.position), ("Entity.rotation", entity.rotation), 
     ("Entity.velocity", entity.velocity), ("Entity.angularVelocity", entity.angularVelocity)]
 - This gets packed into one big packet, and is prepended with a UDP header and timestamp 

SeijiEmery

- Restructure script interfaces so they can be enabled/disabled on a per-script basis
- Add JS hooks (make interface objects properties w/ getter/setter methods?) so when you try to call 
  {InterfaceName}.{method} for the first time, the script system gets to determine whether access to
  this API is allowed or disallowed.
-- If the script is whitelisted, the call goes through
-- If the script is blacklisted, the {InterfaceName} object is undefined (or we kill the script and
  display an error message showing what happened)
-- If access is indeterminate and the API call in question has griefing possibilities, the script 
  gets paused and the user gets a popup "Script XYZ wants direct access to your audio buffers / 
  entity permissions / run other scripts / whatever. Accept / Deny?"

SeijiEmery

''' High level multithreaded job system.

    Actual impl would be in c++.
'''


class PendingJob:
    ''' Stores a job until it gets executed. Uses reference counting to track depencencies 

SeijiEmery

Suggestion: Entity tree could be much more efficient and simpler w/ a rewrite that uses parallel operations

Current implementation:
 - Octree w/ one model
 – Entities are stored + owned by buckets in the tree
 – Synchronous / immediate operations w/ random reads / writes; thread safety via lock guards
drawbacks:
 - Tree must be locked for reads / writes
 – Operations are synchronous, but order is undefined / random (from a threaded script PoV)

SeijiEmery

//
// This is for a client / server side entity controller / simulator script (one script that handles
// simulations for N entities, instead of N scripts that each do simulations), though something like
// this could probably with entity scripts with some tweaking.
//

var ENTITY_TIMEOUT = 30;  			// 30 secs
var TIMEOUT_REFRESH_INTERVAL = 20; 	// 20 secs

// Entity abstraction class (there will be a JS library that does this for you soon-ish)

SeijiEmery

var ENTITY_TIMEOUT = 30;    // tell entity server to delete us after 30 secs
var TIMEOUT_INTERVAL = 20;  // refresh every 20 secs

function createEntity (properties) {
    properties.lifetime = ENTITY_TIMEOUT;
    var entityId = Entity.addEntity(properties);
    var timeout = TIMEOUT_INTERVAL;
    
    return {
        id: entityId,