Caterbuino Post Mortem

General

Mokona

3 months ago

Now that my first little game on Gamebuino is almost finished, and at least playable, it's time for me to write a little post mortem before potentially starting another one.

So, let's see what was good and could be improved.

The Good

The console:

The Gamebuino Meta is a very nice little game console. There is a lot of small gaming or small PC hardware out on kickstarter each day, each with their own identity. The Gamebuino Meta has the advantage of being the second one of its line.

I was nicely surprised when receiving it by its design and, also what I care about a lot, the tools to program it. There are some thoughts being it. And you can really play with it. So good. Nice console, nice packaging, nice startup environement.

The programming documentation:

It's there. It's awfully slow to load online and some parts would gain being rewitten a bit but it's there and usable, updated. In one or two occasions I had to look at the source to clear some aspect, but not more. Having a documentation is great.

What COULD BE IMPROVED

In short... tools, at large.

Default Environment:

the Arduino default programming environment, based on Processing, is nice for making LED blink on a small board. Or for tying up a bunch a libraries with a bit of logic. I even programmed a robot on wheel with it, and had already felt the pain quickly. For a full game, even a small one, it quickly got on my nerves.

I tried to fix this by going in another direction. That could be Eclipse, or even any well configured text editor with a (c)makefile. I went in the direction of using Visual Code, becaue the plugin was working rather easily for Arduino. For Gamebuino, it gets a bit harder because you have to specify where the include files are, which I found not so easy an information to get. By looking at build logs from the Arduino environment, I got something that worked, but it really looks as a quick and dirty solution. I don't like quick and dirty solutions if I have to live with them more than a few hours.

I also discovered that the folder and the .ino MUST have the same name for the Arduino pipeline to work. Really not flexible, but out of Gamebuino scope.

So that was far less than ideal, but enough for this small project. If I'm going for another one, I'll have to spend a bit of time to find something correct (except if someone else comes with a nice solution meanwhile).

What are you using as a development environment?

Build pipeline:
so I'm not sure if it's the Arduino pipeline or the Visual Code, but I get more than too much rebuilds rather than builds when uploading or verifying the program. It seems even than going from verying to uploading and the other way causes a rebuild. Again, when blinking a LED, that's ok. When you decided to separate the concerns of the programs in different files, that's more problematic. I globally have awful build times for such a small program.

But it also happens that some object files are not regenerated even if they are dirty. Or that, after removing a source file, the object file is still linked. The build system seems completely wrong.

So, I'll have also to spend time understanding why. If it's the Visual Code plugin, moving away from it or fixing it will be necessary (which is time not developping the game).

Did you experience the same problems?

Gamebuino META SDK:

the SDK is overall really nice. The public source code is readable and that's a big help.

But... it defines min and max !

Please please please, don't #define min/max in headers, that collides with so much libraries, STL as the first of them.

Well, there's a simple workaround. Rather than including the Gamebuino SDK directly, I include a local file that #undef the min/max macros. That's ugly, but such a classic.

Packaging:

Uploading the icons so that's the OS converts them to local files, then downloading the whole thing and package it? I'm the kind of programmer who thinks that automation of boring and error prone tasks is what computers are made for. This could be a command line tool.

Pictures to C code:

After having made three times the same mistakes when using the online converter, and reminding myself the comment on automation I just stated above, I did my own offline converter.

What were the mistakes: first, using Firefox. THe converter doesn't seem to work with Firefox. So each time, I used the page, tried to understand why it didn't work, then reminded, then launched Chrome then... went to the second mistake.

Second mistake was to use a rectangular layout, because working on frame on a full vertical layout is unpractical. So I wondered each time why my data were all wront and... oh yes, let's cut and paste the picture in GIMP. Time lost.

(we could conclude that I'm really short minded not to recall this each time. My sessions of hobby programming are distant from one another, I tend to have my mind flushed with other things between them).

Conclusion

Lovely little console. I like it. It's fun. There's a particular attention to details. In the software visual quality also, like providing an official palette, which gives a feel to the games (and really, my poor graphics got a little less poor when I switch to the official palette)

The best improvement direction I'd see now is on the development tools, to let people concentrate on the game.



Sorunome

NEW 3 months ago

Thanks for the extensive feedback posts, such things are really helpful for improving the product!

The programming documentation:

It's there. It's awfully slow to load online and some parts would gain being rewitten a bit but it's there and usable, updated. In one or two occasions I had to look at the source to clear some aspect, but not more. Having a documentation is great.

As for the programming documentation being slow, it was affected by the same thing that made the entire site being slow. Since the site got supercharged with speed earlier this week (I think it was monday) that might have been fixed by now.

As for some parts needing re-writing - looking over the entire documentation is on the list. That being said, documentation is there to document the functions, not to act as a tutorial. Suggestions are always welcome!

Default Environment:

I have to agree, I personally dislike the Arduino IDE. I use Atom with the arduino-upload package, and it works like a charm to me (Disclaimer: i have written that package myself). Similar things probably exist for other programing environments, too. I hear platform IO is a pretty popular choice.

For Gamebuino, it gets a bit harder because you have to specify where the include files are

If the Visual Studio plugin is written correctly it would obay board definitions, you would pick the Gamebuino META board and everything would work fine >.>

I also discovered that the folder and the .ino MUST have the same name for the Arduino pipeline to work

Yeah that's a thing with arduino. As you can see, as a result of that the .ino for Reuben Quest is pretty bare-bones, mostly using stuff from other .h and .cpp files.

Build pipeline:
so I'm not sure if it's the Arduino pipeline or the Visual Code, but I get more than too much rebuilds

I am not sure how the Visual Code plugin implements arduino building, however, Arduino itslef keeps track of object files and thus only re-builds changes when re-building. When writing my arduino-upload package up there i had to purposefully take that into consideration to add that feature to that, so perhaps the Visual Code plugin you are using doesn't use that feature?

Gamebuino META SDK:
[...]
But... it defines min and max !

That is actually part of arduino. I am unsure how to go about this, as just removing those in the Arduino.h files distributed in our custom board definition may break existing compability and make it hearder for newcomers who just know "it's like arduino" that there are indeed a few subtle differences. Suggestions are welcome!

Packaging:

Uploading the icons so that's the OS converts them to local files

Yeeeaaaaah we still need better build tools. Getting there step by step!

Pictures to C code:

[...]

What were the mistakes: first, using Firefox.

I noticed that, too. Glad you made your own CLI tool, though!


To conclude, it seems like your biggest hassle (except tools) were with the Arduino IDE. Maybe some kind of tutorial on alternatives and how to set them up would help?

Then, as you mentioned, tools need working, or are, for some parts, non-existing yet. Again, we are aware of that, but, well, we can't do everything at once! Community help is always welcome!

Mokona

NEW 3 months ago

Thanks for the comments.

About the include path to tell the plugin, it's in fact not exactly the Arduino plugin that needs them (it's using, as you say, the Arduino pipeline), but the C++ plugin to activate Intellisense. And jumping to symbols is always a nice to have.


You must be logged in in order to post a message on the forum

Log in