Exile.plan

Posted by Astryl on Jan. 25, 2014, 7:26 a.m.

I was poking around today, and noticed my old exile.plan file. The .plan file is an old programmer tradition, used for organizational purposes, as a handy changelog and a convenient way to find out what the heck you did the night before. If you remember to update them.

Anyway, the last entry I'd made was in March last year, just before I lost the progress I had made on the engine (Scripting, multi-layered maps, better fake lighting, etc).

The .plan file was one of the few things I'd kept in my Dropbox folder, and I added it in to my active development folder, and started writing a new entry.

I'm posting it here out of interest; writing all of this made my realize just how much I'd actually done with the engine (And it's now truly an engine, no longer a framework).

Read it at your own peril:

Quote: Most recent entry

== .plan file description ==

This is a devlog/changelog of sorts. Each day of development begins with a new section.

Additions to the game are marked with a +, - denotes a removed line.

* is used when a bug has been fixed.

? is used when a bug has been discovered.

~ is something that must be amended/added soon.

Order of entries is sorted descending from most recent to earliest.

== 25/01/2014 ==

~~ 01:27PM

Haven't updated the PLAN file in a long time. Haven't worked on the game in a long time either, so I

guess that's reasonable.

Let's see… recap… Last time I worked on Exile was last March. That's nearly a full year ago, so

there is no doubt a lot of stuff I was intending to do last time that I need to do here…

** READS REST OF PLAN FILE **

Ah, this was the pre-loss project plan. To document the event, in around March/April 2013, I lost

the Exile development folder and was left with a beta release that I had let a few people try out

on my Dropbox account.

This was the version where I had added multi-layered maps, decreased the multiplier for height

offsets, decals and a hand-rolled script system for maps.

This was all lost. In around July/August I picked up the old version of the engine and basically

wiped all previous changes to the engine in preparation for the 7DFPS jam, which I decided to

enter with a simple game called "Abyss". This was going to be somewhat of a 3D First Person

Rogue game, but turned out to be a glorified level editor.

The engine gained an integrated level editor with support only or a single layer of map,

but added walls, ceilings, floors, height offsets for all of these and lights.

Also added was the concept of an EEnt, or Editor Entity. This is part of the spawn system

that allows for dynamic entity spawning without anything having to be hard-coded or any

ridiculous if/else chains.

The lighting in the engine was improved drastically; that is, there is now lighting as

opposed to the color blending that was done in Exile 1.4.

A proper per-pixel lighting shader has been implemented, and an unlimited number of

lightsources are now possible. Additionally, these lightsources can move.

Yet another change was the addition of Line/Line intersect testing for some collision.

This makes collision with walls smoother, and allows me to have walls that are represented

as lines within the editor, instead of actually using a whole tile position.

Height offsets affect collision, as an aside, so ledges and such are possible.

On another front, gamepad support has been added (And tested).

The asset system has received a general overhaul; almost all assets can be referenced by

name instead of an implied index (Which would lead to crashes or graphical glitches).

One last task to perform with regards to this is to allow each map to build a tile index

that references tiles by name and assigns a -local- index to those names; this'll do something

I should've done a long time ago: Render the order in which tiles/textures are loaded completely

inconsequential.

Back to the map system, the format has been left open in order to allow for additional data to be added

relatively easily. The format is a headerless binary file, organized into the following sections:

* Floors (12 bytes per space. TileIndex, Height, Metadata)

* Walls (12 bytes per space. TileIndex, Type, Metadata)

* Ceilings (12 bytes per space. TileIndex, Height, Metadata)

* Entities (12 bytes per space. EntIndex, Height, Metadata)

* Lights (4 bytes, LightLevel)

Each map has a constant size, so the filesize of a map will always be very close to any other.

The current constant size is 1024x1024 tiles, which is larger than the largest old Exile map, and

with better access performance.

The filesize is relatively low, averaging at around 832kb. This will grow as new map sections are added,

and when the named tile/entity indices are implemented, but this is negligible (As long as each map is

roughly < 16MB, I'm happy. Also, some RLE compression can be used to compress all 'empty' or similar sections

of a map, reducing the filesize by a large degree).

Now that I've more or less finalized the structure, I need to add a simple header system, and must section

code off to allow for expansion (Use load_v1(), load_v2(), etc for different map versions).

Additional sections I want to add:

* Floor Decal (12 bytes, DecalIndex, Type, Metadata)

* Ceiling Decal (12 bytes, DecalIndex, Type, Metadata)

* Wall Decal (12 bytes, DecalIndex, Rotation, Metadata)

* Trigger (12 bytes. Type, Meta1, Meta2)

In addition to this, I eventually want to add multiple layers to the map format. For this, a table in the

header will be used. It'll work something like this:

NUM ENTRIES

ENTRY 1 - File Offset

ENTRY 2 - File Offset

ENTRY n

This isn't an immediate problem though; for now, a sense of height can be fudged by using teleport zones.

Moving on, the next major addition is the change to the scripting system. In the original 1.5/1.4, I had

rolled my own archaic scripting system that operated specifically on the map.

In this version, I have integrated LUA, and have introduced the ScriptedEntity. You add these with

the assets.dat file, which adds them to the spawn list. If you add a corresponding EEnt, it'll add

them to the editor too.

I'm in the middle of opening up as much of the engine API as necessary to the LUA scripts, allowing

for a lot to be done. As soon as I have the necessary components ready, I'm going to reimplement the

player code in LUA.

Additionally, I must add a LUA state to the Map type, to allow for map initialization scripts.

Well, that's enough of a recap. Back to work.

- A lot of things

+ A lot of better things

* Quite a few things

? Basically everything

~ Should actually start making the game.

So yeah, that stuff was done.

I guess it's pretty boring to most, but some people might be interested in what I'm doing :P

And yes, I am actively working on Exile again. Put in nearly 12 hours this week, and that was only for the past three days.

What's more, I've completely ditched all IDEs in favor of something far more useful:

Thanks to aeron for alerting me to the fact that gvim was a thing. Though I wasn't too badly off using this setup:

Also, my build process is handled by a hand-built 182 line long makefile… and I haven't done anything but set up the debug project.

Well, I'll leave you guys with a little set of progress screenshots from the beginning of the engine's lifespan up 'til now:

Precursor to Exile:

Another precursor

This one was moving along well. I had even somehow magicked up a hand-rolled MD2 loader/animator that I can't seem to do again, but I forgot something crucial: Working out how my gameloop would handle indeterminate numbers of entities.

Exile 1.0

Exile 1.4 (Lost branch)

Darkhold (Another FPS I was thinking of making

Abyss 0.1 (Exile's engine again, 7DFPS project)

Abyss 0.2

Lightbound…

The lighting in this one bugs me.

Exile 1.5.0.1

DERP.

Exile 1.5.1

The bump-mapping was taking things a bit too far.

Exile 1.5.3

Present day. The same map from the 7DFPS version of Abyss, but with better lighting. Much better lighting.

TL;DR: I don't blame you.

Comments

spike1 10 years, 7 months ago

Wow, its amazing how far the engine has come, including bump mapping and proper lighting :D. How hard was it to program this, did you use any external libraries? Are you planning on any 3d model loading such as obj or are you going to stick with 2d images?

This looks really cool though, I hope you are going to release it as an engine people can use as it looks pretty nice.

Edit:

Also, 832kb! Wow, thats much better than my average 10mb with compression when using blender. I think I'll have to implement some sort of level loading system into that, otherwise the entire level is built, saved and loaded from scratch hence the long loading times :(. How long does it take to load a level in your engine?

Astryl 10 years, 7 months ago

If you take a look at this video:

http://www.youtube.com/watch?v=PJNCjlKh3mI

The second I press Enter at "New Game", the level is loaded. It takes less than 150ms last time I checked, and since the level size is practically constant, it's a good guess that it's still sitting at those speeds.

And to answer your other questions…

Quote:
How hard was it to program this,
Not 'hard', really. The previous two 'engines' were a training ground, and I learn from my past mistakes. It's mostly a rigorous application of stuff I've learned over the years.

Quote:
did you use any external libraries?
Several, including a few of my own. These are:

- GL3W

- SFML 2

- MXMATH (Mega's math lib. Vectors, basically.)

- MIO (Mega's IO lib. String handling, mostly)

- lib3ds (3DS model loading code that I'm not really using)

- libLua 5.2

- SLB 2 (To help with Lua bindings)

- libGME (For emulated music)

Quote:
Are you planning on any 3d model loading such as obj or are you going to stick with 2d images?
OBJ is already loadable, or at least there is code there that claims to load OBJ models. I can't be sure, since the timestamp is dubious (I coded it during one of my really 'early morning' coding sprees last year, so I can't remember).

3DS models are loadable, but can't be animated yet.

Models aren't priority in this version though. That's a job for my next project :P

Quote:
I hope you are going to release it as an engine people can use as it looks pretty nice.
I'm thinking about it… though I'd have to first make sure that people can use it. I might release a standalone variant of the engine that works solely through a LUA interface, which would be a lot easier for people than trying to work with my arcane code.

EDIT: I have got last year's public release up on GitHub still… Poke around if you're brave: https://github.com/64Mega/SpectrumEngine

death 10 years, 7 months ago

Interesting work. it seems you got the bulk of the good work in more recent times with bump-mapping and good lighting, which is impressive looking (way better than my chunky lighting). It's also good to know that you're still working on this :P