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”.

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

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!

Level

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)

Sprites

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

Action

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.

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
  “values“
  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:

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…