The Pantheon engine is a work in progress. The primary purpose of ProcJam and Theseus was testing the Pantheon Engine to see what it needs most and how well I can use it to make a full game. Now that they're done, here's my notes on how it performed and what I should be working on next.
This was a known shortcoming of the Pantheon engine. I’ve had it on the “To Do” list for a while. The problem, in a nutshell, is that each time I created a piece of world geometry, the engine created another vertex buffer for it, and necessitated another “Draw” call for that piece. In test environments, I had ten to twelve pieces, so it wasn’t an issue. When I got Theseus up and going, I had ten to twelve thousand pieces. That didn’t work so well. So the second day of ProcJam I had to stop for a couple of hours and rework the vertex allocator for world geometry. Once that change was made, it ran really, really well. It rendered the largest maze, with no culling, in under 3ms. I was happy.
These worked as intended, but “as intended” meant writing new particle logic for each particle effect. I’m not unhappy with that approach, but it occurred to me that a few stock effects, written with good parameterization, could cover a large number of use cases. If only I had a project to put them in ...
No centralized GamePlay project
Common items (The Camera, Particle Effects, Agents) need a home so they can be shared across multiple projects. I made several camera fixes in Theseus that won’t automatically get propagated to Dionysus because their Camera classes live in their respective projects. Likewise, the new particle effect classes aren’t accessible in Dionysus either. I can’t put them in Chaos because Chaos is dynamically linked through interface classes and that would just suck. Prometheus is intended to be very low level, non-game related, project. I need a new (statically linked) project to house the more common gameplay classes.
Procedural Geometry Creation
During ProcJam, I was able to procedurally create simple meshes using the Pantheon Engine’s stock methods. The gold coin, the wall quote symbol, and more were created through data only, but there were issues with texture coordinates. The Pantheon system which creates procedural geometry has only been creating test levels. When I used it to create specific items, I found that I hadn’t exposed control of the UV coordinates. When I start creating more convoluted meshes in Dionysus, this will become an important issue.
The UI was easy to create and worked fairly well. Panels are placed in the scene using a percentage of the scene. For example, the reticle panel is placed at (50%, 50%), halfway across the screen, halfway down the screen -- always in the exact center of the screen. This worked great. Unfortunately I also chose the same system for placing widgets on panels. This means that I can center things easily, but the boundaries between the edge of the widget and the edge of the panel are now scaled by the size of the panel. So if a panel is four times wider than it is tall, it It’s horizontal border will be four times wider than its vertical border. This also happens when placing panels in the scene, but is much less noticeable. This system needs reworked to respect both fixed and dynamic positioning for all elements. Also, it would be a huge benefit to add “snapping” such that the edge of a widget automatically aligns to the edge of a panel or another widget without any manual effort.
A “Build” is a particular version of a game. Creating it, in my case, involved putting a bunch of files into a zip file and uploading that zip file to the internet. I already had a “deploy” process, but there were lots of files present that didn’t need to be put in the build. That meant I had to manually delete files (then retest the game) several times before a build was ready. I created 3 builds during ProcJam, and each of those ate more time than they should have. In the future, I need to be more careful about what files get into the deploy folder, and I also need an automated “build process” which creates a build for me.
I didn’t make an installer, that’s one of those things I need to look into. Actually install PhysX. Make sure DirectX is installed. Make sure DirectX is upgraded to the proper level. Check hardware and make sure it meets the minimum requirements. All that good stuff.
Wow, that was easy. I might integrate a music player into future versions, but the sound FX were the easiest part of this whole project.
Prometheus Data Definition Language (PDDL)
Worked great when it worked. I could type up ten lines of PDDL and it would generate 50 lines of C++ code which defined my data and loaded it for me. All I had to do was go to an Init() function and start using the data. The single problem I had was when I had a typo in a PDDL file. Everything crashed with no explanation. I fixed the typo. I also fixed the crash. Last, I fixed how it’s handles PDDL errors in general. At some point, I’d like to add more descriptive errors when parsing PDDL, but I built it on LEX and YACC and they’re not the friendliest beasts.