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?
- Basic 3D rendering engine
- Physics: Solid walls, gravity
- Simple doors
- Sprites: Multiple views, simple animation
- Items that can be picked up
- Status window: Inventory list, item picture
- Pop-up windows for interacting with items
Improvements over the Marathon engine:
- There can be more than one floor/ceiling visible in the same
horizontal place, so true ledges, bridges, etc. are possible.
- There are no restrictions on the number of polygons or
textures you can have in one level (other than available memory).
- A room can have any number of walls (although rooms must
still be convex).
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