Welcome to lolphin.com!
We are a new game studio currently developing a space sim 3D engine built on OpenGL, OpenAL and AH Devel's C++ Sockets library.
The "cakeday" project began as an undergraduate dissertation at the University of Nottingham, and continues as the engine is further developed into a viable platform for space-based games. During development it is being tested with "Asteroids: Adrift", a barebones 3D implementation of the old Atari favourite, "Asteroids".
Watch this site grow.
^ Features
This is a temporary and partial list.
- C++ API
- Fully hardware-accelerated OpenGL/DirectX rendering modules
- Particle effects (smoke, explosions, implosions)
- Dynamic Ambient-Diffuse-Specular lighting system
- Realistic physics response
- Three dimensional sound
- Arena-style network play
- On-screen console and scripting platform
^ FAQ
- Why is your studio called "lolphin"?
Why not?
- Why is your game engine called "cakeday"?
One morning early in development of the original dissertation project happened to be "Cake Day" in the Computer Science department, and this was the day that the engine's codename was born. It just stuck.
- Is this a serious project? Will it actually be useful for anything? What is the goal?
At the moment it's really just a hobby project, but you never know...
- Can I download it?
Nope, sorry!
- When will it be done?
No idea. Hopefully it'll be a viable platform -- or at the very least a good interface -- by September 2009, though.
- Can the engine use DirectX rather than OpenGL?
There isn't a DXWindow implementation at the moment, but the code is modular so all you will need to do is plug in an alternative *Window.o object file and away you go.
- What about OSes? Which will the engine run on?
The engine definitely compiles and runs on Windows and Linux, and is supposed to work on other variations of Unix (including Mac) with some Makefile tinkering.
^ Roadmap for v0.6 - v0.7
This is an incomplete list of the most significant topics drawn up for attention in this portion of development.
Entries will be greyed as accomplished.
Unbundle engine loop, such that game frames run independently of the core timer and entities are updated ASAP and according to how much time has passed since the last update, rather than attempting to update them every Xms and assuming that this was successful and accurate.- Event model for module integration. In particular, a GameEnvironment should have authoritative control over entity creation/destruction, and the Server should handle entity creation/destruction as necessary on receipt of the relevant event function call.
- Tighten up polymorphic entities so that use of dynamic_casting to determine entity type is minimised. All possible public functions should be interfaced rather than sub-extant (e.g. Projectile::getSource() becomes overloaded Entity::getParent()), and a default member flag created such that e->getType() == { ENTITYTYPE_ACTOR | ENTITYTYPE_VEHICLE | ENTITYTYPE_PROJECTILE | ENTITYTYPE_PARTICLE | ...};
Asynchronous geometry loading mechanism through multithreadedness.Use vertex arrays/vertex buffer objects to cache mesh data rather than sending complete models on every frame.Particle beams at the moment are a stream of particles. They have to have very low velocities to maintain the illusion of a continual stream, which goes against the idea that a beam travels very quickly. A new Beam entity type will be created with a start point defined as the entity parent (and travelling after firing has ended) and end point defined (by physics engine) as nearest intersection point. To be drawn with simple glLines for the time being.Dynamic lighting, so all entities will have the ability to function as limited-range light sources, particularly gun fire bursts.- Vehicles will roll/yaw/pitch/strafe/elevate smoothly in the same way that forward velocity changes are gradual.
- Shadows
and particle/beam light sources.
- Bitpacking for CMF (model format) and CMP (messaging protocol); texture data compression.
- Level distinction with some new test levels, including an obstacle course marked out with glowing buoys.
Will need a new long-range third-person view for this.
- Better HUD to include info about current view, weapon status indicator when appropriate (e.g. beam ttl) and RADAR zoom level indicator.
- Menus to allow model selection. Then we can have a smoother transition from coxxon's fantastic BSG models to some original designs.
Fundamentals of a scripting environment, with exposed variables and a command interface (primarily for debugging and game admin purposes, but also for level/model/setting selection in lieu of a full GUI).