Having used both I can say that PyGame provides much more out of the box but that this is not just a pro but also a con. For example in pygame there is a concept of “sprite” that has movement and you can tell it move left, move right etc. In Ebiten it surprised me to find that there is no such thing but it’s nice for two reasons:
implementing movement is trivial and maybe you don’t want your sprite to move like that, e.g. my first game with Ebiten had moons orbiting, not moving left-right etc.
Ebiten is much simpler to understand
When I was using PyGame I’d say I spent roughly 80% of the time reading the docs and trying to understand how to use correctly what is already there and only 20% working on the game, whereas with Ebiten it was the other way around, 80% of time programming my game.
And then my last point for Ebiten is that it makes it easy for you to build a single binary that you can ship to any popular platform. Ironically just yesterday I closed the last outstanding issue on my awful PyGame game that has been open for 3 years: To bundle the game into a runnable .exe file, I failed, it was too hard for me, but with an Ebiten game, Go’s build tools do the job for you.
Maybe a bit of a long, opinionated rant but I wanted to share the experience:
PyGame makes it easy to get into gamedev if you have zero experience because its framework provides rich existing general features for a game but don’t expect others to be able to play your game (if everyone in your class is already using Python and have it installed then this is not an issue)
Ebiten is by design simple to the core, so easy to understand, it is less a framework and more a strong library, you may have to implement some of details yourself but if you’re already familiar with Go programming then this could be fun and not so challenging, and it will be easier to share your game with others as .exe or for web etc
There are surely many more pros/cons for both, but these are the two that stood out the most for me. I don’t regret using PyGame for my first competition entry, it was a good introduction, but I won’t use it again.
On the 1st of December Tristan, Rowan and I released the first version of Cr1ckt, a tricky platformer where you need to jump to avoid water and get to the fruit. It’s our submission for the GitHub Game Off 2021 game jam, an annual challenge to make a game based on a secret theme within the month of November. The theme this year is “BUG” so apart from playing as a cricket it also has some fun, intentional bugs.
It’s got downloads for major desktop platforms Windows, Linux & Mac, as well as Android. They’re quite small so you should be able to download and play quite fast. You can get the downloads or play online in your browser on the game page at sinisterstuf.itch.io/cr1ckt.
When I attached our children’s swing to the ground there was still a significant piece of sharp-ish threaded metal sticking out above the bolt head and I was worried about them falling on it. Grinding the end off might still leave some sharp parts, so I thought it safer to print plastic covers for them.
There’s this fantastic device we have at home that I’m fairly sure is for giving back rubs, or maybe massages in general, like on your legs or something. I’ve tried it a few times but mostly the kids play with it. However it bothers me that there’s holes in it where the little knobs are supposed to be, so it doesn’t roll properly. I think the kids pulled them out, but maybe Continue reading →
This year was my first time participating in the online Hacktoberfest event.
I often use code from GitHub and occasionally publish my own projects there but I realised I rarely contribute to other people’s code. Hearing people talking about the event on the Ladybug Podcast, I was inspired to make a small pull request. The boost I got from something so insignificant being merged lead me to look through my favourite projects’ issue lists to see if there was a bug I could fix or a missing feature I could implement.
Yesterday I found a typo in a pull request description while browsing another team’s project which I stumbled upon. I mentioned it to the author but it turned out that that part of the text came from the repository’s pull request template, which means every pull request will have this amusing but irritating mistake. I sent them a pull request, modifying the template, to fix the mistake at the source and avoid it in future, and thought that would be the end of it.
It turns out that template was written once and then copied across to new repos, which means this typo actually exists in almost all the pull requests in all of that team’s projects. Well that escalated quickly. This is the point where the average person probably says “OK whatever, it’s not worth it for something so small, there are too many repos, it’s just a small typo, never mind” and stop. A very determined person might actually start opening browser tabs and psyching themselves up to do pull requests. I open my terminal emulator and start writing a for loop. Continue reading →
I’ve decided to give Wakatime a second try. It’s a tool that tracks the time you spend programming on different projects by integrating into your IDE. This works well for typical development work where you open your IDE in the morning and type code in it, do commits with it, and everything else related to the project and Wakatime will track that.
I don’t work like that though, so I had two issues with it last time, both resulting in a lower reported time spent working:
I spent most of the day working on different remote servers and it would be a hassle to set it up in the text editor on each of them and it would undoubtedly cause slowdown on the older servers
This time it’s different because nowadays I virtualise most of the services I work with, using Docker on my local machine, and I’m hoping that using the Wakatime Z Shell integration will give a better record of time spent working on a project. Continue reading →
How and why I normalised my Go paths and personal/local home paths.
Like many people, I have my own scripts and stuff in a bin directory in my home directory. Actually it’s a symlink to ~/.local/bin because I saw there was a ~/.local/share which some programs use to store user-specific things and I wanted to be consistent.
Since I use a lot of split windows in Vim, for example when exploring the git log or editing closely related files, a pattern I noticed is I often want to make one of the smaller windows full screen momentarily so I can read more at once without scrolling and then close it when I’m done. I made a really simple mapping to simulate this “full screen” idea:
:nnoremap <Leader>f :tabe %<CR>
This opens the current window’s buffer in a new tab (fake full screen 😁) and when I close it I’m back to tab one with my split windows.
To demonstrate, here’s a gif in which I inspect the git blame for a file, open a patch and then open it “full screen” in a new tab:
Vim fake fullscreen demo gif
Browsing the git log isn’t the best example because fugitive’s blame window already has an O mapping which opens the patch in a tab instead of a split and the necessity for this would be clearer with bigger files like those I edit at work.
This is one of the few things I use tabs for since I’m mostly jumping through buffers. Hopefully it’s useful for you too!