So, I can take a small break, since I put together my skeleton.
Time to talk about #js13kgames
I only found a few toots here, so I figured, you might want to learn more about why I'm so eager to engage in it.
It's doable. It's a challenge!
If you take a look at the previous entries, there's a lot of creativity.
Oh, and the code is Open Source.
You can study and learn from it.
In previous years, Andrzej / end3r even put everything on USB pen drives and shipped it to the participants.
Now, GitHub and others are advertising the competition (see https://github.blog/2021-10-05-13-tiny-and-terrific-entries-from-the-js13kgames-competition/ for last year, for example), the number of participants rushed, so it is no longer doable financial-wise.
Even t-shirts are only awarded to the top100. It's possible to send some money to buy one (and support his efforts). I do it since years.
Yes, my games in the previous years are kind of crappy.
I consider it R&D (Research and Development).
See #GameDevelopment is not something I have training in. I learned most of it on my own.
I don't have intentions to head into it carreer-wise (because the competition is fierce).
But it's fun also.
In fact, #GameDev will teach you so much on optimisation and performance.
Unlike other hackathons, you don't have 24-48 hours here. You have a _whole month_!
That means, it's enough time to do some research, look at different libraries (this evening, about two hours from now, some maintainers will introduce you to their code) and categories.
You can focus on desktop, mobile, have multiplayer if you use the server skeleton they provide or even go VR.
There are some extra awards in certain categories.
So what to do with the extra time?
I usually head over to different sites like Dribbble to look for some moods I want to go after.
Or consult a thesaurus for the topic (this year, it's about #DEATH).
One decision might be about the genre.
But I usually start with setting up a git repository (I gave up on GitHub for this already).
It's a controversy topic, but I plan to also add a #GDD (Game Development Document). It poses me some questions that spark my creativity. I don't have plans to monetize my game.
But thinking about some questions like story, player, opponents etc. aid me.
You can look at previous years and find #Postmortem by different participants.
Mine are quite technical, so I started to write a journal and add screenshots of current state a few years ago. That helps better understand my thought process.
It's not set up yet, but will appear in the repo later today.
#js13kgames is often taking part during the summer vacation. We will be on holiday this year as well.
(I'm so much looking forward to it).
Meaning, laptop is going to stay at home. Family and everything.
So will I loose some time?
Luckily, Android is somewhat Linux as well. We have some apps there.
It even allows you to use some runtimes, so I can use tooling (but I forego this for most parts).
Markor has an option to render HTML. So if I edit code in Vim, copy it over to a place I can access using Markor, I can code on my mobile and have a preview :-)
Turns out, I personally roll best when using Objects and Functions.
I omit classes if possible. #OOP is nice and well understood, but it takes more space. Which is critical in #js13kgames. Instead, having data and means to manipulate it turns out to be way more efficient.
Given the size constraint, you can't have much complexity, which might be a reason to go OOP.
Mentioning @vanderZwan because it will get more interesting going forward now
It even gets stressed in https://frontendmasters.com/courses/enterprise-patterns/ (Enterprise Architecture Patterns).
However, the Redux library itself is too big. Luckily, they describe their architecture, so it is straight forward to reimplement it:
Actions, reducer and store and you are ready to go.
Middlewares and combineReducer can be dropped.
Side effects could be invoked after each dispatch (as part of the Store class).
If I take it a step further, I can use form inputs to accept the information, that make games special. Put them into a Store.
And generate code.
Yes, there are ways to do this proper with #AST and everything.
You can create functions on-the-fly, e.g. using the Function constructor.
I'm going the route of assembling a <script> on-the-fly. That is, having the code as string.
Now, if you call Function.prototype.toString() you can see the whole implementation as string. This will break all closures, so you might need to include more that just the public API. But FP leans towards many small functions. By using function declarations (instead of function expressions), hoisting might play into your cards.
Then, you „just” need to take care for the data separately.
So if I put everything into an iframe, I can have a preview next to the forms.
By using Redux I can have easy debug by offering controls, to set up the game environment in a way I want. Then I can hack to my pleasure.
I can offer Redo and Undo thanks to Actions.
I can even go so far and have the state replay over the network (multiplayer!)
Betting on the frameworkless movement ( https://github.com/frameworkless-movement/manifesto ) has a drawback:
the DOM is edited quite often. Attached event listener would lead to a memory leak.
But there's a way out!
jQuery (no, hear me out!)
jQuery encouraged you to use #EventDelegation: register and event handler not on every element, but on some further up the tree.
So if I register with document.body, I can catch almost everything. Looking at the event.target allows me to decide what to do.
By coming up with a clever HTML API using data attributes ( https://www.smashingmagazine.com/2017/02/designing-html-apis/ ) allows me to declarative control the experience.
I can use this for transitions or key bindings.
Oh, and don't support #WASD only. For example, the French keyboard layout will make those players cringe.
Next to arrow keys (and on-screen buttons) #ZQSD is recommended:
Maxime / Xem is a person to stay close to. He assembled a lot of research and code gulf, that will teach you new tricks.
The tweet also mentions to come up with a demo as soon as possible so to gather feedback by others who play it.
I try to support Desktop Firefox and Chromium as well as Android mobiles and tablets (using Firefox).
Something I learned to value are to think of the UI as in terms of scenes. Like in a theatre.
I believe, #Phaser taught me this.
Have every view (like you might say in Android or iOS) be a scene with things to put in.
Welcome to the 8th Layer of Madness
Most topics are related to Linux, Anime, Music, Software and maaaany more