I'm quite proud I managed to design, build, publish, and actually finish the whole thing.
I also enjoyed most of the road to get here.
Why is it then that I say I "hate" game development?
About "Hating Game Development"
Again: I loved developing a game.
It's just that I hated game development.
There's a subtle but important difference between the two.
My own guess is that the reason has to with the fact that:
I did have a lot of web development experience.
I had zero game development experience to speak of;
This is an extremely nasty combination, or so I presume.
It puts me top-right in the following table, extended with my take on the other three possibilities:
Little WEB Dev Experience
Lots of WEB Dev Experience
Little GAME Dev Experience
🤩 Game Dev is perfect for you! Most tutorials in Game Development are aimed at your skill level. You'll be amazed at how fast you'll be able to build stuff. And the "elbow grease" needed to get a game completed will feel totally normal. You won't miss any of the stuff that I felt was lacking.
😭 This was my corner. Nearly none of the tools and techniques you know and love from creating web API's or front-ends will be available. You'll be struggling to find game dev information on proper CI/CD, automated testing, inversion of control, or tooling and architecture in general.
Lots of GAME Dev Experience
🧙♂️ You're likely a wizard! You've honed your skill and learned tricks from the industry. Or you may work for a big(ger) studio with in-house tooling to compensate for the lack of industry-wide public knowledge. My blogpost might seem weirdly incorrect or besides-the-point.
🦄 You're the one I need(ed)! You can tell me why this devlog is wrong, tell me that there are tools that I just wasn't able to find. Bridge the gap between the wonderful things from Web Development and their equivalents in Game Development.
In terms of the psychological "Four stages of competence"↗
(related to the Dunning-Kruger effect) I feel like I am "Consciously Incompetent" as far as Game Development is concerned.
Because I'm still incompetent, I might very well be wrong.
But I'd claim:
Game Development seriously lacks broadly available proper practices and tooling.
Here are come examples of what I found lacking:
Continuous Integration and Deployment knowledge and tooling is nearly non-existent.
Automated testing is hardly talked about.
Flow of Data seems to be an afterthought, there's nearly nothing to be found about Unidirectional Data Flow or similar patterns.
Architecture and Best Practices are seemingly left to each individual developer, with only adhoc advice here and there.
Now consider .NET Core, Laravel, SvelteKit, NextJS, or a dozen other web development frameworks.
Each of those has amazing and extensive documentation and great starter templates, to create robust and future proof code.
Comparing that to the PhaserJS and Godot situation, I found things seriously lacking.
I hear similar stories from friends and colleagues working with Unity or Unreal Engine.
Mind you, there is some information on the above topics.
And I appreciate the creators of that content all the more!
But relative to web development eco-systems, information is either hard to find or nonexistent.
Especially if you're just starting out.
About the Godot engine
The above section spoke in broad terms about Game Development.
I purposely generalized from my experience with Godot (and PhaserJS).
And that feels warranted.
Based on conversations with folks who did their first work in Unity or Unreal, I reckon it's roughly the same deal there.
There are a few specific things to say about Godot though.
However, it's weird to "complain" about a free and Open Source tool.
So let me start by saying that I'm very grateful for the hard work put into Godot.
I even put my money where my mouth was.
And overall it was actually a pretty decent experience to build something in Godot.
Having said that, if you're a web developer (like me) coming to game development: be warned!
There are several things with Godot that you'll likely also find awkward:
UI building is powerful but verbose, and frustrating compared to doing HTML and CSS.
Debugging is hard, and you'll miss the tools you have in web development.
Open Source interactions can be harsh, at least for the core Godot stuff.
This is in addition to the general Game Development gripes I mentioned earlier.
Overall however, I think Godot is great for developing your first game.
If you're aware of the gotchas, there are also many things to like about Godot.
It's easy to pick up, and has a good visual editor.
You can compile for several platforms, and the tool is free and open source.
The documentation↗ is quite good and comprehensive.
And the proof is in the end result: it enabled me to build a full game in a few weeks!
So let's talk a little bit about that "proof", shall we?
If you're a Web Developer going into Game Development with Godot,
you might also find the Pincrediball Source↗ a useful resource.
Disclaimer: I am by no means a Godot expert.
However, I did try to create as clean and robust code as I could with the tools available.
If you're going to look through the code, I particularly would recommend looking at:
My poor-man's implementation of Unidirectional Data Flow (e.g. in the Scoring "store"↗.
It has to rely on the singleton pattern, public functions for actions, and events instead of selectors.
But it gets the job done: things are highly cohesive but not tightly coupled.
It prevents a ton of data being passed around and events bubbling through the inheritance tree.
Being forced by Godot to rely on inheritance over composition,
I still manage to apply some Inversion of Control (e.g. in the Base Pinball Component↗).
The general Folder Structure↗
has been carefully chosen, despite the lack of good guidance available online.
It should work well for small and medium sized games; it won't hold up for larger projects though.
But I also recommend you only take this as inspiration, and a way to "not feel alone" as a web developer in the Godot world.
Do not take it as a set of best practices or recommendations... remember:
I am consciously incompetent.
Perhaps this post got you interested, and you'd like to cherry pick some further reading.
For that case I'll share my Top 5 Pincrediball Devlog Posts, the most interesting ones for the general public:
But of course if you feel like it you can also scan or read through the entire devlog since day 1.
Time for some closing remarks about Game Development, and about the project.
I'm happy I took a stab at game development.
I'm proud that I finished an entire game, and got it published on Itch.io and on Steam.
It was fun, and I'll likely do something similar again!
And to fully close of, I'll just repeat the post title:
Game development sucks. But developing games rocks!
Day 105: Releasing on Steam
Jeroen, July 15, 2023
My last post was "Day 47" (March 31st).
Since then 58 days have past.
My sabbatical was over and I've been back to work and other hobbies.
However, I did still spend a ton of time on Pincrediball over those weeks.
Hours needed to get onto Steam
Nearly all of that work went towards getting the game onto Steam.
I was hoping it was only a little more work than publishing on Itch.io.
Boy, was I wrong!!
In sunk an estimated 361 hours of work into the full game and release on Itch.io.
In addition to that I estimate publishing on Steam cost about another 100 hours or so.
That includes roughly 12 hours of work on creating and coding the Steam Achievements.
There's two factors to all this.
First, the back office for partners at Steam is... outdated, and not the most user friendly web app in the world.
Yes, that's an understatement.
Second, there is just a ton of forms to complete.
Let's dive into that, shall we?!
Stuff needed to release on Steam
Officially the Steam Partner features are under "Confidential".
I'm not actually allowed to share the actual pages of the partner dashboards.
But I surely I can get away with giving a broad overview of what's needed to release a game on Steam.
Or at least what was needed for Pincrediball.
So, without further ado...
Here's a grand overview of all the things I needed to do to release on Steam:
Store and Library settings
Name, Developer, Publisher, etc.
External links (about 8 options)
Social Media Links (4 hardcoded options)
Search Keywords, comma-separated
Supported Platforms (3 OS'es, both Minimum and Recommended System Requirements)
Supported Languages (Interface, Audio, Subtitles)
Number of players supported (a dozen or so checkboxes)
Supported Features (Achievements, Stats, Steam Cloud, etc.; about 16 checkboxes)
Genres (Primary and Secondary)
Tags (at least 5, but up to 20)
Controller support (radio button options)
DRM Info (if any), 3rd Party Accounts info
Legal lines (rich text)
Support Contact Info
About This Game (rich text, a few paragraphs at least)
Short Description (one paragraph)
Reviews and Awards from external parties
"Why" section, rich text, at least one paragraph
"How long" section, rich text, at least one paragraph
"Full Version" section, rich text, at least one paragraph
"Current State" section, rich text, at least one paragraph
"Pricing Info" section, rich text, at least one paragraph
"Community feedback" section, rich text, at least one paragraph
Store assets (5 exactly sized images, plus at least 5 screenshots)
Library assets (4 exactly sized images)
Broadcast assets (1 exactly sized image)
Full HD H.264 video upload
Name (yes, again)
Supported Operating Systems (yes, again)
Release date (yes, again)
Depots (basically ZIP's with your game files, one per OS in my case)
Branch and Builds with Depots to be included
Packages that are linked to Depots
Windows launch options
macOS launch options
Linux and Steam Deck launch options
Client Images (icon)
Stats & Achievements
Stats (11 total for Pincrediball)
Achievements (9 total for Pincrediball) with two images for each one
Official Community Group with custom icon image
Custom request for beta keys
Before even gettings started you need to:
Fill out all Personal and Company details
Complete an 8 step Tax form with personal identification
And finally, note a few special things:
Reserve time to handle all feedback from the review process of your store listing
You need to pay a "Steam Direct Fee" of $100 to create a new game at all on Steam (refunded if you exceed a certain amount of sales)
Publishing a game is another 2-5 business days review process
Reserve time to build scripts to publish the Depots using the Steam SDK
Wew, that's a lot of stuff, isn't it?
And there's something else as well...
You actually need to write code in your game to support Steam.
There's three things I wanted to do when I started integration:
Statistics per player (for potential Leaderboards)
Integrating the Steam SDK in your game would be a rather complicated programming task.
Fortunately there's GodotSteam↗:
an open source project to make it easy to integrate Steam into your Godot game.
And it was a breeze to use!
I extended my "Giving back" and donated $9,- (small bits help too, right?) to the project's core maintainer.
I was extremely motivated to get my game onto Steam.
Good thing too, because it was no joke to get through all that's needed.
As a consumer, I find Steam to be a great platform.
The quality of games is of course a lot higher than on Itch.io.
In part, that's probably due to the heavy weight process behind it.
It's baffling how bad the UX of their backoffice is at times, but I appreciate how hard it is to maintain a service like Steam.
Linux and Windows are supported, both in-browser and (higher quality) downloads for desktop.
Android devices... are not officially supported, but if you try real hard you might be able to complete the tutorial.
Sorry Apple users.... web builds are broken in Godot for all Apple platforms, and an Apple desktop build will take me some more time.
I'm extremely sad about that, but not much I can do at this immediate point.
Oh, and there's a launch trailer too (opens in fresh tab):
Many thanks by the way to everyone who supported the project.
My friends on Slack and otherwise, testing and giving feedback and whatnot.
My colleagues and social media buddies, for the encouragement and interaction.
The community and open source authors making the tools I used.
And above all my wife, for, well... everything!
Time to prep a launch-moment-photo to be inserted here:
And after that, I say: thank you.
And: happy gaming!!
I'm off for some weekend before I need to go back to real life and real work.
Day 46: Home stretch! ("Final to-do's")
Jeroen, March 30, 2023
Let's recap the project goal one last time:
The goal would be to create one small game, end to end, nearly every part of it created by myself.
And earn at least one euro with it, which can also be my own 1 euro:
I just want to see what it takes to getting to publishing a game.
Today, I reached that milestone!
Mind you, I paid myself that $1 after I successfully completed a playthrough in the browser.
Here is the html5 version of the game running on itch:
The game store page is still in draft and not publicly available.
But I could make it public right now and call it good.
So, what's holding me back?
Well, about 25 different things.
Here's the subset I really hope to fix on the last day of the project.
Plan for The Final Day
MacOS, iOS, and iPadOS all fail to load or crash the html5 version of the game.
Regardless of the browser used.
I'm not even sure if this is fixable, because I've already spotted several Godot GitHub issues around this subject
It would be fantastic to have a desktop build for macOS as an alternative.
However, it's not trivial to build and sign apps for macOS when you don't have an Apple device around.
Plus it's also not easy to test then.
So, at the very least I then need to post a very good warning on the itch page.
Which is doable enough, even though it's a bit sad.
Last-minute game changes
There's two important things I really want to add:
some extra introductory hints
a final polish of the physics variables
This can also easily become a time sink, especially the second one.
Perhaps I should save it for last?
Either way, it's doable to do something here.
Steam Store Page
There's a ton of things to fill out for Steam.
I've made a start, but there's just so many details to fill out.
And even then Steam suggests it'll take days to process and review things.
So this one seems less doable, unfortunately.
Which is sad, but not a showstopper.
Screenshots and Trailer
A store page isn't much without some good content.
Screenshots should be easy to make.
A trailer can easily become a time sink, despite having a bunch of (hobbyist level) video editing experience
Probably I should just start with something, anything really, that's good enough.
That's doable too then, I reckon.
Publish the itch.io page
The final thing to do will be to publish it and making it publicly available.
Nice to have would be to add a Desktop build for Windows and Linux (see above why I'm leaving out macOS for the moment).
I will start with a "soft launch", by only announcing it on the devlog and to friends and via socials.
Any feedback or other final polish I might apply after my sabbatical.
Just to have a slightly better "real Demo launch", which I'd hope to share a little broader (though my reach is not huge).
Okay, an even more final thing would be to write a final devlog to celebrate the "soft launch".
Friday's post should serve as a little bit of closure, given that my day job starts again on Monday as well.
"What lies beyond?", you'd ask?
Well, there's a bunch of ideas.
I will only do the bare minimum to (feel good about it and) announce the game a little bit more broadly.
After that I need a good long break from (this) game('s) development.
If by some miracle (which I hardly expect) the game racks up a bunch of "wish listings", I might actually complete a full game.
But more likely reviews will be "Mixed" at best, and low in quantity.
And that's totally fine too!
Because I enjoyed this sabbatical project a ton.
And that's what counts the most.
But first, let's get ready for a Final Day in this "Home stretch!".
Day 45: Home stretch! ("Statistics!")
Jeroen, March 29, 2023
We're in the home stretch this week!
Today's post is all about project statistics!
The meta stuff, to build some tension towards the actual beta release!
I've not kept exact track of things, but I think I can guesstimate quite well where I spent my time.
Here's a breakdown of the hours I put into this project:
Or in a more accessible table:
Learning (Svelte + Sveltekit)
Game (art and design)
Game (programming, Godot)
Game (programming, Phaser)
Game (other stuff)
Meta (socials, store pages, etc.)
Learning (Svelte + Sveltekit)
Game (art and design)
Game (programming, Godot)
Game (programming, Phaser)
Game (other stuff)
Meta (socials, store pages, etc.)
Obviously this contains a forecast for this week as well, and assumes I'll actually finish it this week.
An indication of my confidence levels: roughly 4 out of very 5 cells is probably ± 20% accurate.
The overall estimates per week as well as the grand total are near certainly ± 20% accurate as well.
Originally I had estimated I'd be able to do this project within 6 (instead of 7) weeks.
Had I chosen Godot initially I would've probably made that.
But I won't complain: I enjoyed myself nearly all the way through, and am pretty happy with this outcome!
Second, let's look at some code statistics.
Here's a quick export of the current (nearly complete) core game repository↗ code statistics:
Or in a more accessible table:
I'm actually quite relieved and happy that the lines of code for the game well exceeds the 1500 lines of markdown (plus 500 lines of svelte)
for the pincrediball.com repository↗.
Even though I'm still also proud of the extremely consistent blogging side of things!
Note that the above statistics do not include:
The prototypes (Godot nor Phaser prototypes)
The sample repositories I made to help myself and others
The code I wrote for forums and online Q&A
The code I threw away...
Back to the game
So, is that it then?
Will the above roughly be what entailed a fully featured beta-release, which will earn me at least 1 euro!?
Well, today I made the first full-featured release candidates.
It works well on Windows, can be made to work on the Web (to a degree), and even worked on Linux!
A good friend went above and beyond testing this release on Linux.
Feedback included a ton of DM's, a dozen or more screen recordings, and some initial feedback:
I'd like to be able to mirror/flip some components;
Some physics bugs occur where the ball lies still when it shouldn't;
The "Run Playbook" feature should be more discoverable;
Can we move and rotate things at ones, please? (Is that even possible?);
Bumper-walls don't communicate they only bump on one side;
Missing a "true" full screen mode (or borderless maximized);
But also some positive feedback, or positive words of encouragement!
And regardless of which it is, it made me smile.
Plus, it gave me a little extra energy for this home stretch!
Two days left...
Day 44: Home stretch! ("Giving back")
Jeroen, March 28, 2023
I'll be coding a bunch today, it's the home stretch after all.
I'm on schedule, but it's a tight schedule.
But that's not the topic of today's devlog...
As you might know or now realize: I'm not a game developer by trade.
Instead, I make a good living in web development.
Pincrediball has been an 8-week-vacation project.
And it's been made possible in part by other people who invest their free and own time in Open Source projects.
I could've spent my vacation in several other ways.
Prime candidates would've been:
watching series all day (roughly 15 euro's per months); or
playing a few AAA games (20ish euro's a pop at a discount); or
reading all the books I still have in queue (50 euro's worth); or
take an intensive Spanish course (100 euro's, I'd reckon).
So I figured I donate some of that "saved" money to the Open Source projects that made Pincrediball possible.
Too many options to choose from, but something's better than nothing.
Some rationales for choosing these projects, with links if you want to donate too:
(€40,-) because it is the main Pincrediball engine.
($30,-) because I want to see it improve!
($20,-) because it powers the website and was a joy to work with.
($20,-) which I picked from npm fund, and which I probably often rely on.
($20,-) which I picked from npm fund, because it sparks joy!
No heavy analysis (as I normally do with everything), just picked a few logical ones and went with it.
That's really all for the devlog today.
No further Pincrediball content at all.
I'll be posting this one in a second, grab some more coffee, and get coding.
Whatever gets added will be rolled up into a future devlog!
Catch you in the next one.
Day 43: Home stretch! (Part 1 of 5)
Jeroen, March 27, 2023
Got up at 07:00 for some spinning and Last of Us, followed by a quick shower.
At 08:00 I was ready for the first day of the final project week.
A good start surely leads to a good day?
And a good day it was!
Things are coming together quite nicely, and today I added plenty of small and big features:
✔ Saving and loading the player's Progress
✔ Saving and loading Options
✔ Progress overview improvements
✔ Revamped and improved toolbox
✔ Navigating the various stages (still called "levels" at the moment)
✔ Animations to help with navigation
✔ Less score disabling, now only when needed
✔ Drag & Drop improvements
✔ Better descriptions for toolbox items
✔ Medal update improvements
✔ Extra sounds
And in general level progression is now working.
Which means you can now actually finish a playthrough.
I do still need to add a celebration screen for that, amongst other things.
Here's the current state of things:
Several of the above mentioned features in action right there.
Showcase of the animations will have to wait, because today was a long day.
I will showcase one extra still though:
This are the scores my primary beta tester (thank you, dear! <3) in her first full playthrough!
One for the books.
Four days left
So that is one day down, four to go this week.
Tomorrow we'll round out something that's "releasable".
That should leave three days to actually release some thing, and round up otherwise.
Maybe I'll have a spare day of vacation left on Friday?
Nah, who am I kidding?
I'll probably just add more features, content, or polish.
Day 42: Weekend Bonus (XXL devlog)
Jeroen, March 26, 2023
It's awesome when people read my posts online.
But most of my motivation comes from the writing itself.
Writing posts will:
Help me cement and remember learnings;
Straighten out my thoughts;
Make plans or brainstorm ideas;
Let me vent a little when needed;
The fact that people might read my posts helps me aim for some level of quality.
The fact that my motivation comes from within in turn helps restrain the perfectionism.
Today's "bonus" post is about the first bullet.
It's about cementing learnings about game dev tricks I didn't know about before.
In no particular order, it's a list of techniques that have (at first sight!) no big cross-over to web development (or do they!?).
⚠ As such, it's a rather lengthy post! I won't blame you for sitting this one out.
Game Development Specifics
First, let's start with things largely specific to game development.
When playing AAA games a loading screen might call out "Pre-processing shaders" or something similar.
So I knew there was something called "shaders".
But since this week I know what they actually are.
And how to make (a basic) one.
In my understanding, a shader is (usually) a short program written in a specific shader-language.
It's used to manipulate pixels and other low-level graphics objects just before they reach the screen.
You can layer and combine them with other shaders, on top of an the original textures and rendered pixels.
Yes, that's a gross and possibly imperfect oversimplification!
But I think I'll defer to the Wikipedia article↗ and its references for a better overview.
This does what it says on the tin: it generates particles!
Think "fireworks" and "confetti".
A good friend tipped me to try and add some more things for the "feel" of the game.
Which is a great tip, and a good incentive to learn about particles.
So now there's now a little celebratory fireworks for achieving a medal score:
In the background you can also see the "Stars" shader in action.
Godot does animations with an AnimationPlayer (and a Tree for complex stuff) node.
My experience with Non-Linear Editing tools for video came in handy here.
Basically you create a little timeline, add a "track" per thing to animate.
Then tell it the "Key Frame" states, and Godot animates between those states.
I only used it for simple fade in- and out animations so far, for example for the splash screen.
But it can do far more complex stuff, prime example being animation of physics objects (e.g. a "walking" animation).
Which (I fear) can easily slurp up a lot of time.
By the way, many things you see "animate" (move) in the game currently are not animations.
They fall under a different category, up next.
The tip to add audio sooner rather than later was gold.
Because with some generated and royalty-free sounds you can go a long way.
And Godot makes it rather easy to just have code play a sound or two at the right time.
Apart from the very basics, I have not touched any of the advanced stuff.
I know there's things like spatial audio, sound effects, and many more.
But I left those out of scope for this project.
So not much more to say here.
In a game engine like Godot, two things go hand in hand: graphics and physics.
Any game object with physics or collision properties takes part in a simulated 2D or 3D world.
A tiny "delta" of a few milliseconds is taken each "step" to estimate the next state of the world.
After that the graphics are updated to reflect that.
There's a million things to properly arrange and set to create interesting games.
Physics properties, such as gravity, friction, mass, inertia, torque, and many more.
Collision details, like the collision shapes of things as well as layers (which things can collide with each other)
It's incredibly easy to get started.
And it's incredibly tough to debug and tweak.
Web Development Overlap
Second, there are a few things that have overlap with building web apps.
Things you also need to master (at least a bit) and work out in a game.
A quick list.
For Godot you can choose C#, a language I know well.
But nearly all examples and knowledge online uses GDScript, so I stuck with that.
GDScript is Godot's Python-like scripting language.
Easy enough to pick up if you know a little Python or other languages.
But certainly rough around the edges, and annoying to use at times.
This feels like a really underdeveloped area of (Godot) game development.
I know big game studios must be using the techniques we know from other fields.
But beginners will find tutorials suggesting spreadsheets, exports to CSV, and some duck typing after reading the data.
And it doesn't help that the main language (GDScript) doesn't know if it wants to be truly Object-Oriented, or not.
With data-flow, it feels like only 1% of generic software development practices reach game development.
Many important patterns -with the exception of State Machines!- are nearly absent in tutorials and documentation.
Again, surely big studios and experts have solutions, right?
But beginners are left creating spaghetti and tightly coupled singletons.
And I found myself somewhere in between, implementing poor-man's versions of uni-directional data flows and message buses.
Powerful and workable on one hand.
On the other hand, it reminds me of FrontPage, DreamWeaver, Java Swing, WinForms, as well as the tables-for-layout era of web development.
A pain to use.
Worth a devlog (essentially a long rant) on its own.
But having something like this at all was great; not sure how far I'd gotten without it.
So mixed feelings about this in the end.
The main tool is the Godot editor.
The visual designer was extremely helpful as a beginner.
Frustrating at times (looking at you, Undo Feature!), but a smooth experience for the most part.
The script editor, (nonexistent) refactoring tools, file system-based project structure, and overall editing experience...
Well, let's say we're spoiled as web developers.
The experience with Godot is "okay", but not nearly as good as when doing web development.
You can use external editors and tooling (like VSCode or Visual Studio), but that felt firmly outside of a beginner's scope.
Okay, I guess I'm grateful we have something.
Break points mostly work.
Inspectors largely work, and there's always print statements, right?
Plus, shout out to the option to show collision shapes in a game: super helpful!
But it's absolutely no match for the debug tools we get in modern browsers.
Or the experience in -say- Visual Studio or JetBrains tooling.
Many times with Godot I found myself just going through and changing all properties of an object, until I hit the right one.
But quite possibly this one's on me, for not learning the tools properly before using them?
Basically the same as in web development.
It's great that most assets are text based files.
So git does the trick.
For larger games you probably need a better solution for binary assets such as art and sound?
But for small projects I think throwing them (neatly) in your repository works well enough.
Game Development made me investigate new tools and techniques.
Things I didn't know much about at all from web development.
I touched the basics of Shaders, Particles, Animations, Audio, and Physics.
And there are many more things to learn about as well.
A great experience to try my hand at these things!
Game Development also showed overlap with Web Development.
I often felt underwhelmed and disappointed here.
It still eludes me how to do proper architecture, data (flow), layout work, tooling, and debugging in Game Development.
But really, I expect this largely to be due to my own lack of research and learning.
I suppose this post has become a (technical) summary of the entire project.
Which is great, because that leaves one less thing to procrastinate with next week.
When I should really finish the project.
Fixes #14 (Drag and Drop)
Fixes #39 (Credits)
Fixes #38 (Options)
Fixes #36 (Splash screen)
Fixes #37 (Menu)
Fixes #21 (Menu music, which is just the game music but that's fine for now!)
See also #18 (Medals and Level progression, doing a little work for that already)
Followed by #46 (Drop leading to overlaps)
Followed by #47 (Rotation of components)
Quite satisfying, in many ways.
The PR itself was a hot mess of commits and different concerns being handled.
But in my defense I'll say that this is okay for a hobby project...
and it seems to be "The Way" for game development in general?
Anyways, let's end this week with a recap of where things stand.
And as you by now know, I prefer to show that with a quick video:
I got a good friend (who also happens to be a very good game developer) to play the current version.
Quality of the game(play) aside for a moment, I think the game felt quite playable already.
Looking at him poke about, tweaking the machine, just to see what will happen next, was rewarding for sure!
The "Current State" also includes that I'm at the eve of the final week of this project.
So that brings us to what's up next.
And heck, I'll be dropping anything which I don't absolutely need.
Either way, there's one week left in my mini-sabbatical.
And... this seems doable!
Mind you: "doable" in the sense that "it can be done", not "this will be easy".
I'm optimistic, not ignorant.
Also, what I (currently) still lack in game development skills, I think I make up for with persistence and commitment.
Put differently: building a high quality game will be for some other time,
finishing something is the name of the current game!
Let's see if I can make good on those claims next week?
Day 39: Dragging indeed...
Jeroen, March 23, 2023
Back to Drag & Drop today, indeed!
But only after a teensy tiny bit more side-work.
Game Structure Improvements
The menu screens and all that are just so satisfying.
Rounding the project out as an actual game.
If even of dubious quality.
First up, we have some proper options.
Styling CheckButtons in Godot is again an absolute pain, and not fun work at all.
But I'd learned my lesson and switched to TextureButtons within minutes:
It ain't much, but it was an honest hour's work!
And I'm sure you will believe me when I say that a working "Continue Game" option is equally glorious!?
Several things have been improved on the gameplay side as well:
✔ Scores now show the medals you achieve as you run a playbook
✔ Score targets are now data-driven, can be different per level
✔ Disabled scoring when running a "Stress Test" is now more clear
✔ Component unlocks has been prepared
✔ A "DEBUG" button allows you to skip to the last level and unlock all components
Just for something shiny to look at, here's all of that in action:
This also ain't much, but it was an honest day's work!
Yesterday I ended with a mention of the Alpha Release↗.
Guess today I can already even talk about a beta release.
Because if quality levels are negotiable, we can get to the fixed deadline and feature set sooner.
And looking at the Project Board↗ we're pretty close, actually.
And that's a good thing, because I have one day plus one week left.
So let's reach a good milestone tomorrow, shall we?!
Day 38: Productive Procrastination
Jeroen, March 22, 2023
I needed a "win" today.
So I took a break from Drag & Drop, hoping for a break in Godot gotchas as well.
Time for some "Productive Procrastination"!
I finalized the splash screen.
Not much to say or show about this.
But it does round out the game as a real game.
Although not even strictly necessary, I wanted to further "round out" Pincrediball with a proper menu.
So I built one today.
Let's enjoy the results before we "enjoy" the struggles:
Building this felt like I was teleported back to 1998.
That's when I was doing web layouts with tables.
We were building rounded corners on things with 3x3 tables and a background image tailored to each cell.
Anno 2023 Godot even has a dedicated control↗ for this.
Now that remark's a bit of a cheap shot, but even the intended controls are an absolute pain.
For sure a pain to learn, and so far also a pain to use.
So I gave up.
And just created some pixel-perfect buttons in Figma, once for each state.
And used a TextureButton.
The pinnacle of productive procrastination must be to create Credits for an unfinished game.
So that's what I did!
A tiny sneak peak (for full credits you'll need to play the actual game!):
Did I use all the tricks and hacks I had up my sleeve?
Am I proud of that?
My goals haven't changed.
The plan has, a little.
Today I let my partner try out the very first build of Pincrediball to leave my machine.
So technically the "alpha" release has been done and tested.
And it gave plenty of good feedback!
With that shortcut taken I can chug along towards the goals while sacrificing a little bit of quality.
Today an intermezzo was on the menu.
Tomorrow we're having the next course: more Godot (gotchas), until we have a fully playable game!
Day 37: Dropping the beat!
Jeroen, March 21, 2023
Yesterday I did the first bits of drag action.
Today dropping stuff in the right places has been implemented.
There's a metric ton of things left to smooth out, but let's start with the good parts.
Here's what you can currently do:
Super clunky, but you might get the basic idea?
So we achieved quite a bit today:
✔ Dragging "new" components from the toolbox on the left to the playing field
✔ Dragging "existing" components on the playfield around
✔ Crude animation (green flashing area) of the valid drop area
✔ Fallback for when trying to drop outside the valid area
In addition to some other unrelated improvements:
✔ Music and SFX toggle buttons
✔ Run Playbook option will now reset the balls
✔ Official "Stress Test" option to fire off 10 balls
✔ Score reset when running playbooks
✔ Score disabled during a "Stress Test"
But there's a ton left that's not (yet) working surrounding Drag & Drop functionality:
❌ Rotating certain components (bumper pills and wall corners) is missing
❌ Toolbox items should be usable only the allotted number of times, not infinitely
❌ You should not be able to move items during a play run
❌ Each Playbook should get a maximum number of seconds of runtime
❌ A "Stop Playbook" option is needed
❌ The "Toolbox" looks ugly and cramped, the layout needs work
And given the late hour when I write this probably a few more things.
The situation is... grimdireuglypromising... frustrating?
Godot and game development are a struggle (for a web developer by trade).
Around every corner there's a new gotcha waiting, it seems.
Perhaps my expectation of picking it up quickly given software development skills in other areas was unrealistic?
Either way I'm proud to be pressing on.
And proudly press on, I shall!
The quality might not be where I want it to be, but my goals I will reach!
Day 36: Dragging my feat...
Jeroen, March 20, 2023
Only two weeks left to finish my goals.
I've nicely stuck to the plan, and worked on Drag & Drop of Pinball components today.
Which brings me to say...
Doing drag and drop in Godot is not easy at all.
The very first steps are trivial.
Many tutorials describe how it's done.
But the edges... are rough.
And when I get distracted, I get distracted;
and I'll write an entire sample of how Drag & Drop could be done↗.
Guess I'd summarize it with a...
A satisfied "grumble" though, because I worked hard, I made progress, and learned new things.
But a "grumble" nonetheless, because tomorrow will be another full day of dragging this feature along.
Let's hope I'll get it done with one more day.
Or at the very least have fun while trying!
Day 33: Sound's good?
Jeroen, March 17, 2023
Although there's plenty of visual changes, today it's worth viewing progress with sound turned on (I muted it by default):
Are these the best sound effects and bits of background music in the world?
But it's something and that's where we've got to start!
Some other changes, next to music and sound:
The "Playbook" top left is now "real" and connected;
The "Run Playbook" button will reset score and flippers;
The "Your Score" part has been better aligned with "Score Targets";
Basics for level medals and level progression are in place.
Alpha release then?
So one notable thing is still missing: Drag & Drop↗.
Which actually is the core of the inner game loop.
Together with a few other bits it's the last thing missing for the alpha release.
Here's a snapshot of the Kanban Board↗:
I'm a bit sad that I didn't fully finish the alpha release this week.
If I'd pushed a bit harder this week, or would work a bunch over the weekend, I'd be able to finish it.
But I won't.
It's a hobby- and vacation project.
It's meant to be fun.
And there's plenty of time left.
So I'm off for the weekend, and will continue on Monday where I left off.
See you then!?
Day 32: Alpha Release nearby
Jeroen, March 16, 2023
We're steadily approaching a state where I'm ready to let some initial testers handle it.
This version of the game will be equivalent to what you get at the end of a "Design Sprint".
It requires a test script and an interviewer (to explain what's not finished and testable yet).
But still: a milestone!
Here's what currently happens when you play the game:
Notably the drag and drop features are missing so you can't actually play the game yet.
That will be the main issue↗ to tackle tomorrow!
With some further tweaks to some components, physics, and maybe placeholder sound effects, we should close in on the alpha release.
Now excuse me while I run off to play some Lego Star Wars or Cascadia, and recharge for the last day of this week tomorrow.
Day 31: Mixed feelings
Jeroen, March 15, 2023
I feel good about today's progress.
And I feel pretty salty about today's progress.
Mixed feelings, I'd say.
Building the foundations for the final app I encountered a super weird bug.
The ball would sometimes just jump off on its own.
And sometimes it would "sink" into a platform.
Here's what it the bug looks like (with some slow motion):
After hours of reading documentation, bisecting code, and debugging, I found the issue:
the texts and white rectangle to the left of the machine can sometimes cause the ball inside the machine to jump about.
So I felt pretty unhappy about lost time.
But Annoyance made room for feeling relieved when I found a good minimal way to reproduce it.
The tree involves combining GUI and Node2D nodes with physics
The presence of a white rectangle (!) next to the physics node, can affect if the physics inside that node in weird ways
However, I was informed in a one-sentence reply:
I think this is not a bug, but user error.
Ahh, the good old "stupid user" excuse.
Because the wording straight up blames the user for their problems.
They are in error.
This probably makes me extra salty because I've used that excuse myself in the past.
And I'm now ashamed I used to do so.
Another user is slightly more friendly, but still also says:
[This is not on] the engine [..., only] a wrong expectation [by you].
With a bit of empathy, the same meaning for both replies could be conveyed in a much friendlier way.
Plus I still think that it's reasonable to expect either the Editor or the Documentation to somehow help users avoid this pitfall.
Especially since behavior inside a component was erratically affected by its siblings.
The second commenter ended with a bonus suggestion too:
I recommend joining one of the communities to get feedback and support when looking for a solution and ending up with something that is not working.
Guess that's a pretty strong hint that I should not be investing in any further interaction with Godot's GitHub community...
Even through that loss of several hours, I still made some good progress!
So there's also reasons to be happy.
Above animated gif already showed it, here's also a still image of the current state of the game:
Lots of the basic interaction has been ported over from prototype-007 as well.
But more importantly, the project and file structure are now well-organized and clean.
I'm on schedule to have an alpha version of the game ready for friendly testers near or shortly after the end of this week.
And I'm pretty happy about that.
The GitHub Kanban Board↗ will show you:
the alpha release is super-minimal.
Only the very basics are in there, and I'll use a User Test Script of sorts that fills in the gaps.
So (near) laser-focus on that alpha-release, is what's up next!
Day 30: Work In Progress
Jeroen, March 14, 2023
Yesterday I started the day with a devlog.
It outlined the goals and plan for this current stretch.
Since the end of yesterday you can now publicly track progress on the GitHub Kanban Board↗.
Today I'm building the foundations of the final codebase, using prototype-007 as a reference point.
Which involves a ton of struggling with Godot's haphazard UI layout features.
So there's little time for an extended devlog.
These few paragraphs will have to do, dear reader!
Catch you tomorrow!
I'm off to get a wee bit more productivity out of today.
Day 29: Planning
Jeroen, March 13, 2023
But Jeroen, isn't halfway into the project a bit late to create a plan!?
Why yes, it would be!
But: I already had a plan, just not fully written down.
And now that the end of my mini-sabbatical is nearing, and the plan is becoming fuzzy, it's time to revise it.
Today I'm writing a devlog fully at the start of the day.
As I write, I'll create a plan for the remainder of the project.
After that, I'll commit the rest of the day to taking the first steps.
So, "what was the 'original' not-written-down plan then?", you may ask.
Well, let's start with what I didwrite down at the start:
Note that the (respectively) pink and red highlighted items I considered most important.
So the plan was to:
Pick a name, build a website + blog
Design and prototype something, create primary sprites
Set up something temporary for sound and music
Create a fun inner game loop
Learn the game engine needed for this
Beta test it, make sure it's fun to play
Publish and release to friends and family
The inner game loop would be:
Drag components around to "design" a machine
Run the playbook to see how it plays out
The secondary game loop:
Run the inner game loop
Check your score and the medals you got
Unhappy? Rinse and repeat. Happy? Go to next level.
The important thing is: all of the above is still roughly relevant!
So creating a fresh plan should be easy, right?!
Before talking about a plan, I need to talk about goals.
Let's start with the initial goals.
When asked before the start, I'd say something like this:
I develop software for a living.
But I've never developed a game before.
So I want to try that.
The goal would be to create one small game, end to end, nearly every part of it created by myself.
And earn at least one euro with it, which can also be my own 1 euro: I just want to see what it takes to getting to publishing a game.
It's also interesting to now what I did not declare to be my goals:
That it should be a good game;
That it should be a successful game (monetarily or otherwise);
That it should be completely finished;
It's very tough to not care about those things.
And to be honest: I do care about all three (in the order above).
But those things were not my goals at the start.
And I think that has remained unchanged.
So the main goals remain:
Experience what it's like to develop a game;
Publish something and earn at least one euro with it;
Knowing my (unchanged) goals, it's time to create a fresh plan.
Prototype 007↗ after Day 26 gives hope.
It should be good enough to help achieve above-stated goals.
So let's work from there.
I should make it "official" too, and clean up a bit while doing so.
The first step should therefore be:
After that I should basically have Prototype 007, but in a somewhat clean codebase.
The next steps would be to get to a playable state where I can ask friends to user test it.
Create a MUTeP: a Minimal User Testable Product.
Something that supports the inner game loop.
Plus (possibly with workarounds) lets you imagine how the secondary game loop would work.
And yes, I just made the "MUTeP" acronym up.
After getting test feedback, things shake up a bit.
Who knows what testers will tell me?
And what changes they require, affecting the plan.
Regardless, the next step should be clear:
Fix the most glaring problems that obstruct the end goals.
Park all other suggestions and problems for the longer term.
After this some extra feedback rounds may continue.
But looking at the main goals, the prime path to them has another focus.
At this point I should focus on making sure that I myself am happy enough:
Make it publishable.
Make it good enough that I'm willing and happy (enough) to put it up on the web.
Including enough polish to make it presentable, without polishing forever.
Originally I thought I'd publish mainly (or even only) on Steam.
But I'm changing that a bit.
I'm aiming to publish an alpha version with disclaimers on Itch.io first.
And I'ld be happy with merely a wish-list page for Steam.
In short, the final step for during my mini-sabbatical would be:
Publish an early-access version.
Can be anywhere, as long as people can pay me an euro for it.
So that I might buy my own game, and accomplish the original goals.
It feels possible to make these 5 steps in the remaining weeks.
And it would feel great to do so, because I love the dopamine hit from achieving goals I set for myself.
So there you have it, that's the plan!
Beyond the plan
My aim with the aforementioned plan is to achieve the initial goals.
There are goals beyond those.
There's two layers of goals:
Complete the game and make it good enough for my own tastes.
And then also publish it on Steam.
Try to make it a success.
Which includes a ton of marketing and social media work.
Go beyond initial success.
Dreaming big, there could be a version 2 of the game, which would be a proper version.
This could include a Kickstarter and/or trying to get extra help on the project.
These are in chronological order, but also in order of how likely they are to happen.
The first one is somewhat likely, as I already sunk the 100 euro's into Steam to be allowed to publish a game.
But even that goal I might skip.
The good news: I don't have to decide at the time of writing this.
In fact, I need to stop writing and start building.
Otherwise I won't even be in a position to think about those extended plans.
Wait what's up!?
A weekend devlog?
That's a first!
Let me explain.
Week 10 started with an XXL post on Day 22.
I set three strict goals to achieve for the day.
But I tend to get distracted by random ideas.
Things to procrastinate with.
So I decided to write them down in a little notepad.
But a random file somewhere is no great solution.
So on Day 23 I decided to stash them into this blog post.
That means the bulk of all ideas were written down during this week.
All ready to go in markdown format.
Where to leave them?
First I figured I'd just finish this blog post with a giant list of ideas.
But now that it's time to finish the post, I realize: ideas change, we iterate on them.
So something less "permanent" or "captured in time" is needed.
I'm a fan of keeping things in once place as much as possible.
It's also nice to do things out in the open a lot, because it feels like commitments then.
And since they're markdown already anyways: let's stash them into (GitHub) issues.
Heck, I might even give GitHub's "projects" feature another go.
What are side-tracks do we have?
So I don't like making this blog post a permanent exhaustive list of ideas.
But what I can do is to show off what I'm starting with.
The content is in the git history of this post's markdown anyways.
So, here's the current list of ideas.
They're only the titles now, each linking to where to find them on GitHub:
And that's all the temptations for procrastination I'd written down so far.
Which core ideas are there?
Thoughts and plans for the game itself reside in my head still.
We can't link to a GitHub issue then, but we can summarize it in one single to-do:
Really, I need to set goals (or accept I'll continue without any).
Create some sort of plan or road map, if I feel like it.
The labels in GitHub↗ have been prepared.
So week 5 of development should just start with this to-do.
And there's the ideas that are neither procrastination-worthy (at this moment), nor core to the game.
They don't deserve a GitHub issue (yet).
So let me just dump them here, so they might not haunt my progress.
Even though I'm skeptical about if or when I'm going to finish Pincrediball, I still like to dream big.
If there's a playable alpha version, it might even be possible to create a Kickstarter.
Even if only to see how that works.
Chase SvelteHack organizers.
Emailed the organizers of hack.sveltesociety.dev↗ a while ago.
I'm really curious if my pincrediball.com site would qualify, since light work on it was started just before the official announcement.
Would be good to send another e-mail or something similar, as I haven't had any response at all.
I think it would be cool to show a couple of line graphs, detailing aspects of development.
Per day a rating for things like "happiness", "productivity", "success", or possibly others.
And now that things are still fresh, I could fill it in for the past few weeks.
Then again... this idea is a bit "out there", and not relevant at all to actually building the damn game...
And that's really it.
Now my head is empty.
No more core ideas, procrastination sidetracks, or out-there thoughts left.
If there are any direct competitors, I might as well check them out.
Most likely there will be software to create (and possibly also play) Pinball machines, which I also want to check out.
If there's time I might check some more general Pinball games.
This item was last in my list, for good reason.
It's super open-ended, and could take hours, but also days or weeks!
In fact, this goal I've missed for today.
I'll put it into the (forthcoming) blog post on all sorts of random ideas I still have.
But for now: there's not much more to say.
Short days are short.
Shorter even than you'd think.
And I really want to wrap up this post, before I leave for social engagements.
Maybe I'll revisit this post and the linked resources later in the day.
But most likely... this will be it.
And tomorrow should be another day of actual development work.
Day 24: Implementing the Tutorial Machine
Jeroen, March 08, 2023
A strong contender for procrastination of today's original goals came up.
From a friend I got a link to an old semi-competitor to my own game.
Enough to get me past my original hesitation to research how (un)original my game idea is.
And what I can learn from those other games, of course.
I really must park that, if even for a day.
And focus on the original goals.
More precisely specified, let me say out loud that today I aim to:
Get at least the sprites in my game for all Tutorial elements;
Get behavior in for round bumpers;
Stretch goal: get behavior in for slings;
I'm gonna "state my goals publicly" again.
This time I'll do so by pushing relevant commits to GitHub early.
I could use the method I introduced earlier (with "(DRAFT)" in the title↗),
but today I'll just go with the simpler "not yet running npm run build yet".
At this point it is time to get coding!
A few moments hours later...
That went better than expected!
Got all sprites (except the rails) in the game.
Also got base behavior in there for nearly all of them.
Here's a good recording of where it stands right now:
It's just insanely fun to watch a "multi-multi-multi-ball" going.
Really that has to become part of the final game somehow.
If only as a "victory dance" after getting the gold medal.
I'm quite excited about these results!
Even though it becomes more clear that this mini-sabbatical is not long enough to complete my entire idea,
I am certainly enjoying myself and learning a ton.
So I'll happily chug along.
Tomorrow will be a day with some social engagements.
So perfect for some light in-between work.
Perhaps some research, and a summary on the devlog.
For continued work on the game and more fancy recordings:
stay tuned for later in the week!
Day 23: Designing the Tutorial Machine
Jeroen, March 07, 2023
Yesterday was an "XXL" day.
Finished very late as well.
So today I'll go a little easier.
First half of a blog post
Here's the goal for today:
Design a "finished" tutorial machine.
Just one goal for today.
I'm starting by writing this first half of the blog post.
To gather thoughts and set my goals.
Because that part did work well, yesterday.
Here's my thoughts on switching back to "Designing" for a bit.
First up, I enjoyed doing the designs.
So it's easy to stay motivated this way.
Second, it will fixate scope for the Pinball Machine components of the Tutorial stage.
So it should help me keep things small (enough).
And free up some mental space, once those things are "on paper".
Third, and most importantly:
it should help me flesh out the core game concepts.
The Tutorial machine should "proof" that the game loops are fun.
Or it will disproof that, and allow me to pivot if needed.
So, without further ado, let me get to creating those designs...
...a few moments hours later:
Second half of a blog post
We're at the end of the day, and there's some result.
Not entirely happy yet, but "good enough" for now.
Decided to "work backwards" with level design.
First I designed one configuration of the tutorial stage that finishes the last level with at least bronze.
Here's the completed machine, as it's built up from the ground:
Outer bounds and background artwork will always be visible to the player.
Components can be placed nearly anywhere on the field.
The artwork is supposed to be a guided tutorial for where things could have a nice placement.
Quests (if ever) can be added to the tutorial by just completing the various goals a set number of time.
The center artwork could just light up more firmly for each achieved goal.
And perhaps increase the multiplier for scores by doing so?
Next day(s) I will try to move all these components into Godot.
Programming their features as I go along.
At some point the entire pinball machine should be "done".
I guess if I add keybindings for the flippers I will have made a basic flipper game?
After that I'm planning to add the actual core features:
players can move around components, then run playbooks to achieve high scores.
I'm sure to run into design troubles at that stage.
But for now, this result will have to do!
A limited goal for the day, and that worked out just fine!
Moderately happy with this result, even though I guess all I did was "design a mediocre Pinball Machine".
Curious to see if I can at least turn that into a working "mediocre Pinball game"...
Additionally (to "publicly stating goals") I'm also going to get all other productivity tricks that work for me going.
One of which is "writing my way through it".
That is: I'm going to rubber duck by writing an extra long devlog to keep me going.
⚠ If you're here for more casual devlogs, then I recommend to stop reading after his paragraph.
If you're here for the full stream-of-consciousness, then saddle in! We're about to dive deep.
1. Designing the tutorial machine
Designing Pinball machines is a skill on its own.
I have no such skill, but I've tried to do a base level of research.
Amongst others, having checked several PAPAPinball YouTube "Machine Tutorials"↗
I see several aspects of a good Pinball machine:
Theme that's appealing (often tied to an existing brand, like "Batman" or "Jurassic Park");
Backplate with artwork around the theme;
Quests: hitting specific targets in specific orders, in a way that's also fun and challenging;
Toys are extra-special (often gimicky and theme-related) components of the machine that do something crazy when hit;
Balance between how hard goals are to hit (and how big a chance you have to drain the ball), and how many points they give;
Multi-ball mode is usually a goal to work towards, preferably when "multipliers" are enabled;
Basic components that must be included:
plunger (with plunger lane and a gate),
Extra components should probably also be included:
backbox and display,
Skill Shots (plunging the initial ball at a particular speed to hit a particular target) are perfect for Pincrediball too.
Especially in the tutorial levels, the "Playbook" could contain a precise skill shot.
This makes it super fun to place the initial components in a very precise location.
We'll start with designing the theme, backplate, and quests.
One theme per "stage" of the game, so multiple levels are on the same theme.
The Tutorial stage is up first.
Although I don't have a good term or word for the theme yet, it'll revolve around:
Stick figures and a "math" paper background;
A limited color scheme with shades of blue, and some black and white;
Quests to build up a mini-comic lit up on the backplate;
At this point I'll stop writing out my thoughts on this blog post.
It's time to grab a tool to design the initial art!
...a few moments hours later:
This gives me something to work with!
Interesting notes about the design:
The plunger lane includes an amber-colored gate that should be "one-way" for the ball;
The three gates at the top are for points, and to be placed by the player in the game to create high scores;
There's a tiny start for stick-figure art in the main area, which will indicate quest progress;
I'm a noob at Figma, yet still made it work decently well!
I want to continue tweaking this design, but I must move on.
There's still two goals left for today.
Time for a quick break, and then on to the next part.
2. Putting it into Godot
For some reason I figured that having SVG's in Figma would make it easy to import everything into Godot.
I was half right.
The wrong half.
Importing the "Art" as textures was very easy.
But the important half was not so easy; perhaps more research is needed?
I was hoping the SVG paths would be useful as collision shapes.
Especially the bezier curves seemed logical for a pinball machine.
I set myself certain goals for today, and getting this bit perfect would hold me back.
So, I went the labor-intensive route.
Importing the design of the machine in chunks from Figma.
And after that... manually tracing over those shapes again, to create the collision polygons.
...a few moments hours later:
That at least should work to some degree!
Let's have a look, shall we?
3. Allow plunging a ball
Time to program a little bit of interactivity.
The plan was as follows:
A "Plunge" button that spawns a ball and shoots it into the field;
Bonus: Flippers that just constantly, well, flipper;
After a bunch of trial and error;
after a ton of Godot 3.x to 4.0 translation;
after loads of debugging and tweaking;
in short after...
...a few moments hours later:
I have a ton of concerns still.
Most notably if this will be deterministic enough for my core game idea.
But concerns be damned, I'm pretty content with this result!
In short, I achieved what I set out to do:
(1) design a machine, (2) put it in Godot, and (3) have basic ball physics.
Setting the goals at the start certainly helped.
Tomorrow I might go for a more free-form day, but soon after I'll certainly use this same trick again.
If you made it this far into my stream-of-consciousness post:
I salute you!
You're the best.
On to the next bits!
Day 19: Rest day
Jeroen, March 03, 2023
Got up an hour later than I wanted.
Enjoyed a visit from a friend, preferred chatting over working on the project.
Some spinning while watching Rick & Morty.
And some LEGO Star War with the Mrs.
In short: not much game dev was done today.
Perhaps I'll catch up over the weekend.
Or maybe I'll just reboot next week.
I'm fine with either, it's a vacation project, after all.
Day 18: Prototype 006 with Godot
Jeroen, March 02, 2023
Today I followed advice from friends.
Godot got several more recommendations.
And right after I decided to take it for a spin, Godot 4.0 was released↗.
After 3+ years of breaking and rebuilding from the ground up, a complete core overhaul and a full engine rewrite: Welcome to the start of Godot 4!
So that's both good and bad.
It's nice that I join in right when a boost in new modern features is released.
But as I suspected, it's less nice that we're now in a state of limbo.
Documentation has warnings all over the place that they might still be out of date.
Online examples are thoroughly broken.
All forum posts and Q&A online still uses the 3.x way of things.
But if I download the 3.x LTS version, I'm learning obsolete skills from the get go.
So Godot 4.0 it was.
I named it "prototype 006" and might still put the code online as such.
But I mainly set out to just build a tiny game with Godot.
As a teenager I'd lie on my back in my room, endlessly tossing a small ball in the air.
To get as close to the ceiling as possible, without actually hitting it.
So I made it into a tiny Godot game.
Really wanted to make it playable in the browser, more on that in a second.
First, an example of what it looks like:
You press [SPACE] or [LEFT MOUSE BUTTON] for 0 to 2000 milliseconds to send it flying up.
The higher you get, the more points you score.
If you hit the ceiling?
Actually fun to build.
Mostly without frustration.
Better than Phaser, certainly.
This is looking promising!
The actual exporting to platforms is a bit more finnicky.
Android requires the SDK so I'm yet to try that.
iOS similarly likely needs special stuff.
The .exe Windows version was somehwat easy.
It includes the entire Godot engine though.
So my super-simple game becomes 45+ MB: not great.
The "html5" version is even worse.
The WASM file also clocks in at similar size.
But worse: it requires quite modern but certainly not ubiquitous Web Server headers.
The response from the Godot team was, understandably but frustratingly:
"This is a Web Server problem that Web Servers should fix"↗.
It seems that support for needed headers↗ won't easily work on GitHub Pages.
So no runnable version of the game on this devlog for now.
It'd be really sad if my final game wouldn't run well in browsers.
Both a demo version on the website, as well as an itch.io version, would be problematic.
But I don't think I'll let that hold me back.
Tomorrow I'll sleep in, and at some point go back to toying with Godot.
Mainly because it was fun to do so!
Day 17: Giving up
Jeroen, March 01, 2023
I'm giving up.
The past few days have been extremely frustrating.
I'm spending days on trivial things like making objects only movable by a player↗.
In those days I'm also loosing hours on how utterly inconsistent and unpredictable the Phaser and Matter API are for nontrivial things.
Summarizing those two things differently:
Core Pincrediball concepts are nontrivial in Phaser's physics engine;
Phaser itself and its engine are frustrating to work with so far;
So I'm giving up.
On my current approach.
What now then?
Well, I need to mentally reset.
So tomorrow I'll start with a completely fresh approach.
Not sure which yet.
To end this day with a brainstorm of a few possible roads to take:
Stick with Phaser and MatterJS?
Still try to stay with Phaser, revitalize, and try to make Matter physics work for me?
Probably I should know better, given how frustrated I am right now.
Stick with Phaser and a new Physics engine?
Stay with Phaser, but see if there's a way to get Box2D to work with it?
I found the Pinball(!) example↗ but it was for the years old version 2 of Phaser.
Try out Godot, or Unity?
The main alternatives I'd consider (next to very maybe GameMaker).
I'm just super-worried that I first need a few weeks to learn them.
Rolling my own engine?
This seemed like a bad idea after day 10.
But perhaps I should give it another go?
Quit building, start (more) procrastination?
To be honest, I've been enjoying everything except building the damn game a lot.
The website, the socials, the designs, the (not-yet-existent) Kickstarter...
Perhaps I should embrace those first?
I have 4 out of 8 weeks left in my mini-sabbatical.
There's plenty of things to do in those weeks, other than building a game.
And surely there are more options.
I'll sleep on it, and decide when I'm fresh at it again.
It's not very likely that I'll "Quit altogether", but I'm keeping options open:
first and foremost I want to be having fun.
And, surprise: all through abovementioned frustration, I'm still having fun!
But for now, I need a break.
Day 16: Putting it all together
Jeroen, February 28, 2023
Second day of week 3, and although I am pushing myself through some relevant work, I'm not making the progress I wanted.
Heck, I'm even writing this recap at the start of day 16.
So I'm keeping it short, so I can try once more to get some work in.
What I did yesterday is to commit on a setup.
I did not name my repository for the day prototype-....
No, I actually started the main game repository.
And I merged the best bits from earlier prototype.
That means the day after this one, there are really no excuses left.
Work has to be done on the game.
Let's get cracking!
First day of week 3 of the project, day 15 of the project.
I'm writing an early devlog today.
After writing this I will probably continue development.
But I feel like I reached a checkpoint now, so a recap is in order.
Looking at the overview of posts you may wonder: "What happened to prototype 004?".
Glad you asked!
In fact, on Day 12 I combined Phaser with Svelte;
only at the end of that day did I "promote" it to its own prototype repository↗.
Quite likely prototype-004 will even grow into the end result at some point.
Ladies and Gentlemen: Prototype Number 005!
So, today I got up fresh and early.
The main problem to tackle: some (more) determinism in runs.
Otherwise the core game loop (precisely placing parts so you get a high score) is no fun.
Determinism turns out to be quite difficult with MatterJS.
But that's only one problem.
It has no Continuous Collision Detection (CCD) either, causing the ball at high velocity to go through walls.
This might get worse once I get to implementing flippers, I suspect.
So I was doubting my engine choice a bit.
Still, after a productive morning, I found that things might be good enough for now.
I tweaked the engine settings to a point where many parallel instances of my game would all give the same result.
Here's the "proof" of that↗:
This prototype made two things clear to me:
It gives enough confidence to move forward with my current setup;
It causes enough doubt that this engine should be the final choice for a full game;
In short: a nice check point reached!
So the next steps are to go "all in" on the current approach.
More specifically, my to do list is currently:
Design a good looking tutorial theme and pinball machine;
Integrate that design, Prototype 004, and Prototype nr. 5;
Allow the player to move bumpers around
Add flippers to the game;
Perhaps a few sound effects to make working on this project a bit more fun too.
I will roll up the rest of today's work in the next devlog entry either way.
Day 12: Combining Phaser and Svelte
Jeroen, February 24, 2023
I'm back to integrating PhaserJS with the MatterJS physics engine, and Svelte.
The fourth prototype uses some of the domain entities from prototype-003.
And it includes a Phaser scene for the actual Pinball machine.
For lack of time (the weekend calls for other obligations) I'll just use a static screenshot for the blog:
The rest of today was spent on trying to make Matter more deterministic.
And in that process I got (again) a bit side tracked with an energy conservation issue↗ with MatterJS.
So we close off this week with far less results than I'd hoped.
For a large part because I procrastinated and let myself get side tracked though.
What all that does mean is that I need to re-evaluate my goals and approach next week.
What's super important is that the machine becomes more deterministic.
The whole "automata player" and game loop idea falls apart if different runs of the automata have different outcomes.
Either the setup needs to become (more) deterministic, or the game loop has to change.
Or my goals for the project need to change...
Got a weekend to chew on that though.
Day 11: Sidetracked with Markdown
Jeroen, February 23, 2023
I let myself get sidetracked...
Not sure how much it is to procrastinate working on the actual game.
But I am sure that it sparked joy to play around with something else.
Here's what I changed up for this pincrediball.com's website source code.
Prose TailwindCSS plugin
Tailwind resets styling, so you can reliably create Web Applications and Sites.
That's all great, but for long-form textual content it's actually painful to loose all styling.
The Tailwind "Prose" plugin↗ aims to solve that, without compromising the reset of styles that Tailwind gives you.
It was just fine to write this devlog straight up with html and Tailwind classes.
But copy-pasting things like mt-4 on each <p> becomes tedious pretty quickly.
The Prose plugin fixes that nicely, and cleaned up my devlog source code considerably.
After briefly trying the (rather nice!) svelte-exmarkdown↗ library, I decided I needed a bit more control.
So I dove a bit deeper into how svelte.dev does things.
And that setup is quite nice indeed, as it includes support for SSR and RSS.
That's all nice!
But what's next?
Should I ever feel like getting side-tracked again, there's a few things left to tweak:
RSS feed would be nice;
Having [slug] based pages might be nice;
GitHub Action to npm run build would be nice;
GitHub Action to deploy GH-Pages should be nice;
But for now: let's stop procrastination and get back to building the game.
Day 10: Prototype 003, part 2
Jeroen, February 22, 2023
Well... that was a disaster!
As warned by folks around me, and just as I already sortof knew would happen:
rolling your own (engine) is a bad idea.
And specifically, too (at least for this case).
After a few hours of labor here's where I got:
And then the mountain of work became visible.
The smart thing to do?
Enjoy a few other fun things in my sabbatical, let the project lie down for a bit.
I'll likely revitalize my enthusiasm for the project and go back to using an existing engine.
Possibly within this web app that's now set up.
Stay tuned for prototype 004 soon (?).
I'm calling it an early day, on Day 10.
Day 9: Prototype 003, part 1
Jeroen, February 21, 2023
After yesterday several friends helped out with some rubber duck debugging.
Got some great input on Slack and in other places about how I could wrangle the physics engine collisions into submission.
And how much I should probably let go and embrace the chaos of a realistic engine.
However, I still changed it up... for prototyping purposes!
Using PhaserJS and MatterJS might still be the right way to go.
But I still wanted to try out how it feels to create a fully custom engine anyways.
Using SvelteKit and Tailwind, just for prototyping speed at the moment.
I didn't get very far yet with writing the actual game loop and time ticker.
But I did do a bunch of good work on an initial game layout.
It's far from polished, but (even though polish might be 80% of the work?!) that's for later.
Here's the initial results:
Obviously, this still needs work.
But it's getting somewhere.
Even if I go the PhaserJS route after all, I might be able to use this setup in conjunction with it.
And I'm sorry to say: that's all for today, folks!
As a final footnote for today's devlog: I also decided to open source the prototypes.
So you can fully see me fumbling about.
Writing all sorts of just-make-it-work code.
You can find all the repositories in the Pincrediball GitHub organization↗.
And for my most loyal readers (hi mum!), here's a quick peek at it, with just a random screenshot of me hacking about in prototype number three!
Prototype 003 will likely get some more love the coming days.
Day 8: Prototype 002
Jeroen, February 20, 2023
After not doing too much during the weekend (days 6 & 7), it's now Monday of week 2 and high time to get back to the project.
After a week of "meta" stuff, designing, and a super-light prototype, today was spent on more in-depth prototyping.
I'm very happy with what I did, but only moderately so with the result.
Here, have a look for yourself first:
(Note that you see the debug boxes and vectors in these prototypes.)
Let's summarize what I learned during today's experiments, starting with the positives:
✅ SvelteKit will be a great "bearer" of the game
✅ Using plain html/css/js for parts of the app will likely turn out great
✅ Tailwind enables for fast menu's and other UI
✅ I got something looking like Pinball physics to work
However, I have many concerns after today:
❌ MatterJS physics is wonky ls going through static bounds or getting stuck
❌ Level editing is cumbersome in (vanilla) Phaser, without any tools
❌ Curved shapes and SVG paths are a major pain to use
I'm not so sure yet where to go from here.
Have I learned that I need to go back to my original idea?
Building a super-simple physics engine of my own, to make everything far more deterministic and reliable?
Or should I stick with out-of-the-box physics and just deal with the issues?
Perhaps a night's sleep and some distraction will bring clarity.
Day 5: Prototype 001
Jeroen, February 17, 2023
Today was not a very productive day, mostly because I didn't spend too much time on the project.
Still, got to a very first prototype with a plunger and a ball, plus some physics:
It seems the choice for PhaserJS with the MatterJS physics engine is "good enough" for my goals.
And I think I will just leave it to chance that I chose right, instead of heavily investigating other Game Engines.
That's it for day 5.
Weekend's up next, we'll see if I continue work, or whether the next update will come on Monday...
Day 4: Engine's on!
Jeroen, February 16, 2023
Today it's time to figure out an engine to use.
I'm leaning heavily towards PhaserJS↗ (the main alternatives being Godot and Unity),
I'm mostly doing tutorials and reading documentation, so no exciting updates from today for the devlog.
That does give me a minute to share my rough "plan" I created earlier in the project.
Here it is:
It started as a brainstorm, but it became a rough "plan".
Each of the six parts is roughly a time box of one week.
I'm starting with "Design" this week, but currently borrowing a bit from the next goal: "Game Loop / Engine".
Stuff's color coded too: the red stuff is Must-Haves, yellow Should-Haves, and green the Nice-to-Haves.
What do you think?
But let's see how far we'll get, shall we?!
Day 3: Website first?
Jeroen, February 15, 2023
Continuing from day 2 with a focus on fun activities, I decided to finish up the website.
This time I don't think I can claim anymore that it's in the end somehow part of the critical path though?
But regardless of whether it was The Right Thing to do right now, it was very effective!
I mean: you're looking at the very result right now.
The website was built with SvelteKit and TailwindCSS, which was rather efficient because I recently used it for both of my other recent side-projects:
Tierdom↗ and vesta.infi.nl↗.
But not before I spent the entire morning learning some more Figma skills to do the entire design first.
I have no excuses left to procrastinate prototyping
So let's end this third day with some initial social media posts and links to this website.
And tomorrow: we prototype!
Day 2: Now we're getting somewhere!
Jeroen, February 14, 2023
Second day I allowed myself to get side-tracked.
I decided that the best way to keep motivation high was by doing essential things disguised as non-essential things.
By this I mean I tried to incorporate essential things (work on the designs and game idea) into far less essential things (that were enjoyable to do).
First thing I did was to redo the main game screen's design.
For fun I've shared that on the (current, at the time of writing) home page.
After that I took care of a bunch of other non-essential (but fun!) things:
It was a fun day with this too, as you can tell from my related toot↗.
And it really gave me a bunch of inspiration and energy to continue on!
Day 1: Gotta start somewhere!
Jeroen, February 13, 2023
First day of the week I decided to start the project.
However, the night before we watched the Super Bowl... in the GMT+1 timezone!
So was up until 04:30 (that's AM for y'all), naturally this wasn't the most productive day.
But the most important thing got done: I got started on the project!
Plus several important things got done nonetheless, as I wrote on Mastodon↗: