A request for a game creator

Hello everyone. I am in great need of a arduboy drag
And drop system where you can drag and drop items change there collide true or false value edit sprites and make objects and honestly what I’m saying is the forum needs

thank you for your time

This was somewhat incoherant, could you please elaborate?
Are you asking for a drag & drop code editor or some kind of drag & drop functionality in the Arduboy library for use in games?

They are saying they want a drag and drop Game Maker or Construct style editor for Arduboy games.

1 Like

Thanks @wademcgillis … I am glad you could understand what Cody was asking.

1 Like

Assuming that’s what this is about:

It would probably be useful for beginners or for people making really quick mockups, but I think generally a drag & drop editor wouldn’t be useful enough to justify the effort to make it work well.

The problem with a ‘collision’ true/false checkbox is that sprites and collisions are library and game specific.
With something like the UE4 editor or the Unity editor you can get away with those because those editors are targeting specific highly generalised libraries for making games that target computers with lots of available resources (thus they can afford to generalise) but the Arduboy has much less resources so it would be hard to make a generalised library without consuming resources unnecessarily. It would be alright for small games, but anything substantial would be better off being ‘hand-crafted’.

For example, a platformer might require a notion of gravity, but a top-down dungeon explorer probably wouldn’t so using an engine that implements gravity for a top-down dungeon explorer would result in wasted memory and processor time. Game engines for modern computers generally don’t care about that because they have lots of memory and processor time to work with, but for an Arduboy game that could be the difference between the game fitting in ROM or not. (I know that’s a somewhat localised and contrived example, but the fact remains that an optimal platformer game engine tends to look quite different from an optimal top-down dungeon explorer.)


To clarify, I’m not saying it’s an outright terrible idea, I’m saying that it’s problematic as things stand.
If there were more interest in it then such an editor could be justified in the future, but there has to be the demand to justify the effort. For example if there were an upsurge of beginners or enough teachers wanting it for teaching younger/less experienced students then the development of a block editor might be justified. (There would still be a long list of caveats and limitations, and it would be more of a learning tool or a means of making prototypes than it would be a tool for developing actual games.)

Ultimately everyone who develops for the Arduboy should aim to learn C++ to truly get the best out of the console. The reason block editors are so much rarer than programming languages is (partly) because programming languages are much more expressive and give the programmer a much higher degree of freedom.


I’ve been interested in making something like this for the Arduboy for a long time. In the past, I’ve played around with things like an on-arduboy code editor and VM that runs games written with that editor, intended as a type of stepping stone to figuring out how to approach this.

On the topic of collision, since yesterday I have been implementing an Atari 2600 TIA-style rendering library for the Arduboy. Part of that includes converting GLOVE to work with it as an example game. Part of the TIA-ness of the library includes per-pixel collision registers as it renders each scanline (in NTSC-terminology). I’m hoping this approach will make collision detection simple, but I only just finished the library and have yet to integrate it with GLOVE, so we’ll see! :smile:

Edit: Also, since I cut out all of the drawing code from the standard library, there’s about 875 bytes more free RAM (when using 64 sprites and a 16x8 tile background layer) and about 2.5k more free ROM, and the algorithm to draw a scan line is O(n), where n is the number of sprites. So far with lots of sprites bouncing around it looks great, but I haven’t don’t proper benchmarks or GLOVE integration, so we’ll see if it’s actually good or not! Also yes, the “not racing the beam” aspect of programming is very much the not-TIA-like side of this library! :smiley:

Wow … this sounds interesting. Maybe start a new thread (if you haven’t already) and keep us posted.

I’ll definitely make a thread once it’s useful! I did some benchmarks and looked at the generated assembly and found out the code is pretty slow! The bit shifts on the Atmega get turned into loops, and since I’m using 64-bit unsigned integers I got to see some awesomely bloated assembly! The entire drawing library itself is only about 30 lines of C code (with long lines including multiple ANDs, ORs and XORs, multiple layers of pointer dereferences and other unsightly stuff of that nature), so I guess I need to do more a lot more optimization at the assembly level when it comes to performing the shifts. Well it’s the first iteration anyway; this is the fun stuff! :laughing:

Code generation is not an easy task. Compiler theory is its own branch of computer science for a good reason.

That’s because the designers decided not to give it a barrel-shifter (a fancy circuit that lets the CPU shift multiple bits in one instruction), instead the ‘shift left’ instruction actually translates to ADD r3, r3 (adding a register to itself, r3 used as an example).

I believe the technical term for that is ‘eye bleed material’. My brain is bleeding from just imagining it.

Depending on how the code works you might be able to stick a lookup table in progmem and use that as a bit of a hack. (I know it’s possible because the Arduboy2 library use a variation of it, which I know about because it was part of the code I was working on that one time I helped fix a bug in the Arduboy2 library.) Alternatively you might be able to use a regular multiply (might not be faster, but it’s probably smaller… probably).

Yeah, I played with using a small lookup table last night. It replaced the 0-63 shifts with multiplication. It seemed promising but the way I tried it managed to slow it enough to actually see slowdown! When I have time later, I’ll try a different approach. In the past I had first hand experience with slow shifts. When generating the collision map at runtime in my unreleased metroid-style game, Blackout, I was able to get around it using division because they were constant values! :smile:

1 Like

I won’t ask more because I don’t want to clutter the thread too much by going off topic, but if you decide to ask for a bit of insight in another thread sometime in the future (and hopefully provide some code) I’ll definitely be sure to stick my nose in to see if I can offer any suggestions. If you haven’t already looked at it, be sure to look at the ‘canonical’ bithack guide “Bit Twiddling Hacks”.

It looks like this is a request for a game editor not actually drag and drop, because you can add images to posts via drag and drop. It’s something we would love to support but don’t have the resources internally right now to take it on.

If someone in the community needs some help our resources to complete this than please reach out to us!

*editing the title to reflect the request.


I thinks me English was goodly
Watt now

* Weird Al starts singing Word Crimes *

Seriously though, now you just have to wait to see if @fuopy’s project succeeds or if someone else wants to take up the gauntlet.

As I said, there’s a lot of work involved in creating something like this, and at the moment there’s not enough justification to create it in an official capacity, you just have to hope that someone wants it enough to make it of their own accord. You could try to stir up some interest from some of the educators that frequent the forums to see if you can tip the balance, but either way it would be a long wait before anything materialises. If you keep reading up on programming topics you’ll probably surpass the point where a block editor is useful to you before it’s even finished.

1 Like

Watch it … I’m an Aussie too!

I know. So is Bergasms as it happens, and probably other people here that I’m not aware of.

I like Australians, without them we wouldn’t have Neighbours or “Australian Space Gandalf” (a.k.a. Greg Quicke), or a large number of Valve employees.

I wanted to do a joke about the bad grammar and spelling but that was all I could think of. I’ve got one now though, I’ll swap it out.

1 Like

I think I smell internet_war_III

Only 3? Shouldn’t we be on 3,000 or something by now? :P

1 Like

i haven’t given this a go and haven’t really taken a proper look at it (looks like it hasn’t been updated in forever), but this looks like a LOT of the heavy lifting could already be done and could be repurposed, or maybe it already works and i’m just too lazy to install QT and compile it and whatnot…

anywho, i would absolutely love this builder/editor tool to become a real deal thing that exported the code and whatnot, heck i would donate a chunk of money for this for sure!


YouTube Playlist - check out the level editor

That code is for a tile editor and an emulator.

The emulator is very impressive (and should be posted in its own topic because that’s something people have been looking for), but both are a world away from a block editor.

The editor part is just a tile/level editor, it edits data and then simply dumps the data into progmem (i.e. a couple of PROGMEM arrays) with maybe a bit of lightweight processing. Typically they’re not very hard to make.

A block-based code editor has to do all kinds of checking that the code is valid, has to know how to generate the right code, has to either be able to read C++ code (which itself is a major feat) or have its own file format.

Like I say, the emulator is very impressive and should be in its own topic, but neither of these things’ existance makes creating a block editor any easier.