New Game Creator

[pgregory]

Another weekly update, this time with A-N-I-M-A-T-I-O-N!

[ImissSirClive]

This is just incredibly exciting!

I'd love to be in on the alpha no matter what the price is!

[pgregory]

This is just incredibly exciting!

I'd love to be in on the alpha no matter what the price is!

Thanks, drop me a message on my web page (https://www.indigobeetle.co.uk), or on Ko-Fi and I'll make a note of your interest.

[flopping]

Another weekly update, this time with A-N-I-M-A-T-I-O-N!

Thank you, this video helps me a lot. I was in a crisis of solutions.

[Cheez26]

I have dropped you a message. Thanks for being awesome, @pgregory

[uglifruit]

This looks fascinating. Great to have new tools like this available.

[redballoon]

@pgregory This is looking soooooooo good!
A wee suggestion, if that’s ok, regarding the sprite creation and animation? From an artist/animator point of view, and if it’s not possible, it’s not big deal - is there the possibility that when you’re creating a sprite, especially if it’ll be a frame of animation, that you can toggle onion skinning so you can see a previous frame (sprite) of your choice to help with animating?

Also just another thought watching the video again, and I’m really not sure if this is possible especially with showing multiple animations using the same sprites - to help animating, could you click on the animation frame and have the ability to edit the sprite in that frame in real time?

[pgregory]

@pgregory This is looking soooooooo good!
A wee suggestion, if that’s ok, regarding the sprite creation and animation? From an artist/animator point of view, and if it’s not possible, it’s not big deal - is there the possibility that when you’re creating a sprite, especially if it’ll be a frame of animation, that you can toggle onion skinning so you can see a previous frame (sprite) of your choice to help with animating?

I've already had a similar request, it's on the list of planned features.

Also just another thought watching the video again, and I’m really not sure if this is possible especially with showing multiple animations using the same sprites - to help animating, could you click on the animation frame and have the ability to edit the sprite in that frame in real time?

I'd rather not do this, otherwise the features bleed all over the place and each editor becomes overly complex and confusing. I'd rather address the issue you're trying to solve in the sprite editor somehow.

[redballoon]

I'd rather not do this, otherwise the features bleed all over the place and each editor becomes overly complex and confusing. I'd rather address the issue you're trying to solve in the sprite editor somehow.

Totally understandable, it was just more of a thought and the onion skinning will work just as well.

[Lee Bee]

Hi Paul. Some great progress made with last week's animation video! My first chance to respond…

I have a few suggestions, but as always, please take these with a pinch of salt. It's just ideas off the top of my head, in case anything appeals to you. Though I do consider #4 and #5 quite important and would really like to see those implemented if possible…

1. Animation names
Instead of animations being identified by numbers, I'd prefer them to have names. These would be written across the top instead of on the left. Names would be more helpful when you're editing code and go to insert an animation but all you can see is a drop-down list of meaningless numbers! Names would make the selection far easier and quicker.

2. Current frame highlight
I love the automatic preview showing the animation playing (on the left of each animation panel). Could the current frame being played have maybe a white line under it, to show where the "playhead" currently is? Example of what I mean:



3. Manual scrub through frames
Another animation feature which would be nice: Make it so that if you roll the cursor over any frame, the animation preview on the left FREEZES on this frame until you move the cursor away. This would mean that you could inspect all the frames in your animation, at any speed you like, backwards and forwards, just by moving the mouse left and right across the frames. This would feel like the digital equivalent of flicking through hand-drawn animation frames at your own pace. Note that this would require the rollover area of the frames to be edge-to-edge, with no gaps. The above suggestion of a white underline would also be quite important here to communicate what's happening. (Hope this all makes sense, if it doesn't ask me and I'll re-explain.)

4. Important: Animation preview and frame drawing should not be in 2 separate places
Currently, the place where you can view animations, and draw your animation frames are in two completely separate places (Objects tab and Sprites tab). This adds an unnecessary barrier to creating animation, forcing you to go back and forth between the two tabs just to draw frames and see them animating. In other words, you can't edit animation frames and see a live preview of the changes while you're drawing.

Solution: I would demote the Sprites tab from being a "main tab" and move it down to be part of the Objects tab. So in the Objects tab you would now have two tabs on the left ("Sprites" and "Objects") and two tabs on the right ("Animation" and "Logic"). This way, the user can choose which two windows he wants to use together, meaning he can have Sprites on the left and Animation on the right at the same time. As for the sprites sheet selector, that could appear immediately below the sprite editor instead.

5. Important: Flipping should always be done in code
In your example game, you've set up separate sprites of Manic Miner walking both left and right, as well as setting up separate animations of him walking left and walking right. I would prefer not to work this way. I'd rather ONLY set up one lot of sprites facing ONE way, and one lot of animations facing ONE way, then you have ALL flipping done in the code (perhaps with a simple command or button to insert a flipped/rotated version).

To me, this would seem like the most efficient way of working, as it keeps the list of sprites and animations as short and simple as possible making it easier to manage and to find things. For a game where the character can move in 4 directions, this would reduce the list of sprites AND list of animations to QUARTER the length. This means you only need to focus on how the sprites/animation look ONE way without having to be continually updating and copying the changes to all the sprites and animations for all 4 directions. And if you make a small change to one sprite or one animation, you don't need to worry about the other 3 directions, because the flipping/rotation is done in the code, making the change automatic and instant. This saves developers time doing an extremely common task (making flipped versions of sprites and animations). Instead, it's just as simple as ticking a "flip x" tickbox.

The only very minor down-side to this is that inexperienced users may assume the flipping/rotating is being done on the fly and saves memory, not realising that all the flipped/rotated sprites need to be pre-drawn and so will eat up memory.

6. Instant game preview
I was also thinking (and I'm sure this won't be possible but) it's pity you can't have an instant preview of the game instead of having to wait for it to generate each time. I love the idea of having the game window always there and the game always running, with code changes updating immediately. That is just a dream, I'm sure, but I have to mention it!

7. Template/sample/learning games
Finally, your logic/code editor looks extremely user-friendly, nevertheless, as a "dummy" who is scared of code, I would still find it very daunting to use the first time and wouldn't have a clue where to start. It would be great if the program came with a built-in sample game for learning, or a few basic templates, or just helpful documentation. It would be nice to have something like "10 steps" to building a very basic platform game.

Lee

[AndyC]

The only (very minor) down-side to this is that inexperienced users may think the flipping/rotating is being done on the fly by the software, not realising that all the flipped/rotated sprites need to be pre-drawn and so will eat up memory.

Well the other obvious downside is that your left/right frames have to be exact mirrors which isn't always ideal - for example a.character holding a gun in their right hand will switch to holding it in there left hand when they turn around. That's sometimes an acceptable compromise when the hardware is doing the flipping (or it's done on the fly) but a bit limiting when you're going to store all the frames anyway.

[Lee Bee]

Well the other obvious downside is that your left/right frames have to be exact mirrors which isn't always ideal

You misunderstand. I'm not saying the user can't create custom left/right sprites, I'm only saying that the easy convenience of flipping in the code should be available as an option, because 99% of the time, most users will probably only require an exact flip and I would imagine most users will prefer to work that way.

[pgregory]

1. Animation names
Instead of animations being identified by numbers, I'd prefer them to have names. These would be written across the top instead of on the left. Names would be more helpful when you're editing code and go to insert an animation but all you can see is a drop-down list of meaningless numbers! Names would make the selection far easier and quicker.

This makes sense, I'll look into this, should be relatively straightforward.

2. Current frame highlight
I love the automatic preview showing the animation playing (on the left of each animation panel). Could the current frame being played have maybe a white line under it, to show where the "playhead" currently is? Example of what I mean:

Also good, I'll add this.

3. Manual scrub through frames
Another animation feature which would be nice: Make it so that if you roll the cursor over any frame, the animation preview on the left FREEZES on this frame until you move the cursor away. This would mean that you could inspect all the frames in your animation, at any speed you like, backwards and forwards, just by moving the mouse left and right across the frames...

Again, good idea, I'll add it to the list.

4. Important: Animation preview and frame drawing should not be in 2 separate places
Currently, the place where you can view animations, and draw your animation frames are in two completely separate places (Objects tab and Sprites tab). This adds an unnecessary barrier to creating animation, forcing you to go back and forth between the two tabs just to draw frames and see them animating. In other words, you can't edit animation frames and see a live preview of the changes while you're drawing.

Solution: I would demote the Sprites tab from being a "main tab" and move it down to be part of the Objects tab. So in the Objects tab you would now have two tabs on the left ("Sprites" and "Objects") and two tabs on the right ("Animation" and "Logic"). This way, the user can choose which two windows he wants to use together, meaning he can have Sprites on the left and Animation on the right at the same time. As for the sprites sheet selector, that could appear immediately below the sprite editor instead.

This has been suggested elsewhere in this thread. I'm not keen on this, as it makes the individual tabs overly complicated. At the moment, the sprite tab is purely for editing sprite bitmaps, the object tab is for objects animations and logic. Moving the sprite editor into the object editor just blurs the lines, and given that the sprite editor is going to become far more capable over time, overly complicates the interface.

I will be adding functionality to the sprite editor to help with animation, an onion-skinning feature of some sort to help with visualising how frames relate to one another.

5. Important: Flipping should always be done in code
In your example game, you've set up separate sprites of Manic Miner walking both left and right, as well as setting up separate animations of him walking left and walking right. I would prefer not to work this way. I'd rather ONLY set up one lot of sprites facing ONE way, and one lot of animations facing ONE way, then you have ALL flipping done in the code (perhaps with a simple command or button to insert a flipped/rotated version).

To me, this would seem like the most efficient way of working, as it keeps the list of sprites and animations as short and simple as possible making it easier to manage and to find things. For a game where the character can move in 4 directions, this would reduce the list of sprites AND list of animations to QUARTER the length. This means you only need to focus on how the sprites/animation look ONE way without having to be continually updating and copying the changes to all the sprites and animations for all 4 directions. And if you make a small change to one sprite or one animation, you don't need to worry about the other 3 directions, because the flipping/rotation is done in the code, making the change automatic and instant. This saves developers time doing an extremely common task (making flipped versions of sprites and animations). Instead, it's just as simple as ticking a "flip x" tickbox.

The only very minor down-side to this is that inexperienced users may assume the flipping/rotating is being done on the fly and saves memory, not realising that all the flipped/rotated sprites need to be pre-drawn and so will eat up memory.

I also don't agree with this, it unduly hides what is actually happening. Having sprites flipped on export means that what gets exported isn't a direct correlation of what has been created. I will have tools in the sprite editor to make it really easy to create flipped sprites, but I want the user to be fully aware of what is exported, given that it's so critical to memory usage.

6. Instant game preview
I was also thinking (and I'm sure this won't be possible but) it's pity you can't have an instant preview of the game instead of having to wait for it to generate each time. I love the idea of having the game window always there and the game always running, with code changes updating immediately. That is just a dream, I'm sure, but I have to mention it!

This is already on my list, and probably the next big thing to tackle.

7. Template/sample/learning games
Finally, your logic/code editor looks extremely user-friendly, nevertheless, as a "dummy" who is scared of code, I would still find it very daunting to use the first time and wouldn't have a clue where to start. It would be great if the program came with a built-in sample game for learning, or a few basic templates, or just helpful documentation. It would be nice to have something like "10 steps" to building a very basic platform game.

The logic editor is going to have a feature that allows you to "group" nodes into a subgraph and the "close" it, so in the main graph it is represented by a single node. The plan is to have a library of these packaged node groups that the user can just drop into place to get things like basic platformer control, overhead 8-way control, enemy patterns, etc. This way the novice can just use them as black boxes and get started quickly, the more advanced user can open the black boxes up and see how they work and customise them. The other advantage is that they serve to keep the logic graphs less cluttered and easier to follow.


Cheers again for your feedback, keep it coming.


Paul

[Lee Bee]

Thanks so much for listening, considering my ideas, and taking time to respond!

[Lee Bee]

Paul, I've just had a random idea, and a very radical one which would vastly change the nature of your project and require a nightmarish amount of work, so I'm sure you would reject this. But I felt I should just throw it out there, just as something to consider if you haven't already… (This is so off-topic that I'm putting it in spoilers. No reply is needed because I accept this is kind of stupid…

Spoiler

So, I think your game editor is really coming together into something quite wonderful. It occurred to me that from the user point of view - the GUI itself isn't too rooted in Spectrum terminology, so that you can use it to make games without the requirement to know too much about the Spectrum's technicalities.

In fact - when you make a game with it, the resulting game could almost be going onto any system. This got me thinking (and this is just a wild possibility): Could the software potentially be expanded one day to be "multi-platform", so that you could create a game in it, and export this to, say, the Spectrum, the CPC, and maybe more?

I'm aware that this would be a radical departure that would go far beyond the project's current scope.

But basically, your program lets you build a game using a fairly universal system of graphics and logic. There are so many other 8-bit communities and platforms out there (and beyond) that would probably welcome these basic building blocks of a game, and would love to take them and use them for a conversion on their own platform. Your program could be beloved not just by this community but by several!

Practically, this radical expansion of the project would probably involve something like selecting a "platform" when you make a new project, and the ability to "Add platform", which might bring up tabs in the graphics windows where you can switch between, say, Spectrum graphics and Atari ST graphics, or whatever.

OK, that was my crazy thought. Thanks for wasting your time by reading it! Yes, I know, I'm talking silly, here. But it's good to throw silly ideas around because, who knows, maybe 1 in 100 idiotic ideas might just strike gold! LOL

[pgregory]

Paul, I've just had a random idea, and a very radical one which would vastly change the nature of your project and require a nightmarish amount of work, so I'm sure you would reject this. But I felt I should just throw it out there, just as something to consider if you haven't already… (This is so off-topic that I'm putting it in spoilers. No reply is needed because I accept this is kind of stupid…

This has always been the plan.

All the "system specific" editor parts, such as sprite/tile editor, etc. are pluggable. The format is designed to be largely agnostic to the capabilities of the system, well reasonably agnostic, so it can easily support content that is not tied to the Spectrum's limitations.

At the very least, Spectrum Next has always been a consideration, beyond that, I'd have to explore each platform in turn, as it would be a lot of work to add platform support, and this would definitely need to be financially supported in some way.

[Lee Bee]

Wow that's fascinating! Someday I would like to make a few games, and back of my mind, I was thinking I'd like to offer them on 1 other system that has fuller colour (maybe Atari ST, Amiga, or Next).

[pgregory]

Short teaser update video of some stuff I'm working on...

[oO cozy Oo]

Totally amazing,you don't realise what unbelievable project you have created! Hope you keep updating this tool for the community to use ,very well done Sir!!!

[dfzx]

I might have missed it in the discussion, but is the end-game here a tool which allows complete design and implementation of a Spectrum game?

The option appears to be to create hook points in the generated C code, set up to allow re-modification of the generated code using the tool while continuing to support the integrated custom code additions.

Or maybe you have something else in mind?

[pgregory]

I might have missed it in the discussion, but is the end-game here a tool which allows complete design and implementation of a Spectrum game?

The option appears to be to create hook points in the generated C code, set up to allow re-modification of the generated code using the tool while continuing to support the integrated custom code additions.

Or maybe you have something else in mind?

The tool will create a complete game without the need to touch the C code. The C code is generated by the tool and compiled to a .TAP file to run on the Spectrum or an emulator.

The target audience is people who want to make games but not learn programming.

[pgregory]

Video Update 13:

In this video update, I go into more details about the new features hinted at in teaser earlier this week.

[ImissSirClive]

This is just mind blowing. I cannot wait to tinker with it and make my first ever Spectrum game! I don't care how much it is, I'm buying it day 1!

[dfzx]

Which sprite library in z88dk are you using? I was trying to see from the build screen, but the video was too fast to read.

It looked like zsdcc as the compiler, and I'm guessing classic lib with the basic sprite functions? i.e. not SP1?

[pgregory]

Which sprite library in z88dk are you using? I was trying to see from the build screen, but the video was too fast to read.

It looked like zsdcc as the compiler, and I'm guessing classic lib with the basic sprite functions? i.e. not SP1?

SDCC, correct, and new lib with SP1.