Any reason why a bunch of comments say the same thing?
I could hazard a guess that younger readers don’t read other peoples’ handwriting much?
I didn’t even notice it was a problem, but I am middle-aged (I actually like personal writing and I dislike the industrial repetitiveness of fonts. I especially dislike fonts for comics designed to look handwritten but that lack human variability).
I’m 50 and I didn’t find the text very readable, it’s tiny and cramped and really not written with even a tenth of the care that someone lettering a comic by hand would take.
The hand writing was just bad. It wasn't full chicken scratch, but the idea that you would look at negative comments, look at the content and think it's fine, then aimlessly acuse readers of being young is rather absurd.
One way to improve would be to trace a font like comic sans or ames (I'm not actually a font connoisseur). The tracing would be for keeping the kerning and spacing good, not for literal cloning. You can do your own style, but your style itself still needs to be legible.
You can also make your own font file from your hand writing.
Pinch zoom didn't work on this website in Firefox for Android. This would also compound the existing problem.
I much liked https://cloud.google.com/kubernetes-engine/kubernetes-comic/. It does a pretty decent job of using the comic medium by packing in tons of visual metaphors for each concept, having actual characters with defined motivations, being funny... and I won't spoil the ending, but that's done well too.
I think a lot of programmers get stuck in this trap of thinking that making a game is an engineering task. It isn’t. The level to which modern game engines have reached means its really just about your game design, artwork, music, etc. Toy engines like this don’t really have much value, and your time is better spent learning how real engines work.
> I think a lot of programmers get stuck in this trap of thinking that making a game is an engineering task. It isn’t.
Here are a few (non-engineering?) tasks unity does not ship with (last I checked):
* AI Steering behavior
* 2D Pathfinding
* Localization (pre-2018 unity)
* A quality terrain editor
* A quality UI layout mechanism (like why is the UI 100x bigger than the game scene?)
* Any sort of complex multiplayer (pre unity 2020 at least)
And more depending on what specific game your working on. Skill trees? Gotta roll your own. Building a 2D game with tile maps? Good luck using their builtin tile map editor. Complex procedural worlds? Have fun rolling your own. Maybe use some prefabs to speed some of that up.
In addition to that, most of what we call "engineering" today is "how do I organize my CRUD app with a bajillion over-engineered design patterns to make my code cleen and Xtendable". You can do that in a game if you want.
> The level to which modern game engines have reached means its really just about your game design, artwork, music, etc.
Ah yes, all that's left is the easy stuff. After all, designing a custom app workflow, with it's own UI/UX, etc isn't engineering or difficult... Oh wait, doesn't 99% of modern software engineering consist of, "let's make a react app with some custom UI/UX and it's own data models and microservice architecture and blah blah blah". But web dev is definitely "real" engineering unlike these game dev folks.
> Toy engines like this don’t really have much value, and your time is better spent learning how real engines work.
I'm confused by this? So you should invest in learning how engines work? Or you should learn how to use unreal or unity? That's like saying, "Small web frameworks don't really have much value, and your time is better spent learning how real frameworks work". That's just blatantly false. Rolling your own framework has value in the fact that: you learn a lot from it, you learn why certain design decisions are made, and you can more efficiently use big web frameworks since you know the foundations.
Finally, why is it a new fad to say game devs are dumb for wanting to code custom game mechanics? Game engines can only handle the most common use cases. Sometimes you want to try creative things that are simply not possible unless you code a custom engine around it (cough, Minecraft).
Other times you want to make your game stand out by having various custom effects, like embedding velocities in a texture and then using that texture to create dynamic intractable objects like this video[0]. This sure doesn't ship with unity, and all the concepts necessary to make it (physics algorithms, shaders, dynamic textures via framebuffers) are usually encountered when coding your own game engine.
So what does it benefit you to code your own engine? You learn, a lot. All of these concepts give you better tools, tips and tricks you can use in other scenarios. If you can only think about a problem one way, it's likely you'll never innovate much. If you know how to think about game dev from low level graphics to high level game design, you have a lot more ideas and problem solving techniques at your disposal.
Edit: I would also like to add that using lower level frameworks like this helps gain intuition about a lot of concepts that are useful for many things. When I talk about coding your own engine, I don't mean you have to go as low level as bare metal graphics APIs like Vulkan, even using something like Monogame (used to make stardew valley)[1] is beneficial in a lot of ways.
I played with Kaboom a while back and found it fun. I was disappointed, however, to see that the little song that used to be on the front page of the website is gone. Kaboom devs if you see this - bring back the song!
Agreed. Most tutorials have a readable font. This one on the other hand appears to teach not a lot except perhaps an intro to linguistic cryptanalysis.
Please don't complain about tangential annoyances—things like article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
It's still tangential. It's hard to read for some but there's not much point writing the Nth grumpy comment about it. And if the author is here, as in this case, you can include it in whatever else you have to say about the thing without being a jerk about it.
It wasn’t all cursive, but close. For example, look at the word “need” in the second word balloon. It has no gaps – it’s clearly cursive. Also, in the seventh panel, second word balloon, the words “favourite [sic] language” are not cursive, but still almost unreadable. And so on.
can't bother to point out that y axis is flipped because that's how we read and the same hardware that was used for printing text was also used for graphics
