MakeCode Arcade feature ideas

Arcade
#1

Intro

This is a list/mindmap/brainstorm I’ve been compiling recently, of all the additions I think would be awesome to have in MakeCode Arcade. I recently bought a PyGamer and am trying my hand at game development. It’s really fun so far, and I’m having lots of fun! These are some notes that I made over the course of learning this tool, just a few things I think would be great to see implemented. It’s amazing how much MakeCode has matured over the course of it’s (near-ish 2 year, if my calculations are correct) lifespan, and I look forward to seeing where things go next!!

Disclaimer: Let it be known this is not a feature request, expectation, or anything else. It’s simply a brainstorm of all the features and additions I think makecode would strongly benefit from. This is an opinion piece, if you don’t agree, that’s totally ok! If you have something to add, please do. I would love to hear what you all think, and if there is anything that any of you would love to see added! Once again, this is not a plea to the makecode team, y’all are doing awesome work, and you’re professionals with experience, and therefore know far more than I. I’m not attempting to, in any way shape or form, imply that any of this should be done, it’s just a fun thought experiment I wanted to share with the community. That being said, here’s the list

Hardware related things

Support for higher resolution screens, and more powerful processors

There are many small hackable devices/retro consoles which are commonly used for emulation (such as the anbernic rg351, and odroid go super), which would be awesome little makecode devices. However they have significantly more powerful CPUs, a large step away from the tiny little M4 MCUs in current makecode hardware. It would be really nice to be able to have support for more powerful devices (such as, but not limited to these) and run our projects on some more substantial hardware.

Larger flash/storage access (good addition for more colours/larger screens (see below))

Some current makecode devices have secondary flash chips/SD card slots, which could allow much larger projects to run on these devices. Games making use of this feature could potentially be downloaded in two parts, with a seperate “assets” uf2/zip file to be placed on the other storage medium. Uses include multiple full-screen images (think backgrounds for different zones/levels/areas) as well as the “background layers” feature I always wanted to use but never had the space for enough assets to properly utilise it.

Software related things

More colors

Yes, this has been discussed, I’m still going to mention it though. The 16 colour limit, while good for memory and easy to work with, is noticeable, especially when trying to make something really pretty. Having the option (even if it’s disabled by default) to have a 32, 64, 128 or larger array of colours would let aspiring pixel artists extend their skills and make something gorgeous. Custom palettes are great, but they can only go so far.

Tilemap triggers

A concept frequently used in many game engines for initiating scripted sequences would be exceedingly useful to have in makecode tilemaps. Like invisible zones which call an action when a sprite enters them. This could be opening a door, loading a segment of a level, playing a sound effect, starting a boss fight, or any manner of things. Being able to create them like tiles and place them like walls on a tilemap would allow for many different.

Automatic unloading of sprites

In certain games, sprites can be used for collectables across the level (say, coins). This works well if the level is below a certain size, but when it increases in scope, having a hundred or so sprites each with collision and animations playing constantly can tank the processor on the hardware. A potential solution to this would be creating a sprite flag which can be applied to non-crucial sprites, such as these “coins”, which tells the engine to unload them when they travel a certain distance from the camera. In the unloaded state, all that would be needed in memory is their coordinates, info about image/any other properties explicitly declared, but all animation/collision/rendering could be deactivated to save resources.

Custom game resolution (good addition for larger flash access/better hardware)

Ok, I realise this is almost certain to never happen, still worth noting though. Being able to set a custom resolution for your game would let it look nicer on more powerful hardware (should it ever be supported) and allow for greater complexity games/less cramped play areas than the current 160x120 (which was considered low quality by the time of the NES)

Better audio support

This has been something that someone mentioned the team was thinking about, and I look forward to seeing what they do with it. It’s just right now making music/sound effects for games is a little difficult, so having a simpler, more intuitive method of doing this would be appreciated (no idea how such a thing would be implemented though)

Conclusion

Once again, this is just a wishlist, the last thing I want is to make people feel like this is a demand or request, or anything. I think makecode and its developers are truly wondrous and should keep doing what they think is good for the platform. If I knew enough to contribute to the project (yay open source!) I might, however that is currently beyond my capabilities. This post is just to get some ideas turning as to what people might want in a future release/update, and if any of you have suggestions or additions please comment them too!

8 Likes
#2

You can run MakeCode Arcade on the Raspberry Pis I believe which is hundreds of times more powerful then a samd51

You can set a sprite to be ghost via the sprite flags block, which disables all collisions.

You can trigger code when the player overlaps certain tiles, but say having multi-layer tilemaps at different z indexes and being able to hide some of them so they are for tilemap overlapping only would be cool

1 Like
#3

A common way to reduce calculation of detecting collision between sprites is to divide them into zones and check collision against sprites in the same zone.

Looks like the current implementation is doing it this way?

#4

That’s true, I forgot about that (was originally going off the “hardware specifications” section of makecode arcade’s docs). It seems that it’s using Linux as a bootloader for the arcade system running as an application. I wonder if the same methods used for that port could be made to work with others! Having a desktop “Makecode VM” to allow for this (or even exporting your games as desktop apps) would be cool! (apparently they used to have this, would be awesome to see again!)

Indeed, however at present there is no way to do such a thing without a forever loop and the is out of screen function. While this would certainly help the situation, it would have a performance impact in and of itself.

The only downside to this also is that for the game to identify these “certain tiles”, they need to be visually distinct from others, which may break the illusion for the player. This could be helped by having them on different z indexes, although it would once again, come at a performance impact of having two tilemaps loaded.

1 Like
#5

That’s smart, I’ll look into trying to adapt it to work in my game! would be nice if they exposed it as an API for us to use though. Thanks for the idea!

#6

These are really cool suggestions! Some we’ve had in mind before and not implemented at this time e.g. tilemap zones, unloading sprites, etc.

If you have any experience with javascript / typescript and have requests on things to expose like this, you should feel free take a look through the game library and list out anything you think want to be exposed / what you would use it for (https://github.com/microsoft/pxt-common-packages/tree/master/libs/game). Even if you don’t have significant experience with those languages, a lot of the code can be skimmed through to get an understanding (physics.ts notwithstanding, as that’s some of the ugliest code I’ve ever written in the name of hardware performance – e.g. things like not using helper functions to save 2-3fps in the collision detection logic)

For the most part, things like that aren’t hidden because they need to be, it’s usually just trying to minimize the external shape of the game library so people can’t take dependencies on things we don’t expect them to (as if they do, when we make minor internal changes we might not know when it breaks their code). As long as we are aware of it, we can likely expose pretty much anything & just know that we know will need to provide upgrade paths / handle backwards compatability in the case of significant refactors :slight_smile:.

2 Likes
#7

I think arcade needs more color in the color pallete