Worklog for mindfulvector - Infinity Indie Sandbox

👉 BlitzCoder will be building a new platform and other plans to preserve and continue the Blitz legacy.

To be able to achieve this goal, we need your support by becoming a Patreon Paid Member 👈


Tweet worklogs

A sandbox game inspired by the toys-to-life genre, implemented in Blitz3D!

Creating my first worklog here for my new Blitz3D project. It's been a loooong time since I wrote a Blitz worklog (on the old Blitz Research website) so it's really neat to be working with Blitz3D now with full access to the compiler's source code.

Great thanks to Mark Sibly for making this excellent tool (and series of tools, BlitzMax in particular has a special place in my heart and I actually wrote a bunch of code in it for a major airline once!). Also great appreciation and thanks to Blitzcoder for creating and maintaining this excellent site and keeping the dream alive. I've been lurking for a long time and decided to start posting finally. :)

The actual worklog content follows! ;)

So far I've focused on a few things:

  • Re-learning the language and command set
  • Cobbling together a set of userlibs and tests for each one to get the pieces I need in order
  • Initial resource collection, mostly from Open Game Art
  • Planning the scripting, game data initialization, and save file systems -- these are the cornerstone of any kind of expandable sandbox game and any moddable game in general so it's important that I get this right

Userlibs currently planned to be used and with functional tests (just examples really, not unit tests -- which will come later) written:

  • BlitzUI
    • I also evaluated DevilGUI which I really liked as well. BlitzUI's schemes seem a bit more minimalistic visually, so I am probably going to go with this one for the dev tools/console layer of the game.
    • I am also planning to evaluate pseudo2D / "Pseudo 2D in 3D - for Blitz3D"
  • BriskVM
    • I practially had to reverse engineer how this actually works but finally got working scripts and enough knowledge that I can write an Invoker from scratch. As always it turned out that it really is not as hard as it seemed at first. Without a few key pieces of information available anymore it just took a lot longer than it "should have" (a phrase I am trying to eliminate from my vocabulary).
    • I plan to post more details on this and probably will write and share an invoker generator.
  • Sqlite3 for save file storage
  • Newton for physics

I'm still debating if I want to try to implement networking -- sandbox games of this kind can really be a lot more fun with networking but since I have mostly played the ones I enjoy solo I am not quite sure if I will be able to capture that feature correctly. Still thinking about it.

Planning to post videos or at least images of my concept tests, as well as of the game itself as it progresses from the infant state that it is currently in.

Blitz3D rocks!

Working on controller support today:

Was previously working on the Build menu shown here at the bottom of the screen.

The preview images for buildable objects are taken automatically by a "mode" that I've implemented which loops over all loaded objects as defined by scripts in game files, so this list is fully expandable. The images are then loaded on the next execution of the game, and drawn into the Build menu.

Next going to be working on actually allowing those objects to be built and saved to a data file. A good portion of that work is already done as the objects you do see on the screen are created using the same functions that will be used when reading a data file from disk. Any object defined in the scripts can be loaded this way already, so it's the build interactions and the save/load systems themselves that I need to work on only.

Here is a small stress test using 1,200 small terrain cubes (same size as shown above) created using the same functions:


The frame rate does drop to around 30 when you have this many small objects, but this seems fairly reasonable to me for not really having tried to optimize at all. Normally a structure that large would likely consist of far fewer, larger objects which would perform much more smoothly.

State of the engine and game art generally:

  • Experimental objects imported and displayed with textures, which is helping me define the API needed to create new objects via scripts.
  • Initial scripting support -- can execute a script and call Blitz3D functions from it using a hand-written invoker.
  • UI integrated into game loop and looks like it will work well for internal dev tooling.
  • Generating textures from Texture Maker 2.3 online examples so far, which look pretty great and match the art direction I am going for really well.
  • Importing only the albino texture from Texture Maker's output, probably all I really need but I do want to explore options around PBR materials -- if they are actually possible in B3D, which I don't know yet.
  • Learning an old version of Blender (2.79) which still has support for 3ds model export. The cube models in this screenshot are cubes with beveled edges, which certainly felt like quite an accomplishment for someone who finds Blender absolutely baffling! Of course I've already moved on to (slightly) more complex models which I'll feature soon (don't expect anything fancy, it's just a better terrain cube haha).


In this game, when you defeat enemies and destroy some objects you are awarded "pixels" which can then be used to unlock objects for your own sandboxes, buy upgrades for your characters, etc.

Here's an early test I've done recently showing how the pixels might look and how they can be collected.

First, I spawn a random cuboid object, then I destroy it. It turns into a matrix of "pixel" objects that drop to the floor, then are vacuumed up by the camera. (Watch video)

The actual game is planned to be third-person so this is an incomplete test. In the final game the vacuum effect is planned to be point-to-point within the camera's field of view, instead of point-to-camera.