Easterthon 0.2

What is it?

Easterthon is the beginning of a freeware substitute for Marathon. It's aimed at mapmakers who would like a game engine that's more flexible and less quirky than Marathon itself, and at programmers who would like an engine with source code that they can study and hack.

Why is it called Easterthon?

Because I wrote it during Easter 1996, and I haven't thought of a better name yet.

What does it do so far?

Improvements over the Marathon engine:

Requirements

On a 68K machine it requires and FPU. (It will run with SoftFPU, but it's so slow that there's no point.)

There is a PPC binary included, but I have nothing to test it on, so I don't know if it works. (The 68K binary will not run on a PPC because the PPC doesn't emulate the FPU instructions.)

How do I get it?

Simple - just click below:

Easterthon0.2.0.1.sea.hqx

277970 bytes; last updated 5 Sept 1996

Note: I forgot to include the ResEdit "Templates" file in an earlier version of the above. If you're missing it, you can get it on its own by clicking below:

Templates.hqx

3461 bytes; last updated 5 Sept

If I like it and want more, what do I do?

Send me email and let me know! The more encouragement I get, the more likely I am to continue work on it.

If you're a programmer and want to contribute some code, you're welcome. If you want to write a level editor for it, you're particularly welcome...

Frequently Asked Questions

The answers to all the questions below are tentative. Easterthon is still in the very early stages, and I'm trying out many different ideas to see what works best. I don't really have much idea what Easterthon will turn out like in the future!

Will Easterthon be it's own game, or just an engine made for third-party developers?

Mainly the latter, although I may come up with a game or two of my own based on it.

Why are textures limited to 128x128 pixels?

Because my inner texturing loop doesn't have enough registers for a variable texture size, and I made an arbitrary choice. I hope to remove this restriction one day, but in the meantime it isn't really a limitation, since you can always divide a large picture into 128x128 pieces.

Will it incorporate slanted surfaces?

Maybe, maybe not. There are two problems with slanted surfaces: (1) It's difficult to texture map them fast; (2) they don't fit very well into a 2.5-D world model. If I happen to think of sufficiently neat solutions to both of these, I will incorporate them.

How will it handle enemies? Pixmaps or polygons?

So far, pixmaps. In the future, maybe both. Poly-oriented objects are good for some things, not so good for others, so it may be worth having both sorts available.

How flexible will the physics model/AI/anything else be?

My current plan is to provide a scripting language with which you can program the behaviour of just about everything. So the answer is more or less "limited only by your own ingenuity".

Will it incorporate networking?

Eventually, but not right away. I want to concentrate on getting the basic engine right first.

How will lighting be handled?

I hope to improve on Marathon by giving light sources positions in the world and calculating the intensity of the light cast on each surface based on their relative positions. Initially the light sources illuminating each surface will be determined in a fairly simple way, e.g. by considering all the light sources located within a room to be illuminating that room. Propagation of light from one room to another through openings might be possible as well - I'll have to experiment.

Will it have water? If so, will be done like Marathon, like Quake, or a new system?

I haven't thought about this yet. I'm open to suggestions.

Have fun,

Greg

greg@cosc.canterbury.ac.nz