After three months of development, Gameeky reaches its first public release. This project is the result of nearly fifteen years of experience contributing to education projects and mentoring young learners.
I am happy to share it everyone!
Although this project can still be considered in early stages of development, it’s not far from being feature complete. This first release comes the following:
A game launcher to manage projects more easily.
A game client to play games cooperatively.
A scene editor to create and modify game worlds.
An entity editor to create and modify game objects.
A Python library for a LOGO-like experience.
Plugins support to extend the games logic and entities behavior.
An offline beginner’s guide.
The first thematic pack to create role-playing games in a medieval fantasy setting.
Gameeky is available in English and Spanish, including the beginner’s guide.
The recommended installation method is through GNOME Software from Flathub. Alternatively, it can also be installed from the terminal:
flatpak --user install flathub dev.tchx84.Gameeky
The first thematic pack can also be installed from the terminal:
Twenty three years ago a magazine I read featured tools for modding popular video games I had spent hundreds of hours playing.
That article triggered a chain of events that would soon lead me into learning how to speak English, collaborate with people on the internet and, eventually, pursue a career in computer science and open source.
Since then, It became important for me to replicate pieces of that experience for the younger. Not because I wanted everyone to become a software developer, but because I wanted everyone to experience that genuine satisfaction of learning new things while enjoying it.
A problem of exposition
It’s no surprise that video games are often studied and applied in Education. It’s hard to find a better medium that mixes art, math, technology and other STEAM fields.
Although there are plenty of tools out there, those that can take a learner all the way from a consumer of a medium to a creator, are rare. There are great low-floor tools but, only a few make attempts to transition the learner into more powerful paradigms and there are great high-ceiling tools but they often are prohibitively complex.
It’s not a common realization that professional game development tools are designed for creating games efficiently and justifiably are not designed for a comprehensive learning experience for the young.
Giving the problem a try
Therefore, how would a game development tool look like if (a) it’s designed for the learning experience first and above all and if (b) it allowed the learner to experience the learning process in subtle steps.
I spent the last two months tinkering with those ideas and came with Gameeky, a learning tool that will allow educators and learners develop new skills while creating video games.
Step 1: Play games
The first step is simple, provide as many games as possible and have both educators and learners experience and enjoy them. The following example games were made with Gameeky.
An important detail is that these games were created with no programming whatsoever. Note that I didn’t say no thinking whatsoever. There’s definitely a lot of thinking involved, and there has to be.
Step 2: No-code game creation
Gameeky allows everyone to create games by simply putting objects called entities together in a virtual canvas, which is a common architectural pattern in video games. TL;DR everything that exists in the game is an entity. The grass, the trees, the creatures, the light sources, the ambient sounds, the player and everything else are entities.
This reduces the whole concepts zoo to a single concept and sets the stage for the creation of a simple game editor.
The editor exposes all the entities that exist for a game and provides a way to compose a scene with them. Layers can be specified to ease the edition of the scene. Tools for common operations are available, e.g. to add or remove entities from scene or to override parameters for a particular entity.
To expand on entities, these are composed of three fundamental parts (1) parameters that control their behavior, (2) animations and (3) sounds.
An entity can be in one of many states, e.g. “moving” to a place, “using” a tool, etc. Then both animations and sounds can be assigned to each of these states, e.g. “render this animation when the entity is moving north” and “play these sounds when it’s using a tool“.
Actuators are predefined blocks of logic that can be assigned to an entity, e.g. there’s an actuator called “roams” to make entities move aimlessly, and there’s another actuator called “exhausts” which reduces the entity stats to limit the amount of actions that it can perform, and many more.
As I mentioned earlier, even when there’s no programming involved, it still requires some thinking to master the system beneath those entities. Which in itself is a valuable learning experience.
Educators and learners can also engage in all sorts of creative and artistic activities while creating these games. From drawing the characters tilesets for the animations to recording sounds effects, Gameeky can encourage them to learn even more art-related tools.
Better with company
One of the best aspects of creating something is to share it with others but, even better than that, it’s to experience it with others. So, to achieve that, Gameeky is designed to allow all games created with it to be enjoyed cooperatively.
Step 3: LOGO-like with Python
Something interesting about a game that can be experienced cooperatively is that it opens the door for more than just human cooperators. How about cooperators that can be controlled with code.
Gameeky provides a small library that enables learners to control a single entity using Python, in a LOGO-like experience. See the following example.
Even when this is a purposely limited experience, the opportunities for learning are limitless. A few examples below.
An educator can prepare a set of games for programming challenges, where the learners would need to write actual Python code to solve the challenge, e.g. traversing an obstacles field while having to move different objects and so on.
It’s even more interesting when you factor-in the cooperative aspect. It’s very common to see sumo competitions in robotics. Something like that could be quite interesting to replicate with Gameeky, and go completely over the top with complex scenes for these competitions.
Step 4: Plugins with Python
No matter how good the entities system, it will always be limited. That can be the perfect motivation for more learning to occur. To prepare for this, Gameeky comes with plugins support to extend the predefined actuators. See the follow example mini game.
In this example, a new actuator “bounce” is created as a plugin and it’s assigned to one of the cats in the scene. Since actuators can be used to control the whole scene, it can also be used to code complex game logic, e.g. the “winning” condition for the mini game is to be the first to capture a cat.
Step 5: Engine with Python and beyond
The strongest benefit of an open source learning tool is that the learner can become the creator. The ultimate challenge that Gameeky can offer is its own code. Reason why this project will always prioritize simplicity and legibility above all.
Besides releasing the project and making it available on flathub, there are some major priorities.
First, it’s missing a basic ed-tech kit and tutorial. To be clear, no matter how good this tool can ever become, if an educator can’t use it due to lack of guidance, then this tool will not have accomplished anything. This includes, the creation of basic entities packs.
Second, it’s missing basic documentation. I need at a minimum a URL I can point people to if I don’t want to spend the following months simply answering questions about this project.
Third, optimizations. There’s probably not a single area where optimization is not needed, e.g. the scene graphics rendering is clearly slower than it should be, the network protocol can simplified, etc.
Frequently asked questions
Q: When do you think you can release this?
A: Hopefully soon, when it’s ready.
Q: What is the age target for this project?
A: As mentioned in this blog post, this project targets a wide age range due to its steps approach but, I haven’t validated that yet. I plan to run some workshops early next year to validate it. A totally arbitrary guess would be, depending on the step, ages between 8 and 17.
Q: Why having the map editor as a separate app?
A: Both technical and subjective reasons. Regarding the technical reasons, as I am a single person working on this, it is safer for me to design, implement and maintain smaller tools that interoperate than a single big monolithic tool. Regarding the subjective reasons, it is my perception that reducing cognitive overload is preferred for tools like this, so separating things helps.
If building the scene cooperatively is something someone is interested in, that can be achieved by creating Gameeky game where the goal is to create the scene, e.g. have a tool that spawns trees and voilà!
I am happy to announce a new release of Flatseal. This release comes with refined visuals, improved performance, support for a new permission, quality of life additions, and fixes.
Starting off with visuals and performance improvements, these are the result of adopting new widgets and features available in Libadwaita 1.4. The new Adw.NavigationSplitView widget looks cleaner, and the Adw.Breakpointremoves the need for ugly hacks that plagued adaptive GTK applications for years. I can attest that the migration effort is totally worth it.
In preparation for the next Flatpak release, I added support for the new –device=inputpermission. This new toggle option won’t be accessible until the Flatpak release happens and gets into users systems.
Moving on to quality of life improvements. This time I focused on not having to restart Flatseal or manually intervene when externals changes occur, e.g. installing or uninstalling applications or running flatpak-override from the terminal. As a bonus, it will now remember the last selected application and resume the selection later.
Regarding fixes, I improved the validations for text field permissions to detect prohibited characters and, as an extra step, improved the overall experience when handling with broken overrides files.
Moving forward, my priority is to focus on the back-end models in order to overcome known limitations, e.g. not being able to deny permissions globally, among other things.
I am happy to announce the release of Portfolio 1.0.0! This new release is the first step in the modernization process to GTK 4 and Libadwaita. It’s also a continuation to my efforts of bringing a minimalist file manager to the mobile Linux community, with a few important bug fixes.
As a starting point for the modernization process, this new version of Portfolio preserves the exact same design, in a GTK 4 flavor. A few reasons for that.
First, although I wish everyone was distributing applications using Flatpak, I want to reduce friction for the mobile Linux distributions, by sticking to currently available APIs. Second, I want to spend more time experimenting with newer Libadwaita widgets, specially with the ones from the upcoming 1.4 release, as these could require redesigning a few aspects of Portfolio’s graphical interface.
On the maintenance side of things, I fixed a major issue which prevented some files to be sent to the trash and another that prevented displaying progress while moving files, among other minor fixes. Porting widgets to Libadwaita fixed one annoying issue which prevented swapping back, so that’s a big free win.
Even before all of this work ever happened, I spent some time refactoring the project into smaller, more modular, pieces. This helped significantly to the porting process and it will ensure an easier maintenance move forward. So expect more refactors to come.
To celebrate Flatseal reaching 800,000 downloads on Flathub 🤯, a new release is out! Flatseal 2.0 comes with improved visuals powered by GTK 4 and Libadwaita and, with that, a few quality of life improvements and bug fixes.
Kudos to @natasria for the initial work on porting the user interface to GTK 4 and Libadwaita, and to @A6GibKm for helping with the reviews and making a lot of further improvements to that work.
As a result, the user interface looks cleaner and incorporates many of Libadwaita goodies like the mobile-friendly about-me dialog, among other things.
Also, this release includes a few quality of life improvements and bug fixes, e.g. typing to search for applications and a popover with suggestions for auto-completing XDG directories. See the full list here.
There are a few improvements and new features that didn’t make it to the release, e.g. incorporating even more Libadwaita widgets, new translations, and detecting when applications have been installed, removed or updated to allow users reload the applications list. So expect a follow-up release, shortly.
Last but never least, a big thanks to @rusty-snake for always keeping an eye on the issue tracker and answering people’s questions.
After a long hiatus, a new release of Portfolio is out 📱🤓. This new release comes with important bug fixes, small-detail additions and a few visual improvements.
In terms of visuals, by popular demand, the most notable change is the use of regular icons for the files browser view. It should be easier now to quickly catch what each file is about. Thanks to @AngelTomkins for the initial implementation, @Exalm for helping with the reviews, and to the GNOME design team for such lovely new icons.
Another addition is support for system-wide style management. This is specially useful now that desktops like GNOME provide quick toggle buttons to switch between dark and light modes. Thanks to @pabloyoyoista for the initial implementation.
One small-detail change to the properties view is the addition of file permissions. Plus, the properties view was broken down into three different sections to reduce the visual load, and labels can now be selected which is useful for copying locations or ellipsized values.
Moving on to bug fixes, two important changes landed. The first one solves an issue which prevented opening files with special characters 🤦. Thanks to @jwaataja for detecting and fixing this issue. The second one solves an issue with Portfolio not properly detecting mount points under some specific conditions. Thanks to mo2mo for reaching out and sharing his system details, so I could figure this out.
I am happy to announce a new release of Flatseal 🎉. This new release comes with the ability to review and modify global overrides, highlight changes made by users, follow system-level color schemes, support for more languages and a few bugs fixes.
Let’s start with bug fixes. Since Flatpak 1.12.4, removing filesystem permissions with modes in Flatseal caused Flatpak to warn people about the mode being included as part of the override. Justifiably, this confused many. With this release, it will no longer include these modes, e.g. :ro, when removing filesystem permissions.
Although Flatseal main distribution is Flatpak, there are people who prefer to install it from their regular package manager. So, I included a fix which handles the creation of the overrides directory. Under Flatpak, this scenario is handled by permissions themselves.
Moving on to new features, @A6GibKm added support for the new system-level color schemes recently added to GNOME. Plus, he streamlined both shortcuts and documentation windows behavior by making both modal.
The main feature I focused on for this release is the ability to review and modify global overrides, which is actually three features in one. Let me elaborate.
Currently, when people look at a particular application permissions they are actually seeing the mix of two things: a) the original permissions that came with that application and b) the permissions changed by them. But there’s a third source of changes that wasn’t taken into account, and that is global overrides.
So, the first part was to make Flatseal aware of these global overrides. That means, when people look at an application permissions, these global overrides need to be accounted for and displayed. With this release, all sources of permissions changes are taken into account. Now, what you see is effectively and exactly what the application can or can’t do.
But this introduces a new problem or, better said, it exacerbates an existing one. It goes like this; people go to Flatseal, select an application, switch a few options and close it. Next day, they go back, select the same application and have absolutely no idea what changed the day before. This only gets worse when introducing global overrides to the mix.
Therefore, the second part was to extend Flatseal models to differentiate between original permissions and the two types of overrides, and to expose that information to the UI. Now, with this release, every permission changed by the user or globally is highlighted as shown above. This includes tooltips to let people know exactly where the change came from.
Lastly, the third part was to expose global overrides themselves to the UI, so people can review and modify these. I tried different approaches as for how to expose this but, finally, I let occam’s razor decide. I exposed global overrides as-if it was just another application, under an “All Applications” sticky item on the applications lists.
The benefit of this approach is that it’s quite easy to find, and even search, and it’s literally the same interface as for applications. But simplicity comes with a price.
If you’re a heavy user of Flatseal you probably noticed that it only allows to a) grant permissions that the applications don’t have or b) remove permissions that the applications have but, with the exception of filesystem permissions, c) it doesn’t allow to remove permissions that the applications don’t have.
Of course, most of the time, this wouldn’t even make sense for a particular application, but it is a limitation when thinking in terms of global overrides. So unfortunately, you can’t go and remove network access for all your applications in one click. At least not just yet.
After a few months of slow but steady progress, a new release of Portfolio is out 📱🤓. This new release comes with the ability to fully manage external devices, better feedback and responsiveness when copying big files to slow devices and many bugs fixes.
By popular demand, the main addition to Portfolio is the ability to fully manage external devices, this means; detecting external devices, unlocking encrypted devices, mounting and ejecting. For this release, I focused on getting the udisks2 integration right, but there’s still room for improvement on the UX department. A shout out to @ahoneybun for testing my two previous (and unsuccessful 😅) attempts to implement this.
Another noticeable improvement is that now copying operations display progress feedback on individual files. Previously, there wasn’t any, which led to the impression of “no feedback at all” when copying big files.
A related improvement is that copying operations now do a better job displaying the real progress, specially when copying files to slow external devices. No more suspiciously fast copying operations, which later turn into several minutes of undetermined wait time when ejecting these devices.
On the bug fixing department, hidden Trash folders are no longer created on external devices until they’re really needed, send to Trash button won’t show on devices with no Trash folder, Portfolio no longer crashes on the Sway tiling compositor, broken symlinks are now handled properly and the same file size unit is used consistently through all the application.
Moving forward, for the short term, I want to improve the external devices management UX and give these beautiful GNOME 42 folder icons a try 🤩. For the long term, I would love to port this application to GTK4 and Libadwaita.
A new Flatseal release is out 🥳🎉, and it comes with subtle visual improvements, a few bugs fixes, one more permission and a big quality of life improvement.
Starting with the visuals, @BrainBlasted replaced the custom widgets, used in the applications list, for proper libhandy’s widgets. Plus, he fixed a small styling detail to make applications icons look sharper!
On the permissions side of things, @Arxcis added support for the per-app-dev-shm permission, which was added to Flatpak a few releases ago. Also, I extended the Other files subsection to allow negated filesystem overrides, e.g. !home.
Moving on to quality of life improvements, I took the time to make the UI fully usable with keyboard input. For some of us, who prefer the keyboard, this makes the UI faster to navigate. For other people, it makes Flatseal accessible for the first time. Thanks to @sophie-h for reminding me of this 🙌
On the bug fixing front, @Arxcis fixed an issue that prevented users from overriding originally-negated permissions, and I fixed a couple more that caused undefined values to appear in override files. Although these were very rare, both issues were present since the original version of Flatseal.
Additionally, by popular demand, applications are now sorted by the application’s name 😅
The last couple of months have been particularly busy:
A few more releases down the road, the portal permissions support in Flatseal has finally matured. I took the opportunity to fix a crash in Flatpak’s permission store and to complete its permissions API, to pave the way for existing and future Flatseal-like front ends.
I took a short break to take care of my twenty five Sugar applications. Released a new version of the BaseApp, and updated every application to the latest upstream release and GNOME runtime.
On a personal note, I have been mentoring some brilliant interns at work, which is a refreshing experience after so many months of lockdown due to COVID.
What’s new in Portfolio?
On the visuals department, this new release brings a refreshed icon by @jimmac, which looks fantastic and takes it closer to the modern art style in GNOME.
Regarding features, well, there’s quite a lot. The most noticeable one is the Trash folder.
One of my goals for Portfolio is that, for the little it does, it should just work™. It shouldn’t matter what the users environment might be or how it’s being distributed. This imposes some technical challenges and, I imagine, is one of the reasons why a few file managers available on Flathub don’t provide feature parity with their non-flatpak versions.
Because of this, I prototyped different Trash folder implementations. Initially, I went for the right way™ and simply relied on the gvfsd. Sadly, there were a few issues with the sandbox interaction that prevented me from fulfilling my goal. Therefore, I stuck to my own implementation of freedesktop’s Trash spec. I must admit though, that I really enjoy reading these specs for Portfolio.
But there’s more!
A common issue among users, of the Flatpak version, is that they can’t see the real root directory. This is understandably confusing. Therefore, Portfolio now includes a Host device shortcut, as a best-effort attempt to mitigate this.
If you have been using Portfolio on devices with slow storage, you have probably seen that loading screen a few times when opening folders. I will eventually get around to something more elaborated but, for the time being, I reduced these load times with a bit of cache.
Among other improvements, there are now proper notifications when removing devices, filtering and sorting options will persist between sessions, and the files view will restore its scroll position to the previous directory when navigating back.
As for the bugs, kudos to @craftyguy for fixing a couple ones that prevented Portfolio to run on Postmarket OS.