CopperCube 6 Game Engine

I have a deeply complicated relationship with CopperCube, which is quite common within its small-but-active community. On one hand, CopperCube makes building games truly frictionless. On the other hand, your experience is frictionless only when doing the most basic possible tasks. If your project demands ANY degree of polish, you're going to be fighting this engine constantly. That doesn't mean CopperCube is not worth using, because again, it's complicated. This review is my attempt to document the fundamental issues I've run into as someone who's hated every game building tool they've tried but hates CopperCube less. CopperCube involves severe engine tradeoffs to such an extreme it exists in its own world. The single biggest problem CopperCube has is its rendering engine, closely followed by the extremely restrictive engine API (how user-authored code integrates with the engine itself). [h3] Regarding the Rendering Engine: [/h3] CopperCube was built on top of IrrLicht, an open source 3D rendering engine heavily developed between 2003-2011. This means CopperCube feels very mid-2000's in most places, but downright 1997 in some. Personally, I don't mind the dated graphics in theory. It's DirectX 9 so there's just barely enough tech to squeeze out good visuals with enough effort. Photorealism is logistically impossible, but you can achieve something resembling the source engine as it existed in 2004 with enough effort. It can also handle much larger maps than the source engine, kinda. With super careful optimizations & using folders to hold LOD model sets, I could make some incredibly large scenes, provided I could tolerate the terrain being scaled up without more polygons to compensate. The problem with CopperCube's DirectX9 renderer isn't how dated it looks, it's the performance issues. I have never experienced a game or rendering engine struggle to hit 60fps as much as CopperCube. Need to display more than 5 human models? Forget it. That's too many animated polygons per frame. Need realtime shadows? CopperCube has them, but I've never managed to create a map simple enough to use it. Get used to having zero shading beyond baked lighting, but the in-engine baked lighting tool is so glitchy I wouldn't use it either. Performance struggles in very unpredictable ways, too. Terrains seem to be the most poorly optimized part of the CopperCube workflow. Creating a terrain is a decent-enough experience, albeit with a few GLARING issues (why can I not define a vertical height for my brush?? This makes landscaping around buildings or retaining walls very difficult. Plus, only two textures can intersect in any given terrain area, otherwise the texture blending glitches out and creates a bunch of blocky artifacts). The real problem with terrains is their performance impact. A modest-sized map takes a minimum of 1.2 million polygons in my experience. That's just for the terrain. It seems un-sculpted / flat areas of the terrain still have the same amount of polygons as heavily turbulent areas. Using grass, which is required to cover up how polygonal the terrain looks and its horrible texture blending, requires even more polygons. In my ongoing projects, I have to budget 1.5 million polygons for the terrain, leaving maybe 500-800k polygons for everything else, lest the engine slow to a crawl. Regardless of how your scene is optimized, the engine will not hit 60fps (even on an RTX 3090) if the estimated polygons surpass 2.2 million. This is likely due in part to CopperCube being single-threaded, meaning all of your game logic AND non-GPU rendering operations fight for a single CPU core. In my testing, CopperCube scenes perform about 50% worse on Intel UHD 620 graphics as they do on my RTX 3090. Performance is tied to hardware, but not consistently or predictably. I've found certain GPU's or GPU drivers can have worse performance than others. It's extremely difficult to know with any certainty if your project will run well on the end-user's system without severely limiting project scope. [h3] The worst things about the rendering engine I forgot to mention above: [/h3] [list] [*] It cannot handle objects containing multiple animations (like your playermodel!) unless you purchase a very niche $60 program called "Ultimate Unwrap 3D Pro" that converts your FBX files into Blitz3D format. CopperCube docs say to use DirectX format (.X) which literally no software other than a 15 year old version of Blender supports. In my experience, animated .X models still don't render correctly, only Blitz3D does. Strangely, non-animated Blitz3D models import super broken if they have any transparent textures (like tree leaves). [*] OBJ files are the most reliable imports, but only if you triangulate it and export with dual-sided faces which almost doubles the amount of polygons the model uses. non-animated FBX models import better than OBJ on some models, worse on others, but FBX models often import with the wrong transform (so rotated sideways). This wouldn't be a problem if it weren't for the next point: [*] The lighting engine. All I can say is I've never hated someone else's code this much. Real-time shadows break gourad shading on animated models (especially if they're Blitz3D format lol). If you use baked shadows, expect the light map to not stretch over your model properly if your model uses ANY curves, and for the model to permanently be like that. Changing the lighting mode on a model often fails to clear its shadow map, and re-importing breaks it further. You have to manually delete the model entirely, save, then re-import when this happens. Also, you cannot render more than 8 light sources at once. This is extremely problematic for scenes depicting real-life places at night. [/list] [h3] Regarding the Engine & API: [/h3] Coppercube's API is so deeply limiting I’m genuinely unsure if it’s possible to make a successful game with it.The way Coppercube handles user input is truly appalling. If there’s one thing all CopperCube games have in common, it’s poor input handling. You cannot meaningfully assign tags to textures, so playing a specific footstep sound over different materials requires glitchy javascript workarounds tied to texture file names. Because of how bad CopperCube's built-in input handling is, I've had to program a lot of my game's logic in JavaScript engine extensions. CopperCube uses a VERY dated JavaScript engine that doesn't support basic or modern features. Plus, JavaScript operations can easily cause frame timing issues because everything is happening on one thread. Not to mention a lot of JavaScript API calls just don't work well. Raycasts are quite broken, and so are both physics engine options. I'm genuinely unsure how I'm supposed to make the camera not jitter violently as the player walks up or down non-terrain inclines. The player's hitbox often glitches inside of the polygon edges of scene models. According to the community, the fix is using very low gravity settings. That helps, but is floaty. There's no API to know "what node did this raycast hit," you have to use imprecise bounding boxes. [h3] Conclusion because I hit the character limit: [/h3] It’s such a shame, because coppercube is 70% there. It is so close to being an incredible option for people dabbling in game creation. The action / behavior system made complex game systems super simple to create. The level editor is so simple but so effective, and it imports static geometry from OBJ files better than Godot or Unreal. The texturing system is also VERY good. Being able to easily swap individual scene textures into models allowed me to recycle assets very subtly. Having all foliage follow a central wind system was a single button click. Coppercube would be my top recommendation if it wasn’t so broken and incomplete. This engine is so uniquely special I consider it worth using, provided you know what you're getting into.