The Amateur 3D Game Engine

Show Your Projects
1

Hi. I’ve talk with Michalis about this so here I go.

I’ve published version 1.0 of my Amateur 3D Game Engine.

This engine is based in the one I wrote for my 2nd PGD Challenge back in 2012. Such engine was written in about one single week and was pretty buggy because the hurry and also because Allegro.pas 5 was in a very early development state in that moment. I’ve fixed a ton of bugs, changed a bit the API and added some basic functionality.

Right now the engine is very simple and lacks a lot of functionality. I have a roadmap but since I’m working on this in my free time it will take time. Note that the engine is Amateur so it won’t be as big or advanced than other engines. If you need something professional, please use Castle Game Engine; the latest releases are really good.

At the moment you can get the engine from here:

Someday I’ll have a proper webpage. You can see some screenshots at the summary page.

2

Thanks for this information. As I mentioned also in private, we welcome talk / announcements about other game engines, and announcements about new game engines in Pascal / open-source are esp. welcome :slight_smile:

Some notes:

  • Looking at the roadmap, I would

    • Add glTF support.

      • To put this advise in a personal perspective: If I would start making a game engine from scratch nowadays, I would definitely support glTF (and I would hesitate do I need to implement any other 3D format :slight_smile: ). glTF has (almost) all features you need for typical games, is efficient to read and render, can be exported out-of-the-box from Blender, has nice open specification, there’s a lot of glTF content to download etc.
      • That is also why in CGE, our focus since many years is now “perfect glTF support”. We’re not there yet, but we will :slight_smile: (some roadmap items: 1, 2, 3)

    • I see your roadmap mentions octrees. From my experience in CGE, I would say that we should have implemented some integration with a physics engine (Kraft, PhysX…, Physics | Manual | Castle Game Engine ) much sooner, and not put so much resources into our own octree implementation. We do have now some work to cleanup remaining bits from “our octrees” and just rely on physics engine for everything.

      • Bottom line: I would refocus the efforts, from “octree” (or any other spatial structure to resolve collisions “on your own”) to “integration with external physics engine to resolve collisions” (like Kraft or PhysX or other alternatives). Using a physics engine is a bigger task, but after the integration – you can just enjoy using something that is already maintained and efficient and can resolve collisions/raycasts for you.

  • I would recommend to add simple docs with simple example.

    • But note that you don’t need a big webpage to start :slight_smile:
    • A README.md with a simple section “## This is how you make a new application using this engine” with a piece of code that shows a typical way to e.g. load two 3D models, one for level, one for monster – this would make it obvious to read :slight_smile:
3

Thanks Michalis. I’m always open to sugestions. :slight_smile:

I have my concerns about glTF maybe because I find it quite “over-engineered”. That doesn’t mean I won’t add support glTF for models or something in the future, I’ll certainly do but I don’t think I’ll use it as main format. I don’t believe that “one solution for everything” is a good idea.

About octrees, yes, currently A3DGE works with octrees in mind. I understand it will be a problem to integrate with any existing physics engine. The idea (for version 2.0 and beyond) is that the world container (my TWorld3D class) will be an abstract class and extend it as a couple of containers: an octree-based (without physics) and a sector-based (Build Engine or IdTech1, again without pysics). Maybe also a container based on a pysics engine but I didn’t decided wich one yet. This way you can select the best way for your game, or even create your own crazy container (the engine is for amateurs, and amateurs love to do things by ourselves :wink:).

The reason I didn’t it this way is because the lack of planning. Version 1.0 is mostly a bugfixing of the original engine I wrote back in 2012 and back then I didn’t plan a lot (I did the whole thing in a single week which amazes me today!). For A3DGE I initially planned a different engine from scratch and started to develop it but I found it would be a little bit complicated so I decided to step back, store what I did (it’s in /branches/pre-2.0), fix the old engine and then use both experiences for version 2.0. And I think it was a very good idea because I made version 1.0 in a few months while it would take years to finish the engine from scratch, and the work revealed that some of the ideas I had for the engine were bad ideas.

Thanks for the advice about the webpage. I was planning a more complicated one, similar to the one I made for Allegro.pas, but I think you’re right: a single README.md with an introduction and a link to the online API documentation should be enough.

4

I’ve uploaded a bug-fix version number 1.0.1. I found a few little bugs that didn’t prevent to build simple games but were a bit annoying sometimes. Also, I have a proper website now: A3DGE - Downloads

BTW I found that Free Pascal has a bug that prevent to compile the Wavefrong .obj unit with optimizations due to an “internal error”. It seems to be fixed on fpc 3.3 but it’s not in the stable branch yet (yuck!).

Also I was testing the new Debian 13 in my brand new computer and I’ve found tha the mouse input is very delayed when compiling for debug (it happens also with Allegro.pas). I have to do more testings. Quite annoying.

1 Like