Currently working as coding teacher/author. I have a couple of decades experience as a software engineer and want to return to working on larger projects. Previously I’ve been an indie game dev, freelance app developer, academic. I’m very good at making things myself but I’m not so good at deciding what to make and doing the other parts of a startup like sales and marketing, so I’m looking to work for someone else.
Currently interested in Rust and Kotlin but far more interested in the people being right then the tech stack being right.
I have made: PC games, desktop applications, Android games/apps, iOS games/apps, back-end servers, network protocols, educational books and videos.
Currently I am teaching and working on education-related projects but I could take on a development project for up to 12 months if it was interesting and provided opportunity for me learn something new, e.g. Rust.
Currently it’s TUI, but will add GUI eventually. It’s fun to have a protocol small enough you can implement it yourself, but I currently have a weird bug where some Gemini servers work and others don’t because they don’t seem to follow the SSL spec.
When I started developing RetroWar[1], I found Unity quite a disappointment, and so I developed my own custom engine in Kotlin. It works very well, but it took several years.
Recently I tried Godot because I was looking for something simple I could teach to kids[2], and I was amazed how easy it makes game creation. I made these games with no experience in just a couple of days!
GDscript is great. It's similar enough to Python that kids who know Python won't notice much difference, and it actually simplifies things for beginners, e.g. you can use objects without the need to define classes because they are created automatically when you create a script.
Godot is still a little rough around the edges, e.g. not everything has keyboard shortcuts, sometimes it crashes, some of the built in tools like map editor are very fiddly to use. But it's open source so I'm sure they will be fixed eventually (and if they aren't I can always do it myself.) The only major issue I can see for the future of Godot is the lack of exporters for Xbox, Playstation and Switch.
*lack of public exporters. Because of the NDAs around shipping for these platforms, no one can "advertise" that they have the exporters, but the truth is that there are consultants/gamedev shops who have done this work for all of the current platforms. You just have to get in touch with them via the community.
Sure you can hire someone to do the port - they do advertise it on that very page.
But there is another open source game library, Monogame, that distributes their code for free for consoles. You just have to vertify that you are have signed the NDA before you get access to the code. They advertise this. So there is no reason that Godot couldn't do the same if they wanted to open that code.
A lot of assumptions going on in this comment. You should actually consider testing some of them to see if they're true or just mistakes on your part.
Putting that aside: developers who do this kind of (difficult, tedious and thankless) work are entitled to ask compensation for their effort, on top of everything else they do for free.
Yes people are entitled to sell proprietary forks of free software - it's a non-copy left license so perfectly legal. However it puts Godot in a poor position relative to competitors. If you want a free console game engine you could use Monogame. If you want a non-free console game engine then you could use Unity or Unreal and you would have the advantage that you know up-front what it will cost and you know that it will be well supported by well-known developers throughout the lifetime of the console. Godot is a very compelling choice for PC and mobile, but the current situation of “there is console support but it’s a secret so we can’t tell you who makes it, how much it costs and how long it will be supported in future” makes it very difficult to recommend Godot over those alternatives to anyone developing console titles.
The goal isn't education in how to make games or use a particular library. The goal is education in coding, and games are just the hook to maintain interest. Pygame Zero hides the bits we don't care about so they don't distract from the bits we do. Middleschool students might cope with full Pygame, but when you're teaching 8-year-olds who can't type quickly, getting a sprite on the screen without any boilerplate is an advantage in maintaining their attention.
Another advantage of Pygame Zero is that the author was involved in the creation of Mu, and so Mu comes with Pygame Zero pre-installed. Having to install Pygame via pip would be a challenge for many kids.
Anyway, Pygame Zero includes all of Pygame so you're free to introduce as much of it as you like.
one thought: after having read your introduction for the teachers, i wonder why you did not "sort it" the other way round: first the hands on and the tutorials and then the theory...
we suggest the kids to first do the pong game in scratch (we have a booklet with step by step instructions) and then use the set of cards (in order) to do the same.
we try to avoid that they just copy the snippets line by line, without thinking at what they are doing...
i will now give them a link to your book when they want to learn about python!
https://loughton.me.uk/2022/01/01/assembly-language.html