The State of Agora's Legends

Yeah, there hasn't been an update on it in a while. I did work on the engine a bit more, but completely neglected, broke, and partially removed the ability to play over a network in the process. As you "might as well play normal Cave Story" if you're gonna do it alone, there was simply no reason to release a new version.

(If you're interested, I did add the ability for objects to be solid, such that you could stand on them and ride them around and so on, but it broke bullet detection, so when you shoot objects, your shots think they hit a wall when they shouldn't, an annoying 90% of the time.)

I am currently in the process of completely rewriting the engine from scratch. I started this shortly after its one year anniversary. For now, I am referring to it as "AgL++" and have been almost completely silent that it exists at all.

I am doing this in hopes that I can better fulfill the features I initially promised for Agora's Legends, as the system is now almost entirely Lua-scripted with modular, generic-ized subsystems in the C++ backend, all controlled by it.

This includes both a software (SDL) and hardware (OpenGL) rendering system, closed source (FMOD) and open source (SDL_Mixer) sound system, and whatever else I will need to interchange throughout development. (I'm open to suggestions.) The systems can be completely replaced without the game scripting even being able to tell the difference. (I would have included only SDL_Mixer, but unfortunately I have been unable to play ORGs through it due to a lack of frequency/pitch modulation...)

We now have a more detailed in-game menu system, mod select, and options which are saved and loaded automaticly. No command line parameters exist or are required. (As of yet. Unfortunately, subsystems are currently only changed at compile time; Not at run time.)

The engine is split into a client and a server, where the client has access to everything and the server only has access to the networking subsystem. Akin to Garry's Mod, they execute "cl_init.lua" and "init.lua" respectively, which in turn include "shared.lua" and everything else that is needed, with files that are included in both the client and the server able to tell which it is running from by checking the "CLIENT" and "SERVER" boolean variables.

In singleplayer mode (including whatever introduction map your mod shows), both the client and server are running in seperate threads of the program at the same time, directly linked to eachother without any of the networking stuff initialized at all, and generally the Lua scripts won't be able to (nor need to) tell the difference.

The server loads and runs all of the TSC scripts and object AI. For the most part, the client merely displays it all and tries to predict what the server will say next, except in the case of client-side objects such as the water droplets, which the server obviously shouldn't have to keep track of or tell clients about.

So, for example, ideally you will see a Critter hop when you walk in range of it, then the server will send the message when it actually hopped, and the client will correct its position and movement by a few pixels mid-air, and again when the server says "The Critter has landed" and means it more literal than a code phrase.

In order to be multiplayer, a mod will need to be specificly modified for it, mostly in the case of bosses and other non-respawning entities that you might want players to fight either alone or together, and in the case of tiles that are scripted to change between being solid and otherwise.

The server will also check the MD5 of a client's files when they try to join, and send anything (which is required by a client) that doesn't match, including map data (sans tsc scripts) and client-side Lua files, which will all be stored in a seperate directory according to their MD5 and loaded instead. Thus, a dedicated server can be running a custom multiplayer-only mod which the clients can download and play on that server without necessarily being able to run it in singleplayer.

The main concern is for speed, because the scripts now do all of the binary file loading and control nearly every aspect of rendering; Whenever you enter a new map, the server has to load all of the resources from that map, including objects, and send the objects to the client which has entered the map, then the client has to load all the tiles and render them all to a single static texture, and so on... This process can lag quite a bit, especially running Lua-side, and I am uncertain of how to deal with this.

Hopefully it won't be such an issue. I will likely be posting a short Flash video of my progress soon.