[POLL] Pretty Simple Game Jam 5 Vote!

Games Game Jam 5
1

Pretty Simple

18 games were submitted for the Arduboy Game Jam #5: Pretty Simple!

You are suggested to vote for the game that you think is the most simple, easy to play and learn game that is also pretty. But, also vote for whatever game is your favorite!

Polls close 2020-09-09T17:00:00Z

2 Likes
2
3

@bateske is fine, very easy to vote but hard for some games. I voted for my prefered game (and for a new creator as we know all that some are always making great gamesā€¦) but itā€™s a little hard on counts as some good games have a very low score even they are great as we prefere another game. I know itā€™s hard to make a good adjustment but i thanks to other authors as this Jam have some very good games. Gratz to all

1 Like
4

Having only one vote makes it really hard to choose.

Weā€™ve had a lot of good games this time around.

9 Likes
5

Could the authors (or a mod) please make sure all the entries have a working emulator iframe for each thread? It really helps lazy people like me :wink:

2 Likes
6

Program Sizes

Although Iā€™m not sure I agree with it, one of the criteria for awarding prizes for this jam is program size, as described here. In regard to this, I wondered:

An example would be some entries having the boot logo removed and others not. I proposed a way to accomplish this here. Iā€™ve taken it upon myself to do this, with some changes to the original proposal (detailed further on). Here are the results:

Org. Size is the original size compiling the provided source.
Adj. Size is the ā€œnormalizedā€ size after adjustments.

Name Org. Size Adj. Size Difference
Firebox 7594 7594 0
Alice Catches Cards 11890 10990 900
Quick_Block 12304 11508 796
filthecup 13002 12386 616
SlidingTiles 13952 13150 802
FlufflesRainyDay 14582 14002 580
BeamEmUp 16920 14112 2808
MissSnake 14726 14392 334
NewBlocksOnTheKid 14830 15002 -172
ArduboyZenbox 17320 16760 560
Rhythum 20668 20082 586
RushIDE 20738 20758 -20
Lion 22042 21872 170
buttonMash 22892 22350 542
apprentice-wizard 23306 22782 524
InsaneSkulls 24092 23468 624
MannBarSchwein 24908 24108 800
evasion 25646 25464 182

It turns out that BeamEmUp was the only game affected by the process, gaining 2 spots in the order.

Adjustment Process No entries removed the USB code, so I left it in for all of them.

If an entry used the Arduboy2 class but didnā€™t use any library text functions, I changed it to use the Arduboy2Base class.

If begin() was used, I changed it to boot() with additional calls as given below. If boot() was used instead, I adjusted the additional calls as necessary.

  • safeMode() was always added or replaced flashLight().

  • bootLogo() was always removed.

  • display() (used to clear the screen) was always removed, on the assumption that all programs would clear the display again shortly afterwards.

  • If the entry didnā€™t generate any sound, I used:

  arduboy.boot();
  arduboy.safeMode();
  • If the entry generated sound, I used:
  arduboy.boot();
  arduboy.safeMode();
  arduboy.systemButtons();
  arduboy.audio.begin();
  arduboy.waitNoButtons();
  • However, if an entry with sound included its own code to turn sound on and off, I used:
  arduboy.boot();
  arduboy.safeMode();
  arduboy.audio.begin();
Entries of Note

Firebox uses only the Arduboy2Core class instead of Arduboy2 or Arduboy2Base. Iā€™ve never seen that done before. Itā€™s the smallest but more work is involved in writing functions to replace those normally provided by the library.

BeamEmUp is the only one that uses class Arduboy2 but doesnt use text functions. Switching to Arduboy2Base reduced it enough to move it up in the order.

NewBlocksOnTheKid has sound but doesnā€™t include systemButtons() or provide any other way of turning sound on and off. This means that in order to turn sound on or off, another sketch has to be uploaded to do it, then NewBlocksOnTheKid has to be uploaded back in. I suggested to @bateske that systemButtons() be included (along with a few other notes in the post that followed). His response was:

Following my procedure, meaning including systemButtons(), increased the adjusted size for this program.

RushIDE uses boot() but doesnā€™t include flashLight() or safeMode() to guard against the bootloader ā€œmagic keyā€ problem. Adding safeMode() slightly increased the adjusted size for this program.

MannBarSchwein is written using the Nim programming language. I didnā€™t want to go through the process of setting up to be able to compile it. I estimated what the savings would be based on entries with similar features (uses begin(), uses text functions, no sound). If my estimate was off by a few hundred bytes either way, it wouldnā€™t affect the order.

evasion tests specifically for version 5.2.1 of the Arduboy2 library. I had to change it for version 5.3.0 to match what I used for all the rest. This may affect the size that Iā€™ve given compared to the size of the included .hex file.

Note that this post is in no way a proposal that any sketch use what Iā€™ve done to reduce code size, if not necessary. Quite the opposite; if you donā€™t need the extra space you should use begin(), not boot(), and using class Arduboy2 even when itā€™s possible to use Arduboy2Base wonā€™t affect the actual operation of your sketch.

My doing this was only to provide an ā€œapples to applesā€ comparison of relative code sizes for the purpose of contest scoring.

2 Likes
7

Ah, Iā€™d meant to change to Arduboy2Base for BeamEmUp, thanks for the reminder. Iā€™d used the print methods while debugging physics, but with those removed thereā€™s no need for them.

8

Sabotage

Also, I didnā€™t know you could do tables in discourse.

ALSO: I wonder how small my game would have got if I had not included all those words and maybe taken out the usb stack.

9

As I said in the note, I suggest you donā€™t until you actually need the space. The Arduoby2 class provides the feature to display the unit name at the end of the boot logo sequence, if the unit has it set. Using Arduboy2Base will eliminate that because the text functions are required for it. (Users can set a flag in system EEPROM if they donā€™t like the feature.)

1 Like
10

Why wouldnā€™t you be able to? Tables are standard HTML.

(There is also standard markdown syntax for tables, but it hasnā€™t always worked in Discourse.)

11

Like I said, you should include systemButtons() unless you include some other way of toggling sound.
ā€œTurn off the sound on that game. Itā€™s bothering me while Iā€™m driving!ā€
ā€œI canā€™t Mom. Thereā€™s no way to do it.ā€
ā€œYou could with that other game you had loaded.ā€
ā€œBut I canā€™t with this one.ā€

But why would you want to if you have enough space for it? This is why I donā€™t think program size should be a criteria. There are too many variables and considerations involved.

At least what Iā€™ve done equalises things a bit.

12

image

2 Likes
13

Neat! Firebox is smallest by quite a lot :slight_smile:
It was a refreshing change for me to fit into a single .ino sketch instead of multiple cpp/h files like my other games end up doing.

I had to do this because the fire simulation uses 2K of RAM so I had to design it not to use the Arduboy2 library frame buffer. There is a routine that generates the dithered display output from the fire buffer and sends it to the screen 1 byte at a time using Arduboy2Core::paint8Pixels()

2 Likes
14

Hmm, damn it. I read that as code size, not program size. The code for MannBƤrSchwein (excluding library code, including sprites) is less than 500 lines wrapped at 80 characters, but since I load a lot of sprites to make the game look pretty the size of the program ends up pretty big. Just removing the paralaxing mountains in the background drops the size by 2108 bytesā€¦

15

And this is why I donā€™t think code/program size should have been a consideration. It causes the developer to have to trade off between size and features. It also gives an advantage to expert coders who know the tricks, without affecting how the game plays for the user.

Code size should only be used for competitions involving performing specific functions in the smallest amount of code, such as a sort algorithm.

I considered code size to include that of any library functions actually used within the game. Should it include ROM data, such as sprites or fonts? Thatā€™s another grey area.

1 Like
16

Suggestion: rather than having small program size as a criteria which could result in devs not beautifying their games with unnecessary yet pretty sprites, how about simply having program size limit? This could even change from jam to jam to encourage really tiny games or larger elaborate ones.

Iā€™ve done a couple of 1kjs entries and itā€™s really fun seeing what people can do with the same number of bytes.

17

This is a bit more complicated in Nim. My code uses a lot of templates and macros, they are fairly short, but are evaluated during compile-time and expands into more code. My loadSprite macro for example reads the BMPs I use for my graphics and emits a progmem array of bytes directly into the code. This means that my code reads loadSprite(manfood, "money.bmp") but the actual code that is compiled is something like const PROGMEM uint8_t* manfood = [...]

18

Thatā€™s fine when the goal is more or less to award bragging rights to the developers. In the Arduboy environment I think it would almost always be more beneficial that the goal be to create quality fun games for the users. Restricting things by themes is fine, but by size, not so much. Even something as vague as ā€œparticlesā€ is good.

Exactly. Another reason for not considering size.

1 Like
19

Actually doing the smallest something makes sense for a next jamā€¦ I.e. who writes the smallest functioning pac-man clone. But I guess the results would be less interesting as PR than original creations

20

For what purpose? I assume @bateske provides prizes at least partially for promoting sales by having more unique games available. I donā€™t think 10 versions of pac-man would help very much with this.

You could do it without prizes but might not get many entries.