Idea: Game construction set

[FFoulkes]

Hi,

just before I woke up today, I had a dream (really): I dreamt of a program to create games. For example, you define, if you want a static background (like in "Manic Miner"). Or a scrolling background (like in "Giana Sisters").
Then you define game objects. They have attributes, like what images you want to use for the animation. What speed they have. How they are moved (by themselves like the baddies in "Manic Miner") or by player input (Joystick). How they move (with predefined algorithms for jump movements).
You can define shots. For example, you select "This player object owns a gun. It's a futuristic laser gun. The player can shoot upwards. Shots have the style of cut laser beams. They move at speed xy." (for a "Space Invaders" game for example).
Game object can be solid (like platforms). Then other game objects bump into them when making contact (and an event is triggered, like for example an explosion and the loss of one life in the game). Or "transparent". Then other game objects move through them.
The "construction set" would have a database of sprite images to select from, of background images, of movement algorithms of sounds and music and so on.
You place your game objects with the mouse onto the screen, where they appear, when the game starts. The behaviour of the game is defined by the attributes of the game objects. Just like in object orientated programming. But you don't have to do the low-level programming yourself, the "construction set" just knows what you want, and lets you do your settings with the mouse and in menus.
In my dream there was such a game in 3D. I selected a bowl (from a huge database of different types of bowls, of different shapes, colours and textures) and placed it in the 3D world. First it was transparent, until I selected "solid" for it. Nice dream.

I believe, there's a program called "Unity", that does something like that. But it's proprietary. I haven't tried it yet.
I was also thinking more of a smaller construction program for 2D games, maybe Spectrum style. Still on a PC though, output code would be C++ with SDL2 or SFML, I guess. So no 48K assembler code output, I think, that wouldn't work (not enough memory).
Well, maybe it was just a dream. But it would be possible, I think. After all, behaviour of 2D game objects is in a way limited. There's not so much to it.

[equinox]

I know you're not suggesting a game maker for 8-bit machines here, but: "Repton Infinity" on the BBC Micro had a sort of object-oriented language called Reptol where you could program the objects and their behaviours by writing scripts. Pretty cool.

[Nitrowing]

Have you looked at Pico-8?
https://lexaloffle.itch.io/pico-8

[Ralf]

I was also thinking more of a smaller construction program for 2D games, maybe Spectrum style. Still on a PC though, output code would be C++

If you have a game creator tool, you don't need to output your work to C++ or any other language. Your output is the game itself.
Actually several similar tools already exist, some are more visual and some are more programming oriented.

I typed "game making creators" into Google and here is one of my first results:
https://blog.sagipl.com/game-development-tools/

Your dream came true over 20 years ago

[Alone Coder]

I'd like to create a sequel to AGD (also native), with maximum flexibility (any game loop, loading, saving etc).
I suppose that the language should look like this:

Main: mode=GO, t0=_time, dtime=1, MainLoop
MainLoop: MainBody, MainLoop
MainBody: @Mode[mode], WaitDTime
WaitDTime: DTime, dtime==0? WaitDTime
DTime: t=_time, dtime=(t-t0), t0=t, dtime>8? dtime=8

@Mode[GO]: ShowPreIntro, mode=GOMENU
@Mode[GOMENU]: PrMenu, mode=MENU
@Mode[MENU]: Menu, start? mode=STARTGAME : load? mode=GOLOADS
@Mode[STARTGAME]: ShowGameIntro, InitGame, mode=GOLVL
@Mode[GOLVL]: ShowLvlIntro, InitLvl, mode=GOGAME
@Mode[GOLOADS]: PrLoads, mode=LOADS
@Mode[LOADS]: Loads, ok? LoadSave, mode=GOGAME : esc? mode=GOMENU
@Mode[GOGAME]: ShowLvl, PrHUD, mode=GAME
@Mode[GAME]: Game, ?WinLvl? mode=NXTLVL : ?Die? mode=DIE
@Mode[DIE]: ShowDie, ?Lives? NxtLife, mode=GOGAME : mode=GAMEOVER
@Mode[GAMEOVER]: ShowGameOver, mode=GOMENU
@Mode[NXTLVL]: ShowLvlDone, ?Win? mode=WIN : NxtLvl, mode=GOLVL
@Mode[WIN]: ShowVictory, mode=GO

PrMenu: ... mnux=12, mnuy=64, mnuwid=16, mnuhgt=5.
PrLoads: ... mnux=12, mnuy=64, mnuwid=16, mnuhgt=8.
PrHUD: Cls, PrHUDGfx, InvalidateHUDData, PrHUDData
ShowPreIntro: .
ShowGameIntro: .
ShowLvlIntro: .
ShowLvl: .
ShowDie: .
ShowLives: .
ShowGameOver: .
ShowLvlDone: .
ShowVictory: .
LoadLvl: .
LoadSave: # ... InitLvl
SaveSave: .

InitGame: lvl=1, lives=5, InitLife
NxtLife: lives--, InitLife, ShowLives
InitLife: health=100
InitLvl: nxtlvl=0, LoadLvl # или без nxtlvl=0
?Lives: =lives>0
?WinLvl: =nxtlvl
?Win: =lvl==20
?Die: =health==0
NxtLvl: lvl++

Menu: MnuPrCur, key=WaitKey, MnuRmCur, MnuKeys
MnuKeys: CurMv, CheckEsc, key==K_ENT? MnuEnt
MnuEnt: MnuStart, MnuLoad, MnuHelp, MnuCredits, MnuQuit
MnuStart: mnuline==0? start=1 : start=0
MnuLoad: mnuline==1? load=1 : load=0
MnuHelp: mnuline==2? ShowHelp
MnuCredits: mnuline==3? ShowCredits
MnuQuit: mnuline==4? SureQuit? _Quit

Loads: LoadsPrCur, key=WaitKey, LoadsRmCur, LoadsKeys
LoadsKeys: CurMv, CheckEsc, key==K_ENT? ok=1 : ok=0

CheckEsc: key==K_ESC? esc=1 : esc=0

MnuRmCur: MnuPrCur # .type=MENUCUR, .x=50, .y=(mnuline<<3)+100
MnuPrCur: InvBox(mnux,mnuy+(mnuline<<4),mnuwid,16) # .type=MENUCUR, .x=50, .y=(mnuline<<3)+100
CurMv: key==K_UP? CurUp : key==K_DN? CurDn
CurUp: mnuline>0? mnuline--
CurDn: mnuline<(mnuhgt-1)? mnuline++

Game: dtime>0? GameLogic, dtime-- : GfxEngine, WaitDTime
GameLogic: MoveObjs, MoveHero, MoveShots, Collide
Collide: CollideWalls, CollideObjs, CollideShots # (могут менять health, nextlvl)

@Move[ALIEN]: SolidMove, AlienCheckDie, AlienAnim, AlienChg
@Move[ALIENSTAY]: AlienAnim, AlienStayThink
AlienCheckDie: Deadly(.y,.x)? AlienDie
AlienDie: .dx=-1, .dy=-10, .type=ALIENDEAD
AlienChg: TimeOut(50)? .type=ALIENSTAY, .gfx=0
AlienStayChg: TimeOut(150)? .type=ALIEN, .gfx=2
AlienAnim: AnimTimeOut(10)? .gfx=.gfx^1

TimeOut(t): .time++, .time>t? .time=1
AnimTimeOut(t): .animtime++, .animtime>t? .animtime=1
SolidMove: SolidMoveY, SolidMoveX
SolidMoveY: MoveY, Solid(.y,.x)? .y=.y&(0xf0<<3), .dy=0
MoveY: .y+=.dy, .dy+=GRAVITY
SolidMoveX: .x+=.dx, .dx<0? SolidMoveL : SolidMoveR
SolidMoveL: Solid(.y-(16<<3),.x)? .x=(.x+(15<<3))&(0xf0<<3)
SolidMoveR: Solid(.y-(16<<3),.x+(16<<3))? .x=.x&(0xf0<<3)
SOLID=0x80
DEADLY=0x40
# Solid(y,x): =tileflag[_GetTile(y,x)]&SOLID
# Deadly(y,x): =tileflag[_GetTile(y,x)]&DEADLY

# @Draw[ALIEN]: _DrawSpr(.y>>3,.x>>3,.gfx)
# @Draw[HERO]: _DrawSpr(.y>>3,.x>>3,.gfx)


# Game: _foreach(objs,@Move), _foreachcollided(objs,@Collide)
# GfxEngine: _UpdTiles, _foreachvisible(objs,@Draw), _SwapScr

However, I don't have contacts of any AGD users for propositions. I see, artists don't like to contact coders That's why there are many coder's games and many artist's games, and too few games made by full team.
So that's why AGD-like systems are needed (or changing something in the scene relations).

[FFoulkes]

Have you looked at Pico-8?
https://lexaloffle.itch.io/pico-8

Thanks, looks interesting!

[FFoulkes]

I typed "game making creators" into Google and here is one of my first results:
https://blog.sagipl.com/game-development-tools/
Your dream came true over 20 years ago

Could be, but I doubt it. Most people today don't think the way I do (and probably the other way round), that's why in most cases their programs aren't the way I want it.
For example, if it's a 2D editor, you should be able to create 100% clones of let's say "Jet Pac" and "Manic Miner" with it. And also go beyond that.
I would also demonstrate such clones in videos.
And then I'd go "Look, here's an editor, you just can create 'Jet Pac' and 'Manic Miner' with it, now isn't that cool?" ... And nobody today would be interested again, just like when I recreated the Katakis-starfield in Pygame for example without getting any reactions.

The video for the editor "Sploder" on the website doesn't look to bad. But be fair, would you want to play the game shown there? Well, maybe.
I also played "SuperTux". But somehow I still prefer "Giana Sisters" on the Amiga to it. Better look and feel. A good editor would have to get all these things right.

Well, I'm very far from realizing such an editor. Would be a huge project, not sure if I'll undertake it.

[rastersoft]

That sounds a lot like "La churrera"... https://www.mojontwins.com/juegos_mojonos/la-churrera/

[Joefish]

There have been game creators for the Spectrum but they always run into the same problems. There's only so much flexibility they can offer you before the number of menu options gets ridiculous and unmanageable. For example, if you simply have a 2D game designer and you want to be able to shoot, think of all the options: Is it a shoot'em-up where you can only shoot in one fixed direction (e.g. up or right); is it an overhead game where you can shoot in four or eight directions, depending on player movement? Do you want to lock direction while you hold fire? Or is it a platform game where shot direction is based on player movement, but only horizontally?

To avoid being too complex, you can either go for something that's more like a 'Game Editor'; a particular game type where you just edit the graphics and levels. Whether it's a shoot'em-up, or a platform game, or fixed-screen, or scrolling, is not an option. It is simply one of those things and only that thing. Then at least the options are manageable. But the gameplay of any game done with it is going to be very similar to any other.

Or you get into something where features can be scripted, then the designer can program behaviours into game objects. This gives much more flexibility in the types of games that can be created, but demands a lot more of the designer.

One of the big forgotten 'Game Designers' of old, that got a lot of interest, was sadly an April Fools joke from an April edition of 'Your Sinclair'. It was called Arcade Dream and the idea was it had game 'packs' which were basically gameplay engines, and you used a generic series of editors to design the graphics and levels that go with your chosen game engine. To implement it for real you would have to keep the game engines to simple arcade-like affairs without any complex game logic. It could be made to work, but it would really just end up producing a lot of samey games. It would have all the flexibility and all the limitations of having a Manic Miner editor, Jet Set Willy editor, and CRL's 3D Game Maker (has it actually been released yet? ) just bundled on one tape.

[Alone Coder]

The key feature of a game editor is its stop-change-continue ability. The language I proposed supports this. However, I still haven't decided some points, such as resource handlers, changing gfx engines etc.

[ZXDunny]

One of the reasons I wrote SpecBAS was specifically for remaking 8bit games. It's old-school Sinclair BASIC but has all the sprites, graphics and sound abilities you could ever want.

[FFoulkes]

There have been game creators for the Spectrum but they always run into the same problems. There's only so much flexibility they can offer you before the number of menu options gets ridiculous and unmanageable.

Yeah, could be. Reminds me of music programs (socalled DAWs). To create a pop-song or even a classical symphony, that then can be exported as ".wav", also a lot of options have to be set. And it takes quite some time to learn how to use these programs. Nevertheless it can be done (example).
These programs also use plugins (for the instruments and effects). Maybe such a game editor could use a plugin concept too.
Anyway, yeah, it would be complex, but today we also have a lot of computing power and almost unlimited memory, so things become possible, that weren't possible in the past.

[highrise]

Having worked on AGDx, the fork of AGD for a number of years now I can tell you it's a very, very large amount of work. Unlike writing a single game, you have to try and anticipate everything that people will try to do, and at the same time you have to remember that the people who use it don't usually have a great technical understanding of the Spectrum itself or assembly language because if they did, they wouldn't need your help. You then have to be prepared to offer support to those people as you develop the tools. I personally started on AGD and it was a great way to learn, but I wouldn't use it now because even though I know it inside out, it just can't do the things I would want and it always makes more sense to use custom code.

I am still dedicated to helping people get into the scene though, and I'm working on AGDxplus which is a more modular system. The coder can specify which elements of the engine that they want, and a custom engine is then compiled. This helps, but even then you can never expect to get the same results as you would when coding in pure assembly. Usually you end up using a lot more memory - so you end up with a smaller game, or you end up using 128k for what you could probably do in 48k with direct coding.

The Spectrum is an incredibly basic device with no hardware dedicated to gaming whatsoever. Every game has slightly different requirements because it all has to be done in software. It's a bit like making a suit - you can build 'one size fits all' tools to help, but a suit made like that will feel generic. If you really want the best quality, you have to do something bespoke.

In all honesty, having an idea for a game on a machine like this really is the easy part - making it a reality takes a lot more time, patience and dedication than most people have to spare in their grown up lives. For every project I've finished, there are a dozen that lie dormant. So it makes sense that people would want something to save that level of effort, and in the end, if you want to make a fun little game that people will enjoy for a few days, you can use a pre-written engine. You can have a game like that up and running in about a month and you can feel proud of it. But if you want to do more, you kind of have to bite the bullet and learn to work at the coalface, so to speak.

[Alone Coder]

Can you please describe your current system?

Usually you end up using a lot more memory - so you end up with a smaller game, or you end up using 128k for what you could probably do in 48k with direct coding.

I expect that the game script will be compiled for the game release, and the editor functions will be removed from the memory. Anyway, all of us have 256K or more at our Speccy (the stats say that there were more 256K is use than 128K already by 1999: http://www.zxpress.ru/article.php?id=7181 http://www.zxpress.ru/article.php?id=11366 http://www.zxpress.ru/article.php?id=4417 http://www.zxpress.ru/article.php?id=7322 http://www.zxpress.ru/article.php?id=9429), and this amount of memory is still rarely used in games. Maybe because games this big require more comfortable development system than just ALASM.

[highrise]

well, it's not my system, I'm building on top of the existing engine that is AGD by Jonathan Cauldwell.

However, you are correct that the editor code is paged into contended memory depending on which part of the game you are editing, and this can be replaced by user specific code later on. The main memory issue is that sprite systems that are very easy for 'noobs' to use generally require more frames and fixed sizes. This uses up a lot of memory due to shifting. If you code in pure assembly, there are many ways to manage memory and use coding tricks on a machine that is not in any way designed for what you are doing, but almost none of these make sense to people without technical expertise.

I think there is a huge difference between game coders in Russia / former USSR and those in the UK, Spain and others. Most people who code games on the Spectrum in Western Europe are what you might call 'casual' coders. I don't mean that as an insult, it's just that usually they have had a dream of making a game, usually on the original 48k Spectrum, since they were kids, and they want to realise that dream by making a fairly simple game. I think game making engines like AGD serve their interests quite well because they don't have the time or knowledge to do more than that. Some, like me, may move on to coding in assembly directly, and that brings you more into line with how people in Eastern Europe and former Soviet coders, who have a much longer, more technical history with the machine.

Incidentally, I actually live in the former Soviet Union myself, so Приветствую from Kazakhstan

[megaribi]

There was one quite powerful 2D games designed called HURG, intended to write games without programming. I had not manuals back then so I did not write games, but here is the manual.

https://worldofspectrum.net/pub/sinclai ... U.R.G..txt

As far as I know, the game has no sound and depends on HURG in memory. But it may be patched (for example with program that snapshots memory and then deletes the editor parts of HURG, leaving your game only) and music added in interrupt mode 2.

[Alone Coder]

Are there examples of games made in HURG?

[megaribi]

In Perfect TZX version of H.U.R.G. there are two platform games Manic koala, Egg pack and Pacman maye like game MS Hortens.

[Turtle_Quality]

According to this site

https://spectrumcomputing.co.uk/entry/2 ... ctrum/HURG

three example games are included, but games made with Hurg cannot be run standalone. Which was pretty crippling those days. With snapshots from emulators you can get past that. More info about what it can do here

https://www.crashonline.org.uk/03/hobbit.htm

[SteveSmith]

I know you mentioned Unity, but what you originally described sounds exactly like Godot. It exports to PC, Linux, Mac etc... If someone could write an Export to Spectrum module, bob's your uncle.

[Ralf]

Speaking of HURG, somehow I remembered and found an old conversation on WOS

https://worldofspectrum.org/forums/discussion/36108/

ghbearman
October 2011 edited October 2011
I have a couple of HURG made games, I haven't been able to load them yet.

I guess nothing ever came of it and we didn't see these games.
Is anybody still in contact with Guy?