10th of January 2023 – building games?

You know – it is not like I don’t have any open projects… and I NEED to find something new… unfinshed tasks remain – like:

  • I started updating the PiTrex baremetal implementation a couple of weeks ago
  • I wanted to finish the port of DoD
  • I started that Choplifter thing
  • I have some soldering to do – for the transformer studies
  • I have still the RASPI 4 here to build a small Vectrex (after all that is what I updated the LibRetro for)
  • I should build a “complete” Vide version for distribution… after all – I changed/added quite a few things lately
  • … and probably many more things – and these are only “Vectrex-tasks” your would not believe that I also have a life apart from Vectrex

But what am I doing… fiddling around with stuff nobody will ever use… and I sooner or later will come to a point where I must accept that I will not be able to finish what I started – or that I abandon it, since it will never satisfy to my needs.

I have always been intrigued by automation of boring game building tasks. Thus in Vide you can already find many parts where it will support you by generating source code for various tasks (sound/sample/vectorlists/game loops …)

For the fun of it I have taken that one step further. I have not named the vide part yet – so for now I will just call it “game builder”.

a testrun – max cycles … 22000 (analog input)

The ultimate goal is to build complete games without programming.

Yea. I know.

There will be some tiny little restrictions when it comes to the final results – and I will probably add “entry points” where one might add additional code (opponent AI’s will be hard to build by just clicking some buttons).

A major problem with things like these is a GUI that the user actually likes to use! I probably will not be able to create that.
It will be tables, comboboxes, checkboxes and file selectors. It will be buggy – since testing all scenarios is nearly impossible. I can only hope that I’ll come up with some sort good feedback, so the user may have a chance to circumvent the most obvious bugs… but enough said about that.

What I noticed the last day while working with these stuff… there is ALWAYS more.

Where should I start…

Semi – technical structure of a builder game


The game contains everything that makes a game. Code, Vectorlists, sounds etc.
It has not many directly configurable entities – but it contains everything else and in the gui it has the allmighty “Generate game” button!


Each game consists of levels. Without levels – no game.
Every in game “screen” is a level. So the title screen – is a level. Credits shown – is a level. And certainly also in the classical sense every level of the game – is a level.

Game Objects

Different entities that are “glued” together in the correct way – that make a game.
As of now implemented are only:

  • Sprite
  • Background Scene
  • global variable (only partly implemented)

Further planned are:

  • Foreground Scene/Vectorlist
  • music (Arkos Track I/II, YM)
2 players, with a blocking object in the middle


Are game objects that can have a representation on screen, apart from Background lists, these are the only things (as of now) that can make it onto the screen.

Each sprite must have at least one “Action”. The sprite itself only serves as a binding piece for different actions – as of now a sprite has only 3 items:

  • unique ID and a name
  • a default action
  • a list of actions


Actions in the classical sense are things a sprite can do, like:

  • go up
  • go down
  • climb
  • jump

Each action can have a different grafical representation on screen. The only grafic that is used for sprites are “animations” that were built using Vide. But the animation can also consist of a single vectorlist.

New invaders are spawned with a timer “cause”…

Actions are the elements where the ACTION is. Key elements of actions are:

  • Behaviour
    This defines majorly what can be done, some already implemented:
    – player 1 controlled (joystick, – buttons… always joystick 1)
    – player 2 controlled (joystick, – buttons… always joystick 2)
    – parent direction (with this one can define “shots” – these sprites move in the direction of the parent when spawned)
    – patrol (define a path of coordinates)
    – text (this is how you print text – with a text sprite!)
    – trigger only
  • Trigger
    Each Action can have an arbitrary count of triggers.
    A trigger consists itself of following parts:
    a cause“,
    – joystick, button
    – position
    – sprite collision
    – timer
    – many more (over twenty different causes at the moment)
    “a target”
    What happens when the cause has actually happened:
    – action change (e.g. from walk up -> walk down)
    – block movement (e.g. collision with wall)
    – next level
    – change variable
    – play sfx
    – remove (sprite is dead)
    – set position (build teleporters uppon sprite collision?)
    – spawn sprite
    – speed change
    – and others
    In order to move things, and adjust the game to different “causes” flexible input is necessary.
    E.g the position information for a “target” is configured with values that support:
    – absolut values
    – delta values (in regard to already set values)
    – usage of variable
    – random numbers (in a range)

The ball in the arkanoid style test above is the most complex “single” action that I have configured yet:

configuration of the “ball”
Drawn in scale 8!

I have tried optimizing the heck out of things. But I am far from finished. A major point I still have to do is a rewrite of smartlists. For general usage they should be a bit cleaner and more stable I think.

The complete “engine” runs with two basic factors:

  • all positionings are done with scale: $80
  • all drawings (yes ALL!) are done with a scale of $08

It should be possible to keep these settings for all things – once I update the smartlists as a whole it should get prettier still.

For today I’ll finish this entry… but I’ll probably be back with a more technical view of things.

Especially an efficient and “general” collision detection is what kept me awake the last days. I hope my current implementation is stable…

9 thoughts on “10th of January 2023 – building games?

  1. Phillip Eaton

    Building a game builder, very ambitious!

    I’ve never written a full game before, but having spent too many months reverse engineering VIC-20 Jetpac, I can see how a builder would work. Jetpac is basically a list of 10-12 objects, each roughly translating to a screen sprite and the main program is a continually working through each of the objects, updating their parameters and drawing them on the screen. The Jetman object is special, he’s updated on a timer interrupt, which is also when the controls are read. New objects are spawned at the end of main loop. It’s complicated by the VIC having no sprites and a chunky tile-based colour mapping.

    On the one hand, I can see how this program structure would translate well to a building system. On the other hand, everything in the Jetpac code is bespoke optimised code, so I can see that a builder system might be a compromise on performance, unless it can be optimised at PC compile time.

    But game builder systems do already exist and are used, so I guess it’s all doable – I look forward to seeing the results!

  2. Ben Razmataz

    It’s brilliant!!
    As your others modules in Vide, can we be able to export parts made with the builder into regular assembly source into Vide?
    Let me know if you want tester, I will be happy to build something and include it as a bonus game into my next game!!

    1. Malban Post author

      It will be quite a while before I make this available – there are quite a lot of things to implement and fix.
      When my own (bug and missing feature) reports start to cease I’ll remember your offer. Thx!

  3. Graham Toal

    When I had a try at something slightly similar a couple of years ago ( http://gtoal.com/vectrex/SpriteLib/spritelib.h.html ), the problem I came up against was the tradeoff between simplicity and how much RAM the sprites needed – I ended up with too many sprite types, so that each type could minimise the amount of RAM it needed… the tradeoff was that you keep it simple with one all-encompassing sprite type which keeps lots of parameters in ram, or you minimise the ram usage but have lots of different sprite types, each of which keeps only a minimum number of required parameters in ram. I went for the latter but it made for a lot of redundancy and extra coding to handle all these different variations of a sprite.

    1. Graham Toal

      PS One implementation detail I got badly wrong in my sprite library was that I expected to make a sprite disappear by unpost()ing it and make it reappear by post()ing it again. However unposting was too high-level and more like actually deleting it, and posting was more like recreating it. What I really wanted was a ‘hide()’ and ‘show()’ lightweight call to make something temporarily invisible and restore visibility later – what I actually implemented was a cheap & nasty temporary setting of the intensity to 0 – which rather stupidly meant that the invisible object was actually drawn with 0-intensity vectors, which was an entirely unneeded overhead. If I ever resurrect this code I’ll add those more lightweight calls to temporarily ignore an object and hide it without a runtime overhead. But other than that, which was from a lack of foresight in how the library would be used, the interface seemed fairly sound. I didn’t acually implement *all* the types and calls that I envisaged but did enough to confirm it was a plausible proof of concept.

  4. Brian

    Wow – looking forward to this!

    I recently started writing a column on retro indie games and tools to develop them for Old School Gamer… This would definitely fit in when the time is right!

  5. nexus6

    Wow, i’m really looking forward to this. But even as non programmer I can imagine that it won’t be easy to create something like this, because there are so many possibilities and different situations in games. When the maker is finished, I’ll definitely try it.

  6. John Cabrer

    I have been experimenting with ChatGPT 4 to generate code for various things at work. Since Python is so ubiquitous, ChatGPT usually gets it right on the first or second try. Having just received a Pitrex cart, I find myself dreaming about a cart based on the RPI Pico which could be programmed using micro python, and having ChatGPT assist as a plug in to VIDE would just rock

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.