Recent community posts
Hi Dear Jared,
Thanks for the words! I’m glad you like it.
The audio backend reads and plays pre-made audio files, it doesn’t synthesize at runtime, so something like a built-in tracker would not happen. However it supports .mod, .mid, etc files on some platforms, so a music/sfx generator would be an alternative, if you would not mind using an external software.
Another approach would be writing a tracker in Lua as a regular Bitty program, someone from the community had done it once, but his site seems to be down at the moment: https://retro-bruno.fr/bitty-engine-retro-tracker/, I’ll ask him for a backup in the Discord server.
It depends on the features you would like to include in your game. The current alpha 1 version can be used to paint tiles, maps, and to write code, I think there’s no problem with really really simple games, it is yet not capable for making music, actor and scene, besides, the runtime is lacking in completeness. I’ll improve editors in alpha 2, 3, then move on to improving the runtime in alpha 4. As the version stage implies, I’d rather claim it feature-complete for generic development until all the alpha stages are complete.
Thanks for your interest and understanding!
It supports string partially, i.e.
print "pi=%d", 22/7 and
label #0 "hello", the string are constant literals, this is enough for text representation. As a constrained platform, gb is not very good at dynamic allocating, so it doesn’t support assigning string to variable, concating, etc.
Actually the runtime part is based on the GBVM project, their capability are quite similar.
It depends, someone finds Lua is easier for a beginner, the others prefer Python. I’d like to share some of my experience as a glance.
Lua and Python in common:
- Both are scripting, dynamic typed, weak typed. Pro: there’s no complex compiling pipeline, it is often just one click to launch a new program; Con: it doesn’t check variable types before running, so you have to keep in mind which variables are for what, but good naming would help.
- The languages themselves do not offer the ability to create a game directly, Lua is often embedded in integrated development kits, Python can import game creation libs.
- Lua is prototype-based, Python is class-based. Someone find class-based is more intuitive than prototype-based to understand, but once you get the idea of prototype, in my personal opinion, it is more elegant for game development.
- Because of its embedded nature, installing a Lua-based development kit is often simpler than Python.
The app is still in an early stage, there’s not yet a dedicated version for common ARM-based mobile systems (iOS, Android). It was designed in mind to be both desktop and mobile friendly, and the dev-tech behind is platform independent. So it has a potential for a mobile release, but I just could not guarantee possibility. But I’ll post an update when there would be progress on it.
The idea is that it encourages a user to think over and organize what to do and how long a task will last, but does not encourage to suspend once the user presses the start button. However there could be unexpected interruptions, the pause system is right for this purpose. Each pair of WORK-REST pomodoros offers pause budget up to 5 minutes to deal with interruptions, the budget resets when entering next WORK pomodoro.
Nice! I'll update the instructions.
BTW. I also tried to package it in a .dmg instead of .zip, turns out it requires the same commands. Seems Apple has tightened their strategy for running 3rd-party apps outside AppStore.
Googled, and found this https://osxdaily.com/2019/02/13/fix-app-damaged-cant-be-opened-trash-error-mac/
Apply both `xattr -cr bitty.app` and `chmod 777 bitty.app/Contents/MacOS/bitty_drm_free` should work, tested on a Big Sur.
Just copying the installation instructions on the page bottom:
- Download and unzip the package
- Apply execution permission to the executable (i.e. "chmod 777 bitty.app/Contents/MacOS/bitty_drm_free")
- Execute by double clicking "bitty.app"
In my experience it requires less extra operations to get it run before MacOS 11, it solves most of the issues by giving it execution permission. But you might need to allow 3rd-party app to run in the system settings besides the permission, if it's not turned on yet.
I've tested the latest package on both MacOS 10.15 and 11 (big sur) on which it works ok. Feel free to tell me for any troubles.