The adventures of BurekTech
Posted 3 years ago2020-12-01 19:27:28 UTC
As I don't feel that this belongs to any forum category, I've decided to write about it in journals.
In my last journal, "GoldSRC + Godot = ???", I wrote about the idea of a game engine/framework built on top of Godot, that aims to have a workflow very similar to GoldSRC. You can map for it with J.A.C.K., TrenchBroom, or even Hammer in theory, AND sell games made with it. Then I stopped working on that and moved back to my ioquake3 fork, BurekTech. Same idea, different engine.
WE SQUASHED THEM BUGS3 big issues were closed this month, pushing the completion from 11% to 29%. I ported a good chunk of the game code from C/idTech 3 way to C++/BurekTech way.
What this means is, instead of a bunch of global functions and structs, I now have some classes responsible for the game logic (entity spawning, for example), as well as some entity classes. So I didn't just rename all .c files to .cpp and fix the compile errors.
Looks like a ghost town when no entities are 'roundAfter all the remaining required functionality is ported (spawning temp entities, selecting a spawnpoint (the player spawns at 0,0,0 at the moment), making sure MP works), the next step is to re-implement some important
Another concept I had was entity semi-components, but certainly won't be in version 0.1.
BurekTech is not really an engine IMO, since most of the work is done in the game library. It's not an engine-agnostic game framework either. It's like... a game base? I dunno.
With that said, BurekTech 2.0 should be initially based on a different engine like Godot (partially due to licencing), most likely as a plugin. The idea is still gonna be the same. The folder structure is still gonna be (largely) the same. You get the point.
Anyway, I hope that BurekTech will be ready enough by the end of December, so I can start making a game in January. Or in February. It's gonna be a medium-paced retro FPS, set in 2033 Bosnia. I might post a few screenshots in the WiP screenshots thread.
In my last journal, "GoldSRC + Godot = ???", I wrote about the idea of a game engine/framework built on top of Godot, that aims to have a workflow very similar to GoldSRC. You can map for it with J.A.C.K., TrenchBroom, or even Hammer in theory, AND sell games made with it. Then I stopped working on that and moved back to my ioquake3 fork, BurekTech. Same idea, different engine.
WE SQUASHED THEM BUGSWhat this means is, instead of a bunch of global functions and structs, I now have some classes responsible for the game logic (entity spawning, for example), as well as some entity classes. So I didn't just rename all .c files to .cpp and fix the compile errors.
Looks like a ghost town when no entities are 'roundtrigger_, func_ and info_ entities. Then write some utilities, like for gib spawning; a basic AI for NPCs (the Q3 bot code is big, no way I'm porting that soon D:); and, maybe not immediately, a save-load system.Another concept I had was entity semi-components, but certainly won't be in version 0.1.
With that said, BurekTech 2.0 should be initially based on a different engine like Godot (partially due to licencing), most likely as a plugin. The idea is still gonna be the same. The folder structure is still gonna be (largely) the same. You get the point.
Anyway, I hope that BurekTech will be ready enough by the end of December, so I can start making a game in January. Or in February. It's gonna be a medium-paced retro FPS, set in 2033 Bosnia. I might post a few screenshots in the WiP screenshots thread.
4 Comments
You must log in to post a comment. You can login or register a new account.
In fact, I believe this could be done within a HL mod. But, I won't experiment with that until 2022.
By the way, great job my friend!
Yes. My main support is for TrenchBroom (Quake 3 map format, w/o patches for now) and J.A.C.K. (true Quake 3 map format). I am assuming that TB will eventually get true Q3 format support, with patches. Patches are actually those curved planes you're talking about. They can also be cylinders, cones, terrain etc., basically meshes inside the BSP like Source displacements.
Hammer 3.x is less likely, BUT, as long as you have a q3map2 that supports the Valve 220 format (J.A.C.K.'s q3map2 does), you'll be fine. It's of lower priority TBH.
However, a big issue with Hammer is the textures. Since using GoldSRC-specific formats (MDL, WAD3, HL BSP etc.) is technically illegal in engines outside of GoldSRC, and I wanna make paid games with this engine (and put 'em on Steam at some point), yeah. No. We can forget about Hammer support here.
Anyway, another update: now brush entities are solid and can be collided with. I am almost ready to begin re-implementing some of the most needed entities.