GreatReads - Blog Aggregator · Phoenix Framework

Posts in Design (20 found)

The Universe of Joshua Blais 3 days ago

Compline - A colorscheme for deep contemplation and work

Open Source

Design

0 views

Raph Koster 4 days ago

Notes From an Interview With Jony Ive

Patrick Collison, CEO of Stripe, interviewed Jony Ive at Stripe Sessions . Below are my notes from watching the interview. I thought about packaging these up into a more coherent narrative, but I just don’t have the interest. However, I do want to keep these notes for possible reference later, so here’s my brain dump in a more raw form. On moving fast and breaking things: breaking stuff and moving on quickly leaves us surrounded by carnage. There’s an intriguing part in the interview where Ive reflects on how he obsessed over a particular detail about a cable’s packaging. He laughs at the story, almost seemingly embarrassed, because it seems so trivial to care about such a detail when he says it out loud. But Collison pushes him on it, saying there’s probably a utilitarian argument about how if you spend more time making the packaging right, some people mights save seconds of time and when you multiply that across millions of people, that's a lot of savings. But Collison presumes Ive isn’t interested in that argument — the numbers, the calculation, etc. — so there must be something almost spiritual about investing in something so trivial. Ive’s response: I believe that when somebody unwrapped that box and took out that cable, they thought “Somebody gave a shit about me.” I think that’s a nice sentiment. I do. But I also think there’s a counter argument here of: “They cared when they didn’t have to, but they were getting paid to spend their time that way. And now those who can pay for the result of that time spent get to have the feeling of being cared for.” Maybe that’s too cynical. Maybe what I’m getting at is: if you want to experience something beautiful, spend time giving a shit about people when you don’t stand to profit from it. To be fair, I think Ive hints at this with his use of “privilege” here: I think it’s a privilege if we get to practice and express our concern and care for one another [by making things for one another at work] People say products are a reflection of an organization’s communication structure. Ive argues that products are a function of the interpersonal relationships of those who make them: To be joyful and optimistic and hopeful in our practice, and to be that way in how we relate to each other and our colleagues, [is] how the products will end up. Ive talking about how his team practiced taking their design studio to someone’s house and doing their work there for a day: [Who] would actually want to spend time in a conference room? I can’t think of a more soulless and depressing place…if you’re designing for people and you’re in someone’s living room, sitting on their sofa or floor and your sketchbook is on their coffee table, of course you think differently. Of course your preoccupation, where your mind wanders, is so different than if you’re sitting in a typical corporate conference room. Everybody return to the office! Ive conveying an idea he holds that he can’t back up: I do believe, and I wish that I had empirical evidence What is the place for belief in making software? Ive speaks about how cabinet makers who care will finish the inside parts of the cabinet even if nobody sees them: A mark of how evolved we are as people is what we do when no one sees. It’s a powerful marker of who we truly are. If you only care about what's on the surface, then you are, by definition, superficial. Reply via: Email · Mastodon · Bluesky

Design

Business

Culture

0 views

Dominik Weber 5 days ago

Learning photography: composition

I've been taking pictures with mine for years, as I imagine most smartphone owners do. When I see something picture-worthy, I pull out my smartphone and take a shot. But I never seem to be able to do the scenes justice. The pictures always fall flat. What I found so captivating when seeing it with my own eyes is nowhere to be seen in the picture. I wanted to learn how to take pictures that captures what I like about the scenes. So, to improve my photography skills I decided to learn the foundations. The books I read covered a wide array of topics. Composition, lighting, technical knowledge (e.g. lenses, exposure), how to recognize picture-worthy scenes, and much more. It was great to read about all that, and it showed me many areas to learn and improve. But as an amateur photographer it's too much to focus on at once. I have to take my time and practice step by step. Composition, learning how to arrange the elements, appeared to be the foundation. Other topics, like lighting for example, build on top of composition. Which is the reason why I focused my efforts on improving my composition skills before anything else. ## Composition Composition is a catchall term that covers a bunch of techniques and guidelines. The ones I learned about are leading lines, framing, foreground interest, symmetry, landscape vs portrait,, rule of thirds, and visual weight. It's possible to take great pictures without those guidelines, or by breaking them, but as a beginner they helped me improve my pictures. And knowing about them sharpened my eye. I classify them in 2 areas - Creating balance in the picture: symmetry, rule of thirds, visual weight - Guiding the eye of the viewer: leading lines, framing, foreground interest, landscape vs portrait They can be arbitrarily combined. It's not necessary to use all of them, and using more of them doesn't guarantee a great result. It takes experimentation and experience. For me, this knowledge combined with intuition and experimentation (taking many pictures of the same subject) creates the best results. And I assume (hope) that over time the accumulated experience will allow me to take better pictures with fewer takes. ## Guiding the eye Techniques for guiding the eye are about connecting the viewer with the picture. My pictures often appeared lifeless, and the primary reason was that I photographed the main subject without paying attention to the surroundings. The result was that the images had nothing that draws the viewer in. Nothing that connects the viewer with the subject. Techniques to guide the eye to the subject fix that. ### Foreground interest When photographing a subject that's large or far away, images often feel disconnected and lose their sense of depth. Objects in the foreground can counteract that effect. They are a stepping stone into the image, towards the subject. This is particularly important for landscape photography. It's easy to focus on the big picture, on the landscape. But a good picture also needs something close by to connect the viewer to the subject or landscape. ![](./IMG_0873.jpeg) In this picture, the subject is the Arco da Rua Augusta (the building). The bucket and the bag with the red jacket were happy accidents (I didn't know they were there, didn't pay attention to them). Without them, the foreground would be empty, and there would be nothing to connect the viewer to the subject further back. As a side note, cropping the image, shaving some off the top, would probably further improve it. ### Framing Framing is surrounding (parts of) the picture with something that resembles a frame. It can be anything, a window, a door frame, or any other kind of opening. The frame calls attention to the part of the picture that's inside. ![](./IMG_0933.jpeg) In this picture the scenery is framed by the stone wall around it. Framing can have a stronger impact if there was a specific subject that's worthy of framing, and if it frames only part of the picture. Here, the frame covers the whole picture. I still like it, but mostly because of the symmetry (I'll reuse the picture later in this article). The pictures with framing that I have all cover the full image. More complex scenes, where only part of the image is framed, and the other part still is interesting enough to be in the picture, are much more difficult to spot. ### Leading lines Leading lines are any objects that create some sort of line. They help drawing viewers into the picture. They guide the eye of the viewer to a specific part, often the subject. ![](./IMG_1017.jpg) In this picture I used the bridge as a leading line going to the colorful buildings in the back. Without the bridge, it would be a picture of random buildings in the background. ### Landscape vs portrait I was never quite sure which orientation to take my pictures in. I mostly decided that based on the picture and how the scene would fit in it. Now I know that landscape pictures encourage the eye to move from side to side, while portrait pictures encourage up and down movement. It's best to choose the orientation that matches the flow of the subject, or the dominant lines in the image. For example, in the image above (Leading lines section), the dominant line is the bridge. At first it goes straight into the image, but the more important part is when it turns right and becomes horizontal. This is why I shot it in landscape. In the image below, the eye should quite clearly move from the street in the front to the hill and building in the back. That's why this picture is in portrait mode. ![](./IMG_0938.jpeg) ## Creating balance Balance in a photo creates harmony and evokes an emotional response. If the viewer is connected with the image (through the aforementioned techniques), balance is what causes captivation. I imagine there are many more ways to evoke an emotional response and create great pictures. But for me, currently, harmony is what I'm after in my photos. ### Symmetry There is beauty in symmetry, and we are instinctively drawn to it. The same in pictures. However, if it's too symmetric, it can feel a bit eerie, a bit too perfect. Slight imperfections make it interesting. ![](./IMG_0933.jpeg) In this picture I like the frame (as mentioned before) but also the symmetric aspect of the man standing on the left and the stand on the right. They create a balance, without perfectly mirroring each other. ### Rule of thirds This is probably the most well-known technique. Pretty much every camera and camera app has a setting to show lines at 1/3rd and 2/3rd of the width and height. The rule of thirds is about putting the subject at one of the points where the lines overlap. So that the focal point of the image is about a third of the width or height away from the center. Putting the subject in the center can be too boring, too predictable. Moving it off-center can make the picture more exciting while still keeping it balanced. ### Visual weight The visual weight is how strong an element appears in the image. For a balanced picture, the size of elements are less important than their visual weights. If one element looks heavier than the others, it should take less space in the picture to balance it out. Finding the correct relationship between the elements is complicated. I haven't read any specific tips, besides trusting yourself when taking and viewing the picture, and adjusting based on feeling. ![](./IMG_1063.jpeg) ![](./IMG_1064.jpeg) I think it's obvious why I like these pictures. The sky is breathtaking. What I find interesting though is that on my phone, the first picture looked better. There the balance of the bright sky and dark foreground was good. But when looking at them on my laptop (with a bigger screen), I find the second one better. I'm not sure what to make of that, maybe the size of the image changes the visual balance? ## Final words Photos are good if they create an emotional response. As I paid more attention to the mentioned techniques, it became easier to create such pictures, but they're by no means a requirement. The books I read mentioned that it's also possible to take great pictures by throwing all rules out the window. It's much more difficult though, it takes a trained eye which I, as an amateur, don't have. So for now I'll use these rules when taking pictures. And I am happy that I finally decided to read photography books. With that little investment my pictures are 10x better than before.

Design

0 views

Artyom's Chaotic Blog 6 days ago

Towards Better Word

Read on the website: The concept of text editing word is inflexible and outdated. We need better.

Design

Frontend

Writing

0 views

JSLegendDev 1 weeks ago

Making a Small RPG

I’ve always wanted to try my hand making an RPG but always assumed it would take too much time. However, I didn’t want to give up before trying so I started to think of ways I could still make something compelling in 1-2 months. To help me come up with something, I decided to look into older RPGs as I had a hunch they could teach me a lot about scoping because back in the 80s, games were small because of technical limitations. A game that particularly caught my attention was the first Dragon Quest. This game was very important because it popularized the RPG genre in Japan by simplifying the formula therefore, making it more accessible. It can be considered the father of the JRPG sub-genre. What caught my attention was the simplicity of the game. There were no party members, the battle system was turn based and simple and you were free to just explore around. I was particularly surprised by how the game could give a sense of exploration while the map was technically very small. This was achieved by making the player move on an overworld map with a different scale proportion compared to when navigating towns and points of interest. In the overworld section, the player appeared bigger while the geography was smaller, allowing players to cover large amounts of territory relatively quickly. The advantage of this was that you could switch between biomes quickly without it feeling jarring. You still had the impression of traversing a large world despite being small in reality. This idea of using an overworld map was common in older games but somehow died off as devs had less and less technical limitations and more budget to work with. Seeing its potential, I decided that I would include one in my project even if I didn’t have a clear vision at this point. Playing Dragon Quest 1 also reminded me of how annoying random battle encounters were. You would take a few steps and get assaulted by an enemy of some kind. At the same time, this mechanic was needed, because grinding was necessary to be able to face stronger enemies in further zones of the map. My solution : What if instead of getting assaulted, you were the one doing the assault? As you would move on the map, encounter opportunities signified by a star would appear. Only if you went there and overlapped with one would a battle start. This gave the player agency to determine if they needed to battle or not. This idea seemed so appealing that I knew I needed to include it in my project. While my vision on what I wanted to make started to become clearer, I also started to get a sense of what I didn’t want to make. The idea of including a traditional turn based battle system was unappealing. That wasn’t because I hated this type of gameplay, but ever since I made a 6 hour tutorial on how to build one , I realized how complicated pulling one off is. Sure, you can get something basic quickly, but to actually make it engaging and well balanced is another story. A story that would exceed 1-2 months to deal with. I needed to opt for something more real-time and action based if I wanted to complete this project in a reasonable time frame. Back in 2015, an RPG that would prove to be very influential released and “broke the internet”. It was impossible to avoid seeing the mention of Undertale online. It was absolutely everywhere. The game received praised for a lot of different aspects but what held my attention, was its combat system. It was the first game I was aware of, that included a section of combat dedicated to avoiding projectiles (otherwise known as bullet hell) in a turn based battle system. This made the combat more action oriented which translated into something very engaging and fun. This type of gameplay left a strong impression in my mind and I thought that making something similar would be a better fit for my project as it was simpler to implement. While learning about Dragon Quest 1, I couldn’t help but be reminded me of The Legend of Zelda Breath of The Wild released in 2017. Similarly to Dragon Quest, a lot of freedom was granted to the player in how and when they tackled the game’s objectives. For example, in Breath of The Wild, you could go straight to the final boss after the tutorial section. I wanted to take this aspect of the game and incorporate it into my project. I felt it would be better to have one final boss and every other enemy encounter would be optional preparation you could engage with to get stronger. This felt like something that was achievable in a smaller scope compared to crafting a linear story the player would progress through. Another game that inspired me was Elden Ring, an open world action RPG similar to Breath of The Wild in its world structure but with the DNA of Dark Souls, a trilogy of games made previously by the same developers. What stuck with me regarding Elden Ring, for the purpose of my project, was its unique way it handled experience points. It was the first RPG I played that used them as a currency you could spend to level up different attributes making up your character or to buy items. Taking inspiration from it, I decided that my project would feature individually upgradable stats and that experience points would act as a currency. The idea was that the player would gain an amount of the game’s currency after battle and use that to upgrade different attributes. Like in Elden Ring, if you died in combat you would lose all currency you were currently holding. I needed a system like this for my project to count as an RPG. Since by definition an RPG is stats driven. A system like this would also allow the player to manage difficulty more easily and it would act as the progression system of my game. When I started getting into game development, I quickly came across Pico-8. Pico-8, for those unaware, is a fantasy console with a set of limitations. It’s not a console you buy physically but rather a software program that runs on your computer (or in a web browser) that mimics an older console that never existed. To put it simply, it was like running an emulator for a console that could’ve existed but never actually did. Hence the fantasy aspect of it. Pico-8 includes everything you need to make games. It has a built-in code editor, sprite editor, map editor, sound editor, etc… It uses the approachable Lua programming language which is similar to Python. Since Pico-8 is limited, it’s easier to actually finish making a game rather than being caught in scope creep. One game made in Pico-8 particularly caught my interest. In this game you play as a little character on a grid. Your goal is to fight just one boss. To attack this boss, you need to step on a glowing tile while avoiding taking damage by incoming obstacles and projectiles thrown at you. ( Epilepsy Warning regarding the game footage below due to the usage of flashing bright colors.) This game convinced me to ditch the turned based aspect I envisioned for my project entirely. Rather than having bullet hell sections within a turn based system like in Undertale the whole battle would instead be bullet hell. I could make the player attack without needing to have turns by making attack zones spawn within the battlefield. The player would then need to collide with them for an attack to register. I was now convinced that I had something to stand on. It was now time to see if it would work in practice but I needed to clearly formulate my vision first. The game I had in mind would take place under two main scenes. The first, was the overworld in which the player moved around and could engage in battle encounters, lore encounters, heal or upgrade their stats. The second, being the battle scene, would be were battles would take place. The player would be represented by a cursor and they were expected to move around dodging incoming attacks while seeking to collide with attack zones to deal damage to the enemy. The purpose of the game was to defeat a single final boss named king Donovan who was a tyrant ruling over the land of Hydralia where the game took place. At any point, the player could enter the castle to face the final boss immediately. However, most likely, the boss would be too strong. To prepare, the player would roam around the world engaging in various battle encounters. Depending on where the encounter was triggered, a different enemy would show up that fitted the theme of the location they were in. The enemy’s difficulty and experience reward if beaten would drastically vary depending on the location. Finally, the player could level up and heal in a village. I was now ready to start programming the game and figuring out the details as I went along. For this purpose, I decided to write the game using the JavaScript programming language and the KAPLAY game library. I chose these tools because they were what I was most familiar with. For JavaScript, I knew the language before getting into game dev as I previously worked as a software developer for a company who’s product was a complex web application. While most of the code was in TypeScript, knowing JavaScript was pretty much necessary to work in TypeScript since the language is a superset of JavaScript. As an aside, despite its flaws as a language, JavaScript is an extremely empowering language to know as a solo dev. You can make games, websites, web apps, browser extensions, desktop apps, mobile apps, server side apps, etc… with this one language. It’s like the English of programming languages. Not perfect, but highly useful in today’s world. I’ll just caveat that using JavaScript makes sense for 2D games and light 3D games. For anything more advanced, you’d be better off using Unreal, Unity or Godot. As for the KAPLAY game library, it allows me to make games quickly because it provides a lot of functionality out of the box. It’s also very easy to learn. While it’s relatively easy to package a JavaScript game as an app that can be put on Steam, what about consoles? Well it’s not straightforward at all but at the same time, I don’t really care about consoles unless my game is a smash hit on Steam. If my game does become very successful than it would make sense businesswise to pay a porting company to remake the game for consoles, getting devkits, dealing with optimizations and all the complexity that comes with publishing a game on these platforms. Anyway, to start off the game’s development, I decided to implement the battle scene first with all of its related mechanics as I needed to make sure the battle system I had in mind was fun to play in practice. To also save time later down the line, I figured that I would make the game have a square aspect ratio. This would allow me to save time during asset creation, especially for the map as I wanted the whole map to be visible at once as I wouldn’t use a scrolling camera for this game. After a while, I had a first “bare bones” version of the battle system. You could move around to avoid projectiles and attack the enemy by colliding with red attack zones. Initially, I wanted the player to have many stats they could upgrade. They could upgrade their health (HP), speed, attack power and FP which stood for focus points. However, I had to axe the FP stat as I originally wanted to use it as a way to introduce a cost to using items in battle. However, I gave up on the idea of making items entirely as they would require too much time to create and properly balance. I also had the idea of adding a stamina mechanic similar to the one you see in Elden Ring. Moving around would consume stamina that could only replenish when you stopped moving. I initially though that this would result in fun gameplay as you could upgrade your stamina over time but it ended up being very tedious and useless. Therefore, I also ended up removing it. Now that the battle system was mostly done, I decided to work on the world scene where the player could move around. I first implemented battle encounters that would spawn randomly on the screen as red squares, I then created the upgrade system allowing the player to upgrade between 3 stats : Their health (HP), attack power and speed. In this version of the game, the player could restore their health near where they could upgrade their stats. While working on the world scene was the focus, I also made a tweak to the battle scene. Instead of displaying the current amount of health left as a fraction, I decided a health bar would be necessary because when engaged in a fast paced battle, the player does not have time to interpret fractions to determine the state of their health. A health bar would convey the info faster in this context. However, I quickly noticed an issue with how health was restored in my game. Since the world was constrained to a single screen, it made going back to the center to get healed after every fight the optimal way to play. This resulted in feeling obligated to go back to the center rather than freely roaming around. To fix this issue, I made it so the player needed to pay to heal using the same currency for leveling up. Now you needed to carefully balance between healing or saving your experience currency for an upgrade by continuing to explore/engage in battle. All of this while keeping in mind that you could lose all of your currency if defeated in battle. It’s important to note that you could also heal partially which provided flexibility in how the player managed the currency resource. Now that I was satisfied with the “bare bones” state of the game, I needed to make nice looking graphics. To achieve this, I decided to go with a pixel art style. I could spend a lot of time explaining how to make good pixel art but, I already did so previously. I recommend checking my post on the topic. I started by putting a lot effort drawing the overworld map as the player would spend a lot of time in it. It was a this stage that I decided to make villages the places where you would heal or level up. To make this clearer, I added icons on top of each village to make it obvious what each was for. Now that I was satisfied with how the map turned out, I started designing and implementing the player character. For each distinct zone of the map, I added a collider so that battle encounters could determine which enemy and what background to display during battle. It was at this point that I made encounters appear as flashing stars on the map. Since my work on the overworld was done, I now needed to produce a variety of battle backgrounds to really immerse the player in the world. I sat down and locked in. These were by far one of the most time intensive art assets to make for this project but I’m happy with the results. After finishing making all backgrounds, I implemented the logic to show them in battle according to the zone where the encounter occurred. The next assets to make were enemies. This was another time intensive task but I’m happy with how they turned out. The character at the bottom left is king Donovan the main antagonist of the game. Further Developing The Battle Gameplay While developing the game, I noticed that it took too much time to go from one end of the battle zone to the other. This made the gameplay tedious so I decided to make the battle zone smaller. At this point, I also changed the player cursor to be diamond shaped and red rather than a circle and white. I also decided to use the same flashing star sprite used for encounters on the map but this time, for attack zones. I also decided to change the font used in the game to something better. At this point, the projectiles thrown towards the player didn’t move in a cohesive pattern the player could learn over time. It was also absolutely necessary to create a system in which the attack patterns of the enemy would be progressively shown to the player. This is why I stopped everything to work on the enemy’s attack pattern. I also, by the same token, started to add effects to make the battle more engaging and sprites for the projectiles. While the game was coming along nicely, I started to experience performance issues. I go into more detail in a previous post if you’re interested. To add another layer of depth to my game, I decided that the reward you got from a specific enemy encounter would not only depend on which enemy you were fighting but also how much damage you took. For example, if a basic enemy in the Hydralia field would give you a reward of a 100 after battle, you would actually get less unless you did not take damage during that battle. This was to encourage careful dodging of projectiles and to reward players who learned the enemy pattern thoroughly. This would also add replayability as there was now a purpose to fight the same enemy over and over again. The formula I used to determine the final reward granted can be described as follows : At this point, it wasn’t well communicated to the player how much of the base reward they were granted after battle. That’s why I added the “Excellence” indication. When beating an enemy, if done without taking damage, instead of having the usual “Foe Vanquished” message appearing on the screen, you would get a “Foe Vanquised With Excellence” message in bright Yellow. In addition to being able to enter into battle encounters, I wanted the player to have lore/tips encounters. Using the same system, I would randomly spawn a flashing star of a blueish-white color. If the player overlapped with it, a dialogue box would appear telling them some lore/tips related to the location they were in. Sometimes, these encounters would result in a chest containing exp currency reward. This was to give a reason for the player to pursue these encounters. This is still a work in progress, as I haven’t decided what kind of lore to express through these. One thing I forgot to show earlier was how I revamped the menu to use the new font. That’s all I have to share for now. What do you think? I also think it’s a good time to ask for advice regarding the game’s title. Since the game takes place in a land named Hydralia . I thought about using the same name for the game. However, since your mission is to defeat a tyrant king named Donovan, maybe a title like Hydralia : Donovan’s Demise would be a better fit. If you have any ideas regarding naming, feel free to leave a comment! Anyway, if you want to keep up with the game’s development or are more generally interested in game development, I recommend subscribing to not miss out on future posts. Subscribe now In the meantime, you can read the following :

Design

Gaming

JavaScript

Python Lua

0 views

Ruslan Osipov 1 weeks ago

Modality, tactility, and car interfaces

Modal interfaces are genuinely cool. For the uninitiated, a “modal” interface is one where the same input does different things depending on the state (or mode) the system is in. Think of your smartphone keyboard popping up only when you need to type, or a gas pedal driving the car forward or backward depending on the gear. I love the concept enough to dedicate a whole chapter of Mastering Vim to it. But there’s a time and a place for everything, and a car’s center console is neither the time nor the place for a flat sheet of glass. I was traveling this week and rented a Kia EV6 - a perfectly serviceable electric car. I was greeted by a sleek touch panel that toggles control between the air conditioning and the audio system. Dear car manufacturers: please, I am begging you, stop. When I’m driving down the highway at 75 miles per hour, the absolute last thing I should be doing is taking my eyes off the road to visually verify which mode my AC knobs are in so I can turn down the volume. I can’t feel my way around the controls because gently grazing the surface of the screen registers as a button press. It’s not just annoying - it’s unsafe. Modality works fine when you have physical feedback. My old Pebble Time Round ( may it rest in peace ) had a tactile modal interface. It had four buttons that did different things depending on the context. But because they were physical, clicky buttons, I could operate the watch without ever looking at it. I could skip a track or dismiss a notification while riding my bike, purely by feel. Compare that to modern smart watches, or, worse, earbuds. Don’t even get me started on touch controls on earbuds. I’m out here riding my bike through rough terrain - I do not have the fine motor control required to perform a delicate gesture on a wet piece of plastic lodged in my ear. I miss the click. I miss the resistance. I miss knowing I’ve pressed a button without needing confirmation from the software. We’ve optimized for screens that can be anything in so many areas of our lives, but these screens aren’t particularly good at controlling stuff when we’re living said lives. Yeah, I miss analog buttons.

Design Electronics

Hardware

0 views

JSLegendDev 1 weeks ago

5 Pixel Art Tips for Programmers

Programmers are known to not have a strong suit for art related disciplines, pixel art is no exception. In this post, I’ll share 5 tips for making good pixel art from the point of view of a programmer. This is to help other solo devs coming from a programming background to make better pixel art for their games. Now, you might be wondering if I’m qualified to share tips related to pixel art? Below are two pixel art asset packs I made. If you like how they look, then the question is answered. https://jslegend.itch.io/kirby-like-platformer-asset-pack https://jslegend.itch.io/samurai-arena Here are all the asset packs I’ve made so far : Kirby like platformer asset pack (FREE) Mario-like Platformer Asset Pack ($4) 2D Pixel Art Samurai Arena ($4) How do you know if a sprite looks good or not? You might have assumed that you just need to look at it and your brain determines whenever it’s appealing or not. Maybe the colors clash or the pixels are not placed symmetrically, etc… all things that you should detect naturally. However, it’s not that simple, an art piece can go against commonly held rules and still look good. It can look good to one person but not to another. While it’s true that whether a sprite or any piece of art looks good is subjective to some extent, it’s undeniable that some of them are widely considered more appealing. This subjective nature of art is what a lot of programmers struggle with. You might be used to having a compiler compile and run your code. If your code successfully runs then you know that at least your code works. With art however, you need to acquire good taste that will effectively act as your own internal compiler when doing pixel art. It will guide you during your art process and allow you to realize when things don’t work (ex: Color clashes, etc…). The question now becomes, how do you develop good taste in pixel art? The simplest way is to look at well regarded pixel art online. It can come from games where the art is praised or from pixel artists online. When observing each piece, try to notice the details. If you do this enough, you’ll build an internal understanding of what makes good pixel art. https://x.com/nekocrocodile/status/1894101890406776904 https://x.com/ChrisPariano/status/1886151340541227153 Tip #2 : Don’t Draw! Negotiate Your Pixels Instead If you come to pixel art with the mindset that you’re going to draw what you want like you would on pen and paper, you’re going to get frustrated. Pixel art at low resolutions is all about negotiating with your canvas. It’s basically a puzzle game. You need to figure out where to place your pixels to represent what you want while still compromising on certain details. The sooner you view pixel art like this, the less you’re going to struggle drawing the sprites you need for your games. This is because you’re now more flexible and ready to adapt when representing certain things that are challenging at low resolutions. You can either do the hard work of figuring out how to represent an object or character in lower resolutions or you can go look at the million of available game sprites that already solved what you’re trying to represent. That’s why I recommend using references extensively. For example, if you want to make a top-down action adventure game a la Zelda there is no shame in looking up link’s sprites to see how he’s represented or how his sword attack animations are made. In case you didn’t know, the most comprehensive website for looking up sprites from various retro games is The Spriters Resources . Tip #4 : Stick to a Limited Color Palette but Expand It if Needed Sticking to a limited color palette is very important in pixel art due to the low amount of space available. Every color you choose will have a big impact on the appeal of the final sprite. If you don’t want to deal with color theory, you can always pick an existing color palette. There is this website called Lospec with plenty of color palettes you can pick from. On this website, you can often see pixel art examples using the listed color palette. This will help you determine if a given palette will likely help you achieve your desired aesthetic. Another option consists in finding a pixel art piece you like online and picking the same colors to make your palette. Finally, you might feel too constrained working with a limited amount of colors. Sometimes, the colors you have in your palette are not enough. In that case, I recommend adding colors to it. In fact, it’s much easier to expand a given color palette one color at a time then to not limit yourself to one by choosing colors on the fly. When needing a new color, you can more easily compare your new color choice with an existing palette and see if it fits or change your choice otherwise. I often hear the phrase “Constraints breeds creativity” and I agree because when constrained you often end up finding creative solutions. However, another lesser known benefit of constraints is that they allow you to hide your flaws. The less constraints you have, the more ambitious you get, the higher the likelihood of going out of your comfort zone and finding yourself in an area where you do not have enough skill to pass the “professional” quality bar. For example, if you’re someone with very limited coloring skills. I would recommend sticking to a prefined color palette of max 4 colors. This way, you can more easily reach a “professional” looking result compared to if you had to pick your own colors. Well chosen constraints allows you to put forward your strengths while hiding your flaws . Another way to put it would be that constraints reduces the likelihood of shooting yourself in the foot. While I hope these tips will help you make better pixel art, it’s no secret that practice remains a big part of what you need to do to achieve good results. If you’re interested in reading more posts like this. I recommend subscribing to my Substack as to not miss out on future releases. Subscribe now In the meantime, you can check out my previous posts. Programmers are known to not have a strong suit for art related disciplines, pixel art is no exception. In this post, I’ll share 5 tips for making good pixel art from the point of view of a programmer. This is to help other solo devs coming from a programming background to make better pixel art for their games. Now, you might be wondering if I’m qualified to share tips related to pixel art? Below are two pixel art asset packs I made. If you like how they look, then the question is answered. https://jslegend.itch.io/kirby-like-platformer-asset-pack https://jslegend.itch.io/samurai-arena Here are all the asset packs I’ve made so far : Kirby like platformer asset pack (FREE) Mario-like Platformer Asset Pack ($4) 2D Pixel Art Samurai Arena ($4)

Tutorial

Design

0 views

Jim Nielsen 2 weeks ago

Tahoe’s Terrible Icons: The B-Sides

This post is a continuation of Paul Kafasis’ post “Tahoe’s Terrible Icons” where he contrasts the visual differences across a number of Apple’s updated icons in macOS Tahoe (a.k.a. the Liquid Glass update). While Paul’s post mostly covers icons for the apps you’ll find in the primary folder, there’s also a subset of possibly lesser-known icons in the folder which have suffered a similar fate. When I first got a Mac back in college, one of the things I remember being completely intrigued by — and then later falling in love with — was how you could plumb obscure areas of the operating system and find gems, like the icons for little OS-level apps. You’d stumble on something like the “Add Printer” app and see the most beautiful printer icon you’d ever seen. Who cares what the app did, you could just stare at that icon. Admire it. Take it in. And you’d come away with a sense that the people who made it really cared . Anyhow, enough reminiscing. Let’s get to the icons. I’m saving these pre-Tahoe icons for posterity’s sake because they’re beautiful. On the left is the pre-Tahoe icon, on the right is Tahoe. (Psst: I’ve got a long-running collection of icons for iOS and macOS if you want some eye candy.) Reply via: Email · Mastodon · Bluesky

Design

0 views

Playtank 2 weeks ago

Maximum Iteration

The quality of your game is directly related to the number of iterations you have time to make. The adage is that game development is an iterative process . We know we should be tweaking and tuning our game until it feels and runs great. To make it the best it can be; greater than the sum of its parts. Early on, to make sure that the features we work on are worth pursuing. An iteration can be as small as an incremented variable or as big as a complete reset of your entire game project. What iterations have in common is that the only way to get more of them is to teach yourselves the right mindset and to continuously remove anything that costs time. For the past few years, this has been at the top of my mind: how to maximise iteration . At the very highest level, you need to remove obstacles, clicks, and tools. The fewer things a developer needs to know and do per iteration, the better. Those three are what this is all about. I’ve come up with five areas where you need to optimise iteration, that I’ve obsessively built into my own pipelines. These five are what the rest of this post elaborates on: Iterating on object and state authoring means creating new objects and states and connecting them to data. A character that can roam, shoot, and take cover, and has MoveSpeed, TurnSpeed, and Morale, perhaps. This is one of those things where many developers will get used to how their first engine does things and forever see it as the norm. But most tools for object authoring are actually quite terrible (in my opinion), and are also highly unlikely to match your specific needs. They are far more likely to present you with hoops to jump through and prevent you from achieving fast iteration. It’s not unusual for getting a new object into a game to take hours and involve multiple people. Particularly if the game’s pipeline has grown organically over several years of production. Where you only had to add a single collision capsule at first, maybe you must now add a full ragdoll, two different sets of hit capsules, IK targets, and a bunch of other things before the new asset works as intended. Some of which has to be created manually. Forget one step, and your game may crash or exhibit weird results. This is a big threat to iteration. Maybe the biggest. So if you can, you should make your own tools for object authoring that are perfectly suited to your needs, require as few steps as possible, and waste as little time as possible. Or use a tool that’s specifically made for exactly the thing you need, if you can find it. I tend to think of objects in systemic design as Characters, Props, and Devices. This is not in any way strict, it’s only what my favorite designs tend to need. If you are working on a grand strategy game, a puzzle game, or something else, the nature of your objects may vary. The key to object authoring is variation. A lamp is not the same thing as a crate or a human, but they should be able to interact in interesting ways. To make them interact, you need to be able to vary them easily and then hand off responsibility to the game’s systems in a predictable way. Something that can’t be stressed enough is to always set working defaults for all of your objects. Make sure that objects work out of the box so iteration can begin immediately. Few things waste more time than “oops, forgot the flag that did the thing.” The most intuitive way to represent objects is to use objects, unsurprisingly. A Character can be expected to do certain things and a Door will do other things. Enemy and Player can now inherit from Character and they may make use of a Gun or a Broom depending on the kind of game you’re making. With this setup, authoring objects is no harder than inheriting from the right class and then tweaking the numbers. This is how Unreal Engine is used by many teams. But this gets cumbersome if you want a character that can fly or to utilise the dialogue system in a character but for something that cannot move. Or maybe the spline following that characters have, but now for a train car. Authoring with object-oriented systems seems intuitive but doesn’t handle exceptions well. Everything now needs to be a character if it wants to access certain things, and designers will have to learn the intricacies of all the objects in the game before they can truly begin iterating. If you want your object to collide with things in a physics simulation, you add a Collider. If you want it to move on a flow field, you add FlowFieldMove. The sum of an object’s components dictates its behavior. This may use many different types of component setups, but the two most common are GameObject/Component (GO/C) and Entity Component System (ECS). Both Unreal and Unity uses the first, but in very different ways. Both Unreal and Unity also provide ways to use the second, but in ways that are mostly incompatible with the first. Conceptually, component-based object authoring is great. In practice, it tends to be a deep rabbit hole of exceptions and flawed component combinations that have grown organically through an engine’s lifetime. Most game engines today are data-driven at some level. You plug data in, it gets compiled into an engine-friendly format, and voila: the engine knows what to do. The data is picked up by a renderer, physics engine, or something else, and things simply happen just the way they are supposed to because the data is clear enough to just chug along. Like feeding coal into a steam engine. With a data-driven approach, you will usually be collecting all that data and bundling it up using authoring tools. Bring in the mesh asset, animate it using animation assets, play some sound assets on cue, etc. The data itself will drive the process. For example in a “target-based” setup, where one piece of data activates another which activates a third, etc., until the game level or other logic has run its course. You need ways to define how something goes from Alive to Dead, or when something should be Idle instead of Moving. This layer of authoring and iteration is very rarely straightforward, and parts of it are almost always deep down in the code for your game. This is bad. So let’s discuss how to make it not bad, and how to open up your game for more direct rules authoring through state transitions. If my use of the word “state” in this post gets confusing, you can look into the state-space prototyping post to see what I mean. This is not standard jargon used by all game developers, but it is a key part in my own framework. A good state authoring tool allows you to list which states an object can be in, where it can collect changes from, and how it behaves in relation to other objects and their state. Just to be clear: this doesn’t have to be complex at all. It can be enough to list the actions an entity can use and then leave it to other systems to actually select actions. Take a look at the An Object-Rich World post if you are curious about other models for working with permissions and restrictions. The most important element of permissions and restrictions is predictability . There are many cases where our games become interconnected in ways that are not immediately visible. For example, when you say that a character’s ability to Move has been restricted due to a state, you may have to manually add this to multiple places. Perhaps the sound, animation, and head-bobbing system also need to be paused separately. This is extremely bad, because it means both that you will get unpredictable results and that you will often have to revisit the same changes. A specific state is only relevant for a particular object. A generic state can be used by any object sharing the same characteristics. Think of the idea of spotting something, for example. A sensor picking up that an object can be seen. If a player is going to spot something, this needs to be specific , since the player’s avatar, unlike a NPC avatar, will generally have a camera attached to it. So to check if the player spots something, we can use the camera’s viewport to determine if the thing is on-screen or not. A generic version of the same thing could instead use the avatar’s forward vector, an arbitrary angle, and perhaps a linecast, to determine if the object can be seen. This could be used by any avatar, player or otherwise, and would probably be accurate enough if your game doesn’t need more granularity. An exclusive state is the only state that can be run at a given time, whereas an inclusive state also allows other state to run alongside it. Parallell states are made to run at the same time as each other and may therefore not poke at the same data, or you could get unpredictable results. A state is conditional if it only activates based on preset conditions. It’s your if-then-else setup. Conditionals will often need considerable tweaking, and if you’re not careful in how you build such systems, they can turn into a tangled mess. Just like nested ifs. Common ways to handle conditional states are predicate functions, tags, flags, and many of the other things brought up in the A State-Rich Simulation post. Preferably, setting or changing conditionals should be just a click or two, and it should respect the type of data separation mentioned earlier. When a game has multiple dynamic sources for conditions, it quickly gets complicated. For this reason, your tools should provide debug settings for visualising where conditions are coming from, and you can also log everything that gets triggered by certain conditions during a session. A state is injected when it’s pushed into an object. This can follow any number of systemic effects , from straightup addition to slightly more granular propagation . Common points in a game simulation for state to get injected are collision events, spawning or destruction, proximity, spotting, and various forms of scripted messaging. This means that having a solid system for defining such injections is a great starting point for how transitions will work in your game. If you have the concept of a Room, for example, this Room may keep track of what’s inside of it and then propagate that knowledge to anyone visiting the room. Objects would then inject their presence into the room, while the room would inject relevant state into the objects in turn. An explicit conditional state is something like the Idle state pushing a Move state onto an internal stack because move vector magnitude is higher than zero. These are the only circumstances where Move will ever happen, making it an explicit transition. A dynamic state would be something like a gunshot killing you by injecting the Dead state. This is a dynamic transition because it can happen at any time, and beyond any restrictions on the injection itself (ammo, aiming, etc.), you won’t be defining anything in advance, and you’re not really waiting for it to happen. It happens when it happens, or it may not happen at all. A state is timed if it remains active for a limited time. It can also loop over a given duration and either bounce back (i.e., from 0 to 1 back to 0) or it can reset and repeat. The current value of the timed state is often referred to simply as T and should be a normalized (0-1) floating point number. This type of state is extremely handy, and you will want to tweak how the T value output gets handled in as many varied ways as possible. You want to be able to use curves, easing functions, and all thinkable different kinds of interpolation. Timed state can be used to achieve anything from a Thief -style AI sense of “smell,” to a menu blend, to an animation system, to reward pizzazz. It’s the perfect type of state for an interstitial and is where you will be able to do much of your polish. A state is interstitial when it’s added between other states without affecting them beyond the delay this may cause. Screenfades, stop frames, and sound triggers, are some examples of this. Objects and states will be defining the game at its highest level. But you will also want to change the rat catcher’s catching range from 2.3 to 2.5 and maybe add an additional key to a curve to make a fade-in smoother. It’s been mentioned before, but may be worth repeating: you should separate data from objects from the very beginning of your project. Every second you can avoid having to navigate the jungle of files in your project is a second gained towards additional iteration. Remember: remove clicks and remove tools. Many games will expect either a database approach (“spreadsheet specific,” in Michael Sellers’ terms), or they will have a hard connection between an object and its data. But a good data authoring tool is either integrated with the game engine or is an established external tool, such as a spreadsheet or database, that has a single-click or dynamic export/import process into the game. Many games still to this day keep data hard-coded into their compiled executables. This can be done for security or obfuscation reasons, out of habit, or because the engine used for a certain game is structured that way. For a small game with simple data, this is rarely an issue. You can make your changes, recompile, and then test, within seconds. But for bigger or more complex projects, it can have a cascading effect on iteration complexity. It also forces you to rely on programmers even for changes that have nothing to do with game logic or code. If you can avoid this, do so. It doesn’t matter if a compile takes five minutes, it’ll be stealing those five minutes over and over again. It will also decrease the number of iterations you can make. Issues with compiled data are not new. One common way to avoid some of them is to use lightweight text files that can be loaded and interpreted at runtime. This can be done in one of two ways. You can construct data this way . The below is a small example of this, where Lua was used to package information about different sectors in a space game. In this case, a sector has details about which other sectors the player can travel to, which pilots are present in the sector, and which stations and colonies can be visited. This is information that could’ve been hardcoded into the client, but this way it’s made available at runtime and much easier to iterate on. You can build logic this way . The next example is also Lua, but is a narrative sequence from the same space game. By exposing gameplay features to Lua, it becomes possible to script these sequences that can be loaded and parsed by the engine on demand. One benefit of this is that you can rewrite the script, make the engine reload the data, and then test within moments of making the change. If there’s such a thing as a standard today, it’s to store your data in a database. This database may live on a proprietary server owned by the developer or publisher, or it can utilise something in the cloud, like Microsoft Azure or Amazon Web Services (AWS). It can also be an offline database that you store with your game client much like a script. A database forces you to decouple data from objects and allows live editing of data (if in the cloud). Most modern live service games do this for some of its data, if not all, as it makes it a lot easier to respond to community feedback and fix data-related issues. Planning how you structure your data before a project begins can save you many headaches. If you want to do MoveSpeed, you could have a MoveSpeed baseline multiplier at 1.0, each object could have a MoveSpeed attribute of maybe 10-20, and gear or other props could then add their own MoveSpeed modifiers on top as additions, multipliers, cumulative multipliers, or some other thing. You’d get something like MoveSpeed = Baseline * (Attribute + Modifier(s)) . If you manage to separate these from their objects you can mix things up for any reason you want without ever touching or even looking for the objects ever again. The amount of time this saves for more iteration can’t be overstated. (Again: remove clicks, remove tools.) Maybe you want to modify Baseline based on difficulty, so that MoveSpeed is 1.5x on Easy, but only 0.75 on Hard. Or go in there and double the MoveSpeed attribute for all enemies that have the Small trait. With this type of separation, all of those things can suddenly be done in seconds. This makes everything from bulk operations to conditional exceptions a lot easier to make and therefore to iterate on. A change set is a collection of changes made to your existing data. You can look at it as a changelist or commit in version control. Bundling variables into change sets is a handy way to keep track of what you are doing and makes it easier to compare one change to another. Change sets really come into their own if you can combine them, turn them on/off, and provide more than one at a time. Over time, these sets can become like a log for your earlier tweaks, creating a kind of tweak history for your game’s design. To know how any iteration works out you need to play it. But it’s not enough to merely play as you usually do. You need to compare changes and report when something doesn’t work out. Even as a solo developer, a solid reporting tool can be the difference between fixing problems and shipping with them. This is where your change sets from before will work their magic. Let’s say you made a “goblin damage debuff” change set where you decreased how much damage the goblin dealt by half, and you now go into your change set tool to activate that change set. Or you tell external playtesters to play once with and once without the change set. You can suddenly talk about balancing the same way you’d talk about feature implementations. I encounted Semantic Versioning during my first mobile game studio experience, at Stardoll Mobile Games. I’ve stuck to it ever since. The summary for Semantic Versioning is so simple, yet so powerful: “Given a version number MAJOR.MINOR.PATCH, increment the: This is a convenient way to plan your assets. The Patch version can be automatically incremented whenever you build your game to identify each change and you can regulate when the Minor and Major version must be incremented. For example, you can plan that you only release a new Major when you are releasing new content and a Minor when features are added or changed. At Calm Island, we used to maintain one Dev and one Stable branch. The latter meant we could always show the game to any external stakeholders, even if it may have been an older build. The stable version was also the one deployed to stores after final validation. The idea to always keep your game playable may sound self-explanatory, but good processes for this are uncommon. Many studios still use a single main branch for everything and when a deadline looms the only way to safeguard its health is to enact some kind of commit/submit stop where no one is allowed to push anything that risks the playability of the build. This often results in a rush of new code and content right after the stop is lifted, that almost always breaks something and may take days or weeks to resolve. A common issue with playtesting is that you need to jump through hoops before you can test the thing you’re actually working on. This can be because you need to launch the game, go through the splash screen, load the right level, noclip or teleport to the right place, etc., before you actually play . If your game is unstable (see Always Playable above), this can be further exacerbated by crashes or bugs that are not yours to fix. To avoid this it’s important to be able to do targeted testing. Using isolated environments, such as a “gym” level for movement testing, and testing exactly the thing you just tweaked or implemented without any distractions. You need to be able to mix and match both systems and change sets in your game, to iterate as much as possible. Play without the enemy AI running, no props spawning, or with that goblin damage debuff or double move speed turned on or off. You can look at this like the layers in Photoshop, where you can turn things on or off so they don’t impact your testing when you need to test something specific. Once you have a modular setup, make sure that you can switch quickly and easily between different modules as well. Make them incerchangeable. If you need to test playing against only a single goblin, but that goblin can’t move, and you have only torches and stale bread; then it should be as few clicks and tools involved as possible to do so. Once the data is separated, you can take it one step further: you can remove entire segments of your game and isolate iteration and testing to retention loops or other longterm systems. Think of a standard game loop. You have some inputs into each session, such as matchmaking settings or difficulty selection. This input affects how the session plays. Once the session completes, you get outputs , such as XP or treasure , that you can then reinvest into progression. This is the template for many standard game loops. Simulated state allows you to pretend that one of these steps happened without actually having to take the time to play them. You can randomise the inputs and then play, or skip the session entirely to only work on the output and investment cycle. Once you reach the modular and interchangeable iteration dream, this is quite possible. The value of this type of testing is high, since longterm systems often don’t get the testing they need simply because you must finish a real session of gameplay to get the “proper” outputs. Being able to compare different iterations to each other and choose which comparisons to make is more of a meta tool than it’s directly testing related. It’s more about comparing the results you gain from testing than the testing itself. Look at the Game Balancing Guide for some inspiration on what kinds of things you could potentially compare. If you find something that’s not great or that you want to revisit, make it easy to take notes or report to a central system; you may even go so far as to generate planning tickets from an in-engine event. Have your testers press some easy to access key combination (on controllers, maybe to hold both triggers and both stick buttons down for one second). Sometimes in a big team, the more technical tasks involved with the build and distribution process are invisible to you. You may hear about porting or signing or compliance, but you never have to deal with any of it. You happily playtest on whatever is easy and available, usually your development computer. Sometimes even inside of your development environment. The reason this happens is because your updating process is not built with iteration in mind. Builds take too long, frequently don’t work, and distributing to local devices is a hassle. Many teams “forget,” or rather downprioritise, testing on their proper target devices. One of the stranger things I’ve run into is developers who not only dislike testing on their current target platform but basically refuse. It’s so much easier to stay in your comfortable development environment indefinitely. Some studios may even resent some of their own target platforms, for example mobile platforms or consoles, because they are allowing personal opinion to affect their professionalism. But there’s really no excuse: you should always test on your target devices. Something that’s easy to overlook is to keep visible and easily copy/pasteable version information on-screen in your game. This is good for a product after launch too, so that players can provide you with more detailed information if they experience bugs or crashes. One of the first things I did in gamedev was to drive cars along a race track’s edges to make sure that the collisions worked like they should. A kind of testing that you can automate relatively easily. In test-driven development , testing and automation is already part of the thinking, and there’s really no need for game development to be different. Automate the right things, however. An automated test can’t tell you about quality. It can’t suggest design changes or warn that a player may not understand the phrasing of a dialogue line. Automate regression testing, compliance testing, integration testing, and the driving along the tracks to test collision. But don’t automate quality testing. Building for all of your platforms without having to do so manually is an essential element of game development. No amount of testing in a development environment compares to testing real builds. Automated builds are often triggered by new commits or version increments. It’s also common to have nightly builds, hourly builds, and build cadences based on testing needs and build duration. What’s important for such a pipeline is that it can clearly say what’s going wrong by posting logs and details to the relevant people. A Slack channel, for example. What you absolutely don’t want is to put developers on fulltime duty to get builds out. Once you have a build, you need to get that build onto the right device for testing. Most devkits and software platforms allow remote connection. You can usually set up jobs to trigger automatically when a build completes and publish your game to your testing platform (or even live) without requiring any work at all. Hopefully, this post provides some food for thought on iteration and what it really means. If not, tell me every way I’m wrong in an e-mail to [email protected] or in a comment. Here’s the list: Remove obstacles . Make the process of iteration as fast as possible, by removing gatekeepers and bottlenecks. Maybe you shouldn’t go through the full approval process for a quality of life improvement, maybe your playtesters should get three separate sets of things to test instead of just one, and maybe a developer can prioritise their own tasks rather than sitting in hours-long meetings or being micromanaged. Remove clicks . I once heard the suggestion that you lose 50% of viewers with every required interaction on a website. More clicks will invite more pain points, more potential human errors, and will also lead to fewer iterations. Just imagine (or remember) not having box selection in a node tool vs having it. Remove tools . You need special skills, licenses, installation time, and more, the more tools you require. Everything in your pipeline that can be either bundled into something else or removed entirely via devops automation should be considered. Not least of all because tools development is itself a deep rabbit hole . Authoring objects and data. Transitioning objects between states. Tweaking and rebalancing data. Testing and comparing iterations. Updating the game for testing and distribution. For object-oriented authoring: clearly visualise what an object can (and can’t) do based on its inheritance; don’t hide logic deep into a dropdown hierarchy. For component-based authoring: make non-destructive tools with opt-in as the default rather than opt-out . Provide good error messaging for when requirements are not met. For data-driven authoring: provide clear debug information and visual representations for where data is coming from, when, and what it allows. Make it clear what data is expected where, so no steps are missed. Make it easy to list states and transitions per object. Provide state transition information with data reporting, so that you can keep track of all the whens and whys. Make states have meaning; if a state says that an object cannot move, this should be definitive. Differentiate between Specific and Generic states, so that you will never accidentally add state to an object that won’t work. Set clear guardrails between Exclusive, Inclusive, and Parallell states. Plan what you need each state to be able to do and where to get its data. Visualise which conditions apply at a given moment and why. Show when conditions are unavailable and why. Log transition changes and which conditions made them change. Show when, how, and from where a state injection occurs. Make it clear which explicit states are running at any given time. When dynamic state is triggered, make all of its relevant overrides predictable and singular: it should always be enough to turn something on or off once . Provide visualisations of start and end positions for timed states. Allow developers to scroll timed states manually to preview them. Allow states to resume after interruption, so that you can use interstitials in a non-destructive way. Separate your data into logical containers, such as Baseline, Attribute, and Modifier. Bundle collections of changes into change sets . E.g., “double move speed.” Identify change sets modularly, so you can test more than one thing at a time. MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes” Maintain clear versioning, even if just for yourself. Make sure that you can always play a recent version of your game. Provide shortcuts and settings that let you avoid time sinks. Make it easy to choose what to test. Make it clear what is being tested. Make your systems modular. Make modules easy to toggle. Allow testers to easily switch out and modify what they are testing: anything with the same output should be able to tie into the correct input. Make it possible to simulate the systems without running them. Show the data; show comparisons. Make it easy to file bug reports and provide feedback without leaving your game. Integrate screenshot tools and video recording. Test on target devices. Test your lowest spec targets. Make version numbers visible in all game builds, including release. Automate functionality testing, but not quality testing. Building the game automatically and get new builds continuously without requiring manual intervention. Remove all obstacles for build distribution: make it a single click (or less) to get a functional build to play on the right device. For object-oriented authoring: clearly visualise what an object can (and can’t) do based on its inheritance; don’t hide logic deep into a dropdown hierarchy. For component-based authoring: make non-destructive tools with opt-in as the default rather than opt-out . Provide good error messaging for when requirements are not met. For data-driven authoring: provide clear debug information and visual representations for where data is coming from, when, and what it allows. Make it clear what data is expected where, so no steps are missed. Make it easy to list states and transitions per object. Provide state transition information with data reporting, so that you can keep track of all the whens and whys. Make states have meaning; if a state says that an object cannot move, this should be definitive. Differentiate between Specific and Generic states, so that you will never accidentally add state to an object that won’t work. Set clear guardrails between Exclusive, Inclusive, and Parallell states. Plan what you need each state to be able to do and where to get its data. Visualise which conditions apply at a given moment and why. Show when conditions are unavailable and why. Log transition changes and which conditions made them change. Show when, how, and from where a state injection occurs. Make it clear which explicit states are running at any given time. When dynamic state is triggered, make all of its relevant overrides predictable and singular: it should always be enough to turn something on or off once. Provide visualisations of start and end positions for timed states. Allow developers to scroll timed states manually to preview them. Allow states to resume after interruption, so that you can use interstitials in a non-destructive way. Separate your data into logical containers, such as Baseline, Attribute, and Modifier. Bundle collections of changes into change sets. E.g., “double move speed.” Identify change sets modularly, so you can test more than one thing at a time. Maintain clear versioning, even if just for yourself. Make sure that you can always play a recent version of your game. Provide shortcuts and settings that let you avoid time sinks. Make it easy to choose what to test. Make it clear what is being tested. Make your systems modular. Make modules easy to toggle. Allow testers to easily switch out and modify what they are testing: anything with the same output should be able to tie into the correct input. Make it possible to simulate systems without running them. Show the data; show comparisons. Make it easy to file bug reports and provide feedback without leaving your game. Integrate screenshot tools and video recording. Always test on target devices: no amount of emulation will ever compensate for real qualitative testing. Have as many diverse target devices available as financially and physically possible. Test on target devices. Test your lowest spec targets. Make version numbers visible in all game builds, including release. Automate functionality testing, but not quality testing. Building the game automatically and get new builds continuously without requiring manual intervention. Remove all obstacles for build distribution: make it a single click (or less) to get a functional build to play on the right device.

Gaming

Programming

Design Lua

0 views

Brain Baking 2 weeks ago

Thumbs Up 👍

Don’t you hate it when that happens? You compose a targeted question, re-iterate the sentence a few times to make sure it is easy to interpret, press send, only to get a thumbs up in response? How should you even interpret that? Is that an ironic sure thing buddy go ahead I’ll revert your changes behind your back anyway ; is that a honest go for it! ; is that a whatever, no time right now but here’s something telling you I’ve read your thing ; or is that a too long didn’t read ? I don’t know, do you? Clear and effective human communication is one of the hardest things to get right. The widespread adoption of emojis only made the problem worse. Instead of adding context, by, you know, using words, like these, emojis manage to strip even more context, sometimes paradoxically by adding layers of confusion. Isn’t a thumbs up a universal sign of good! ? It’s not, as I’ve seen it being used and abused in ways I would never ever dare to stick out my own thumb, like I would probably never Roll On the Floor Laughing when sending ROFL. Shut up boomer, that’s also being replaced by an emoji. I know, I just proved my point. And I’m not that old (yet). You won’t find any usage of emojis in Brain Baking articles because I not only think they’re ugly or they form a danger to our ability to interpret longer texts, but also they induce ambiguity that always leaves me dazzled. Here’s some random proof why emojis just don’t work. Oh that’s what you meant! : reducing emoji misunderstanding by Tigwell and Flatla (2016—that’s almost ten years ago!): […] the purpose of the emoji was often misunderstood, e.g., “To me that looks like a nervous face but a lot of people use it as a really happy or excited face” This gets worse in cross-cultural communication according to Cominsky. It’s not just a cross-cultural problem, it’s also a generational problem: a study by Zahra and Ahmed revealed that emojis such as thumbs up, crying laughing and skull are more likely to cause mix-ups between generations . Or how about surrounding the emoji with textual context in order to reduce potential confusion? That was disproven by Miller et al. in Understanding Emoji Ambiguity in Context : The Role of Text in Emoji-Related Miscommunication: […] we found that our results do not support the hypothesis in prior work: when emoji are interpreted in textual contexts, the potential for miscommunication appears to be roughly the same. Guess what, Wang et al. found out that emotioanl emoji elicits are being abused by social media marketeers in order to increase customer engagement. Digging further specifically into thumbs-up emoji research, Bates writes about the recent court case recognising the thumbs-up emoji as having indicated contractual agreement, concluding that: Perhaps it is best that communication with icons stays within three general settings: (1) A highly contextualized environment, in which a limited number of symbols are to be clearly understood, as with road and airport signage, warning labels, and computer interfaces; (2) Interpersonal communication—private exchanges often prioritizing the establishment and maintenance of good relations; (3) Internet postings meant for public consumption (e.g., social media comments). A big thumbs up, Bates! See, that was easy, right? The last piece of research I’d like to share here is that of Shandilya et al. on using non-contextual communication in virtual workspaces like Slack and Google Chat. It looks like new employees first have to read between the lines and learn the intricate interpretation details of the micro-culture, sometimes even differing from team to team within the same company. Before we can send out a thumbs up, we first have to decode how others around us are using and interpreting it. Which might differ greatly from your habitually usage in causal app messages to friends. Fellow blogger Horst Gutmann recently pointed to another study on the connection between emojis and personality traits : heavy reliance on emojis seems to shape our perceived image—and not in a very good way. The biggest problem, however, is not using the thumbs-up emoji as part of a message: it is using the thumbs-up emoji as a reaction in itself—the recent phenomena called reaction emojis . A reaction is not a response. Our languages have words to form an expression, let’s make use of them. I sometimes receive conversation duds like that as an answer to three sentences of mine explaining how things are going. What am I supposed to do with that? If you’re not interested in knowing how I’m doing then don’t bother asking? My wife has one particular friend who simply replies all his messages with a thumbs up reaction. I would be inclined to stop exchanging messages at all with such a person. I ROFL-ed (how am I supposed to conjugate this?) when I read MaliciousDog’s opinion on emoji reactions on Reddit: They break the text consumption flow. In a coherent text, an emoji is somewhat like a fart in a middle of a nice song . It may be fun by itself or in an appropriate context but not everywhere. Like a fart in a middle of a nice song. By Wouter Groeneveld on 10 November 2025. Reply via email .

Culture

Design Communication

0 views

Raph Koster 3 weeks ago

Game design is simple, actually

So, let’s just walk through the whole thing, end to end. Here’s a twelve-step program for understanding game design. There are a lot of things people call “fun.” But most of them are not useful for getting better at making games, which is usually why people read articles like this . The fun of a bit of confetti exploding in front of you, and the fun of excruciating pain and risk to life and limb as you free climb a cliff are just not usefully paired together. In Theory of Fun I basically asserted that the useful bit for game designers was “mastery of problems.” That means that free climbing a cliff is in bounds even though it is terrifying and painful. Which given what we already said, means that you may or may not find the activity fun at the time! Fun often shows up after an activity. There’s neuropsych and lots more to go with that, and you can go read up on it if you want . Anything that is not about a form of problem-solving is not going to be core to game systems design . That doesn’t mean it’s not useful to game experience design, or not useful in general. Also, in case it isn’t obvious – you can make interactive entertainment that is not meant to be about fun . You can also just find stuff in the world and turn it into a game! You can also look at a game and choose not to treat it as one , and then it might turn into real work (this is often called “training”). This rules out the bit of confetti . A game being made of just throwing confetti around with nothing else palls pretty quick. Bottom line: fun is basically about making progress on prediction. There are a lot of types of problems in the world . It is really important to understand that you have to think about problems games can pose as broadly as possible. A problem is anything you have to work to wrap your head around. A good movie poses problems too, that’s why you end up thinking about it long after. You can go look at theorists as diverse as Nicole Lazzaro, Roger Caillois, or Mark LeBlanc for types of fun. You’ll find they’re mostly types of problems , not types of fun. “I enjoy the types of problems that come from chance” or “I enjoy the types of problems that come from interacting with others” or whatever. This is not a bad thing. This is what makes these lists useful. Your game mechanics are about posing problems, so knowing there’s clumps of problem types is very useful. In the end, though, a problem is built out of a set of constraints. We call those rules, usually . It also, though, has a goal. Usually, if we come across a set of rules with no problem, we just play with it, and call it a toy. Building toys is hard! Arriving at those rules and constraints to define a nice chewy problem is very challenging. You can think of a toy as a problematic object, a problem that invites you to play with it. On the other hand, it’s not hard to turn a toy into a game, and people do it all the time. All you have to do is invent a goal. We shouldn’t forget that players do so routinely. Building a toy is an excellent place to start designing a game. Bottom line: we play with systems that have constraints and movement, and we stick goals on them to test ourselves. Games are machines built around uncertainty . Almost all games end by turning an uncertain outcome into a certain one. There’s a problem facing you, and you don’t know if you can overcome it to reach that goal. Overcoming it is going to be about predicting the future. If there’s one thing that good games and good stories have in common, it’s about being unpredictable as long as possible . (This is also where dopamine comes in, it’s tied to prediction; but it’s complicated and nuanced). If a problem basically has one answer, we often call it a puzzle. There’s not a lot of uncertainty built into a binary structure. You can stack a bunch of puzzles one on top of the other and build a game out of them (which then introduces uncertainty into the whole), but a singular puzzle isn’t likely to be called that by most people. It happens quite often that we used to think something was a game, and it turned out it was actually a puzzle. Mathematicians call that “solving the game.” They did it to Connect Four – and you did it to tic-tac-toe, when you were little. Good problems for games therefore all have the same characteristics : A lot of very good problems seem stupidly simple, but have depths to them . Math ones, like “what’s the best path to cross this yard?” but also story ones like “For sale: baby shoes, never worn.” I recently watched a video that included the statement that “picking up sticks” is not a useful loop. Picture a screen with a single stick in the middle. The problem posed is to move the cursor over it and click it. Once you do it, you get to do it again. Guess what? The original Mac shipped with games that taught you how to move a mouse and click things. Once upon a time, mousing was a skill that was challenging; for all I know, you have grandparents who still have trouble with it. For them, it has uncertainty. For you, probably, it doesn’t. Bottom line: the more uncertainty, indeterminacy, ambiguity in your game, the more depth it will have. Now, imagine that the stick pops to a random location each time. Better, yes? The core of a loop is a problem you encounter over and over again. “How do I get the next one?” But something needs to be pushing back , that’s what makes it an interesting problem and is usually what takes it past being a puzzle. I like to say “in every game, there is an opponent.” Even it’s just physics. People talk about the core loop of a game. But there’s really two types of loops. One is what we might think of as the operational loop . This is the loop between you and the problem, it is how you interact with it. You look at it. You form a hypothesis. You poke the problem. You see a result. Maybe it was success, and you grabbed the stick. Maybe it was failure. Maybe it was partial success. You update your hypothesis so you can decide what to do next. The second loop is really your progression loop but is better thought of as a spiral . It’s what people usually mean when they say “a game loop.” They mean picking up the stick over and over. I say it’s a spiral, because clicking on the same stick in the middle of the screen over and over is not usually how we design games. That would actually be repeatedly doing the same puzzle. Instead, we move the stick on the screen each time, and maybe give you a time limit. Now there’s something you’re pushing against, and there’s a skill to exercise and patterns to try to recognize. Far more people will find this a diverting problem for a while. It’s a better game. It’ll get even better if there are reasons why the stick appears in one place versus another, and the player can figure them out over time. This matters: the verbs are in a loop. “Pick up,” over and over. But the situation isn’t. And you are learning how to reduce uncertainty of the outcome: move the mouse here and click, next move it there . That’s why it is a spiral: it is spiraling to a conclusion. It’ll be fun until it’s predictable. You can think of the operational loop as how you turn the wheel, and the situations as the road you roll over. A spot on the wheel makes a progression spiral as you move. One machine, many situations — we call these rules mechanics for a reason. Bottom line: players need to understand how to use the machine, and the point is to gradually infer how it works by testing it against varied situations. You can’t learn and get better unless you get a whole host of information . There are fancy names for each of these, and you can go learn them all . Everything from “affordance” and “juice,” to terms like “state space” and “perfect information” and very confusing contradictory uses of the words “positive” and “negative” paired with the word “feedback.” Feedback in general can, and should be, delightful. That means it’s where you get to use all those forms of fun that I threw away at the beginning. It can be surprising. It can be a juicy multimedia extravaganza. It can be a deeply affecting tragic cutscene that advances the game story. If you have too little feedback, players cannot go around the interaction loop. Picture Tetris if the piece you drop is invisible until it lands. If you have bad feedback, players cannot go around the learning loop either. Picture Tetris if sometimes your score goes down when you complete a line and sometimes it goes up. You can’t draw any conclusions about what the problem in the way of the goal actually is , in that crappy version of Tetris . Feedback needs to act as a reward to help you draw conclusions. But there’s a third mistake: you can supply a gorgeous and compelling set of feedback and not actually have a real problem under there. At minimum you’re making shallow entertainment. At worst, you are building exploitative entertainment. People will be willing to go along with pretty simple and pretty familiar problems as long as the feedback is great. Bottom line: show what you can do, that you did it, what difference it made, and whether it helped. If you are trying to design and are thinking of a specific problem scenario you are not doing game systems design. You are doing level design. “How to multiply numbers” is a problem. “What is 6 x 9” is not a problem, it’s content . Now consider the game of Snake , or Pac-Man . They are also games where the core loop is picking up a stick. The difference is that something is an obstacle to you picking up the stick: you get longer when you pick up the stick, and can crash into yourself. You have to avoid ghosts as you gather the stick. How long you are in Snake is a different situation . Where the apple to eat is located is a different situation. To be specific, you have the same problem in different topology. Where you are relative to the ghosts, and which dots are left, and what directions you can go in the maze are different situations in Pac-Man . You want the verbs you use in the loop to end up confronting many many situations. If your verb can’t, your core loop is probably bad. Your core problem (aka your core game mechanic) is probably shallow. What you want is to be able to throw increasingly complex situations at the player. That’s how they climb the learning ladder . Ideally, they should arrive at interim solutions (lots of words for that, too: heuristics, strategies) that later stop working . Pac-Man actually got solved, by the way! That’s why Ms. Pac-Man was invented. Sometimes, the way to escalate is to change the rules, and that’s what Ms. Pac-Man did. It did it by adding randomness, and in fact using randomness is one of the biggest (and oldest) ways to create situation variation in games. Bottom line: escalate the situations so that theories can be tested, refined, and abandoned. Since we can put all this this down very much to problem solving and learning and mastery, it means we can steal a whole bunch of knowledge from other fields. People learn best when they can experiment iteratively, which we also call “practicing.” That’s why loops make sense. There’s a lot of science out there about how to train, how to practice (and also a lot of educational theory that overlaps hugely), and your game will be better if it follows some of those guidelines. People learn best when the problem they are tackling is right past the edge of what they can do . If it’s too far past that edge, they may not even be able to perceive the problem in the first place! And if the reverse is true and they see a solution instantly, they’ll either be bored, or they might just do that over and over again and never develop any new strategies and not progress . There’s an optimal pacing shape. It looks just like what you see in your literature textbooks when they diagram tension, or whatever: sort of like a rising sine wave. You start slow, then speed up, hit a peak challenge, then back off a bit, give a breather that falls back but not all the way, then speed up… we have conventions for what to put at those peaks (bosses!). But what matters is the shape of the curve. You need to structure your game so that you push players up. They might need to climb the curve at different paces, which is why you might also have difficulty sliders. They might not be capable of getting all the way to the top, and that’s okay. You also need to pace to allow room for everything that isn’t mastering the problem — such as having fun with friends socially . But at the same time, things to do in the game need to come along at the right pace too! Bottom line: Vary intensity and pressure, give players a chance to practice and moments to be tested . Remember the game about clicking on a stick that appeared at a random location on screen? That’s also a rail shooter. You move the mouse and click on a spot in 2d space. Which is also not that different from an FPS — only now you move the camera, not the cursor. Almost no games are made of only one loop. Instead, we chain loops together – complete loop A, and it probably outputs something that may serve as a tool or constraint on a different loop. An FPS has the problem of moving the camera (instead of the mouse) to click on the stick. It also has a loop around moving around in 3d space. Moving around is actually made of several loops, probably, because it may be made of running and jumping and spatial orientation. Those are all problem types! We speak sometimes of value chains : that’s where one loop outputs something to the next loop. We speak also of game economies , which is what happens when loops connect in non-linear ways, more like a web. This is not the sort of economy where you are simulating money or commerce. Instead it’s a metaphor for stocks and flows and other aspects of actual system dynamics science. In this view, your hit points is a “stock” or, if you like, a “currency” you spend in a fight. Games nest fractally, they web into complex economies, and they unroll chains of linked loops. That’s why they can be diagrammed in a multitude of ways. At heart though, you can decompose them all into those elemental small problems, each with an interaction loop and a learning loop centered on that problem. Bottom line: build small problems into larger webs, and map them so you understand how they connect. The common question is “okay, so how do I design a problem like that?” And that is indeed the unique bit in games, because the other items here are common to lots of other fields. The list of possible problems is, as mentioned, enormous. This is a big rabbit hole. And once you consider that you can stack, web, and otherwise interlink problems, it means that there’s a giant composable universe of games (and game variants ) to create. Just bear in mind that because of varied tastes and experience, the diversity of the set of problems you pose is going to affect who wants to play your game. There are basically a set of categories of problems that we know work, and this is the absolute simplest version of them: These break down into a ton of sub-problems, but there are less than you think, and you can actually find lists of them . The hard part is that often they each seem so small and trivial that we don’t think of them as actually being worth looking at! They are also often in disguise: the problem behind where a tossed ball will land, and the problem of how much fuel you have left in your car if you keep driving at this speed, and the problem of when your hit points will run out given you have a poison status effect on you are the same thing . But the more of them you as a designer have wrapped your head around, the more you can combine. And you’ll find them very plastic and malleable. In fact, you could almost make a YouTube video about each one . So where do you get them? Steal them. Other games, sure, but also, the world is full of systems that pose tough problems. You can grab them and reskin them. Bottom line: not every mechanic has been invented, but a ton have. Build your catalog and workbench. In the end, the feedback layer of a game is everything about how you present it. The setting, the lore, the audio, the story, the art… How you dress up the problems can change everything about how the player learns from it, and how they perceive the problem. The exact same underlying problem can be as different as picking up sticks or shooting someone in the face, or as mentioned, the calculus problem of estimating the trajectory of a variable in a system of rates of change (the ball, the car and its gas, the hit points and poison) might be the same but dressed extraordinarily differently . When you think about how you dress up the problems, you are in the realm of metaphor . You are engaging in painting, poetry, and music composition, and rhetoric, and the bardic tradition, and all that other humanities stuff. This is a giant and deep universe for you as a designer to dive into. A lot of this stuff gets called “game design,” but then again, we also often say that a given game designer is a frustrated moviemaker, too. It is really easy to create an experience that clashes with the underlying problems it is teaching. There are fancy critical terms for this. You also need to be very conscious about whether you are building your game so that you are telling the player a story, or so that the player can tell stories with your game . So the takeaway should be: this stuff is deeply, deeply synergistic with the “game system” stuff that this article is about, but they are not the same thing. And games is not the best place to learn how to do these things. Those other fields have much longer traditions and loads of expertise and lessons. They won’t all apply to the issue of “how do I best dress up this collection of problems” but most of them will. It does not frickin’ matter if you start out wanting to make interesting problems, or if you start out wanting to provide a cool experience . You are going to need to do both to make the game really good . Bottom line: game development is a compound art form. You can go learn those individual arts and the part unique to games. Researchers have done a ton of studying “why people play games.” This gets called “motivations.” Motivations are basically about people’s personal taste for groups of problems and how those problems are presented, and characteristics of those problems and the situations in which you find them. Some people like problems where you destroy stuff. Others like problems where you bond with others. Some have trouble trusting other people. Others want to cooperate. Not everyone likes the same sorts of problems or the same sorts of dressings. Some of this is down to personality types, some of it is down to social dynamics, how they were raised, what their local culture is like, what trauma they have had, and countless other psychological things. That’s why one fancy term for this is psychographics . The big thing is, it’s not enough that the problems need to not be obvious to you, and also not be baffling to you. They also have to be interesting to you. What problems fit in that range is going to depend entirely on who you are, what your life experiences have been, what skills you have, and even what mood you are in. Picking motivations and selecting problems based on them is a great way to design. But motivations are not the same thing as fun. They’re a filter, useful in marketing exercises and in building your game pillars (which is an exercise in focus and scope). Scientists have spent a bunch of time surveying tons of people and have arrived at all sorts of conclusions that map people onto reasons to play and from there onto particular problems. If you start with motivations, then you can go from there to types of problems, types of experience, and even player demographics. And then, if you want problems that are about interacting with people, well, there’s lists of those. If you want problems that are about managing resources, or solving math issues, there’s lists of those too. Bottom line: no game is for everyone, so you will make better games if you know who you are posing problems for. I run into game developers who do not understand the above eleven steps all the time . And understanding all eleven is more valuable than building expertise in just one, because they depend on one another. This is because getting any one of the eleven wrong can break your game. The real issue is that each of these eleven things is often multiple fields of study. And yeah, you do need to become expert in at least one. To pick one example, some of us have been working out the rule set for how you can link loops into a larger network of problems for literally over twenty years. Others have spent their entire career doing nothing but figuring out how best to provide just the affordances part of feedback . So game design is pretty simple. But the devil is in details that are not very far below the surface. It’s fairly easy to explain why something is fun for an given audience. It is much harder to build something new that is fun for an arbitrary person. That said, every single one of those fields has best practices, and they are mostly already written down. It’s just a lot to learn. Put another way — every single paragraph in this essay could be a book. Actually, probably already is several. Bottom line: each of these topics is deep, but you want a smattering of all of them. Some of you may not like this deconstructive view on how games are designed. That’s okay. Personally, I find it best to poke and prod at a problem, like “how do I get better at making games?” and treat it as a game. And that’s what I have done my whole career. The above is just my strategy guide. Someone else will have different strategies, I guarantee it. But I also guarantee that if you get better at the above twelve things, you will get better at making games. This is a pragmatic list. And it will be helpful for making narrative games, puzzle games, boardgames, action games, RPGs, whatever. I breezed through it, but there are very specific tools you can pick up underneath each of these twelve things. It really is that simple, but also that hard, because that’s a frickin’ long list if you want to actually dive into each of the twelve. What that also means is that people designing games fail a lot at it . You might say, “can’t they just do the part they know how to do, and therefore predictably make good games?” No, because players learn along with the designers. If you just make the same game, the one you know how to make, the players get bored because it’s nothing but problems they have seen before and already have their answers to. Sometimes, they get so bored that an entire genre dies. And if you instead make it super-complicated by adding more problems, it might dissolve into noise for most people. Then nobody plays it. And then the genre dies too! Game designers will routinely fail at making something fun. When the game of making games is played right, it is always right outside the edge of what the designers know how to do. That’s where the fun lives, not just for the designer, but also for their audience. That’s it, the whole cheat sheet. That’s it. Hope it helps. They need to have answers that evolve as you dig in more – so they need to have depth to them. Your first answer should only work for a while. There might be many paths to the solution, too. This is why so many games have a score – it helps indicate how big a spread of solutions there are! They need to have uncertain answers. (When you’re little, this universe is a lot larger than it is when you’re older – peek-a-boo is uncertain up to a certain point!). The problem should be something that can show up in a lot of situations. You need to know what actions – we usually call them verbs — are even available to you. There’s a gas pedal. You need to be able to tell you used a verb. You hear the engine growl as you press the pedal. You need to see that the use of the verb affected the state of the problem, and how it changed. The spedometer moved! You need to be told if the state of the problem is better for your goal, or worse. Did you mean to go this fast? Mathematically complex puzzles Figuring out how other humans think Mastering your body and brain

Gaming

Design

0 views

Hugo 3 weeks ago

Can You Still Learn to Draw in the Age of AI?

I started drawing as a teenager because I loved comics and several people around me worked or had worked in bookstores. I copied everything I could—comic book characters, European BDs. I got good at copying, but without mentors, I eventually plateaued. Then studies took over, professional life began, and I stopped drawing. Here are some of the last drawings made in 1999 : ::Gallery --- photos: - src: "https://writizzy.b-cdn.net/blogs/48b77143-02ee-4316-9d68-0e6e4857c5ce/1762035986119-latlktl.jpg" alt: "Magneto" - src: "https://writizzy.b-cdn.net/blogs/48b77143-02ee-4316-9d68-0e6e4857c5ce/1762035990247-zmqo757.jpg" alt: "Xmen" - src: "https://writizzy.b-cdn.net/blogs/48b77143-02ee-4316-9d68-0e6e4857c5ce/1762035995600-0vi7vkk.jpg" alt: "Witchblade" --- :: ## The golden age of Youtube But in 2018, I thought we were living in amazing times. There were now tons of online resources to learn from. I found hundreds of talented artists on YouTube who reignited my desire to learn. I finally had everything at my fingertips to understand the basics I'd missed when I was younger: the Loomis method, proportions, perspective, inking techniques... So [I started again](https://www.instagram.com/corwinhakanai/). I drew traditionally with pencil, then ink, tried watercolor, and finally digital drawing. I felt steady progress, even though drawing is one of those skills where learning happens in plateaus. There are tough moments where you stagnate, and then something clicks and you leap forward again. ![Moon knight I drew for Inktober 2021](https://writizzy.b-cdn.net/blogs/48b77143-02ee-4316-9d68-0e6e4857c5ce/1762036626305-0pqp4c5.jpg)It was better, but I still I felt limited, especially since I wanted to write stories and tell them through drawings. The gap between being able to reproduce a drawing correctly and bringing a story to life is massive. But that's part of the game. Drawing is learned slowly, in stages. I'd learned a lot, but now I needed to tackle composition rules, master lighting, understand how to structure a story, how to chain shots to guide the reader's eye to the right place, lettering, and many other things. ## And then AI arrived. DALL-E was born in 2021. Midjourney followed in 2022. Today in 2025, these AIs are incredible at creating drawings that I still can't produce after several years of training. A professional will always be better, but only after many, many years of experience. A beginner like me is quickly discouraged by the gap between my current knowledge and the minimum level needed to at least match an AI. That’s what I call **“the AI wall”**. Digital tools got me back into drawing in 2018, but AI cooled my enthusiasm a few years later. I haven't drawn in a year. My last drawing post [on Instagram](https://www.instagram.com/corwinhakanai/) was at the end of 2023. And I'm conflicted. I see people who, on the contrary, found new motivation in it. They couldn't draw but are now able to tell a story in comic form. Overall, I could do that because the story I have in mind could use this medium. You could say it's the story that matters more than the drawing. There are plenty of counter-examples, but let's assume it's true for the sake of argument. Except I don't want to learn how to prompt an AI. It's less exciting than learning to master your line work and thinking about character design or composition. ## What about software development ? And in those moments, I draw a parallel with my job as a developer. I've reached a point where, like the professional artists I admire, AI doesn't scare me too much. I know how to use it as a tool and I'm still capable of doing what it produces. I can go faster with it, but also because I master the equivalent of the basic rules of drawing for my profession. I understand architecture, UX, security, etc. I am above the AI wall and I'm looking down from above. But what about young people entering the tech industry today who face the same AI wall I have to climb as an artist? Who's going to take the time to learn the basics? I was born in the last century. The year 2000 made me dream. There was a kind of technological mythology where we'd end up delegating all the tedious tasks to machines so we could focus on what interests us most: discussion, games, arts, creativity. And I admit I feel like we got a bit lost along the way and did the opposite. I hope I'm wrong. On the other hand, will they be just as important in the future? In the past, driving meant adjusting the dynamo, setting the choke to enrich the air-fuel mixture, cranking a handle to start the engine. I imagine you needed to know much more about mechanics than you do today. But that doesn't stop me from driving today. Cars have evolved. Computing tools are evolving too. Once AI masters all the basic aspects, won't the issue simply be knowing how to properly dialogue with an AI? In the same way that some new comic book authors can produce by prompting an AI. In fact, their job has changed compared to their equivalents from 20 years ago. And it's quite likely that this will be the case for software development in the future.

Design

0 views

Manuel Moreale 1 months ago

Frank Chimero

This week on the People and Blogs series we have an interview with Frank Chimero, whose blog can be found at frankchimero.com . Tired of RSS? Read this in your browser or sign up for the newsletter . The People and Blogs series is supported by Sal and the other 123 members of my "One a Month" club. If you enjoy P&B, consider becoming one for as little as 1 dollar a month. I’m Frank Chimero, I design and write from my little apartment in New York City. I’ve been doing this for a long time, mostly for technology and media companies. Other than work, I’m interested in the same things many other people are: my partner, my dog, visiting museums, movies, paintings, reading, cooking, stimulating conversation, and long walks. A lot of those have a tendency to go together, especially here in New York, which is nice. I started teaching design shortly after finishing undergrad and had a great time with it. My students and I had so many stimulating conversations in the classroom, and their questions really forced me to think about my presumptions and beliefs about design in a way I wouldn't have without the prompting. So, after class, I'd type them up and was eager to share, and thus my blog was born. Writing is generally a way to scratch an itch in my brain. Sometimes it is an annoyance or disagreement with something else I read, or responding to an idea I came across in my reading that captivated me in some way, and trying to figure out why it grabbed me. Most first drafts are brain dumps in front of the keyboard or going for a walk and using speech to text on my phone. These things are incredibly rough, and take a bit of polishing until they end up on the site, but I enjoy that process too. It’s nice to nudge, tweak, and expand on parts and feel things get stronger or more clear. I try to have some interesting reference or idea at the heart of each post I make, because it’s what I want to read. The web I am interested in is the insights and ideas of individuals. Some people will think I’m a barbarian, but I don’t think tools matter that much. I write in TextEdit. If it’s by hand, it is typically on loose copier paper and a pen I stole from a hotel. I’m sensitive to spaces and love a beautiful room and good lighting, but I think it is more worthwhile to learn how to write well in spite of the environment rather than because of it. At least, that’s what I tell myself. The trick, for me, is to seek out those beautiful places and experiences and try to hold on to the internal environment they create in me, then find ways to get it down onto the page later. Sometimes that works, sometimes it doesn’t. A few years ago I wrote a book called The Shape of Design . I’d book trains from New York City up to Albany to enjoy the views of the Hudson Valley from the train window. The trip was about 8 hours there and back home. I got so many words down, something about the momentum of the view creating a velocity in the writing. But you know what? Once I stacked that writing up next to all the other writing I did in libraries, at the kitchen table, or coffee shops, I never could pinpoint where what was written. This is going to be underwhelming. I have an off-the-rack Macbook Pro M4. There is pretty much nothing installed on it except Figma, my fonts, and just enough of a local dev environment to make my rickety Jekyll deployments. If you were to close your eyes and imagine the first five sites you’d need for work, I have those, too. I have last year’s iPhone with YouTube and NTS Radio on it. I’ve stripped most everything out. It makes no difference. I just type and typeset. I’m not certain. I have no clue how one would grow an audience in 2025 without betraying some of my values about respecting people’s attention. My current mindset is to enjoy my audience, respect them, and make no presumptions about it growing. The site either costs $60 or $0, depending on how you look at it. It’s served via Github Pages, which requires a subscription, but it also pays for other things like private repos, etc. I’ve never tried to make money with the writing on my site. Even the book I wrote is available in full online for free. This isn’t necessarily a moral stance, it is simply that the economics of it wouldn’t pay enough to justify the headspace it’d occupy. If others want to do something different, I say go for it. I focus most of my reading time on books, and most of my digital reading is happening through newsletters these days. On the blog side of things, I mostly check up on friends’ writing by manually going to their site. “I wonder what Naz is up to?” and that kind of thing. I know there is RSS, but seeing the site is half the point. You’ve already interviewed a lot of them, but I think you would get a kick going through Rob Weychert ’s obsessively maximalist life-documentation-as-blog. It is exactly the opposite of my own tendencies (“anything you don’t remember must not be that important”), and I have a lot of admiration, confusion, and respect for what he’s done. I want to take a moment to give a shout out to libraries. Librarians are god’s people. I think there is a strong ideological kinship between digital personal publishing (blogs) and libraries (self-expression, availability of information, capitalistic counterpoint, community and connection, and the overall “this is for everyone” vibe the web was born from). So, go check out your local library. Get a card, check out a book, enjoy the space, and maybe ask about what other services they have to offer besides media. Good communities come from good people and good spaces. Supporting your local library may be a way to nudge the world toward your vision of how it should be. Or it could just be a nice way to spend an afternoon. Now that you're done reading the interview, go check the blog and subscribe to the RSS feed . If you're looking for more content, go read one of the previous 113 interviews . Make sure to also say thank you to Henrik Wist and the other 123 supporters for making this series possible.

Writing

Design

0 views

Raph Koster 1 months ago

Stars Reach visual upgrades

For months now, we have been working on a big overhaul to the visuals in Stars Reach . This has involved redoing most of the shaders in the entire game, and going back and retouching every asset. We started by redoing all the plant life and flora, and we have hundreds of those assets that had to be redone. Further, they all need to grow, change in response to seasons, be able to catch fire and burn, freeze, shed leaves and die, and so on. We don’t pre-design our biomes; we derive them on the fly from the simulation based on the environmental conditions. The right plants grow in the right places based on the temperature and the humidity and the soil types. (Yes, we even have a dozen soil types). All that means that every tree you see in the game grew there , and propagates across the landscape just like real plants. Seeds fall and grow into trees, forest fires happen and so on. Further, everything in the landscape itself can be changed. Mountains can be flattened, roads built, and so on. What you see in this screenshot and the videos is all dynamic, evolving, and modifiable by players. In this picture, that cliff face can not just be climbed, it can be melted into lava. You can see an ice rim along the top — pour water on the ground there, and it freezes and you will skate on the resulting ice. We are finally at a place where we do not need to compromise on the visual quality in order to deliver the simulated living world we have had working for years now. We also have been working on improved lighting, volumetric fog and other effects. And there is more coming, such as a much improved global illumination model. Truly dark caves are on the way! Some of these things are in the game now — we’ve been slowly putting in the new assets for months — but a lot of it is still pending a big patch to the game to roll out the technical features. But we’re at the point in development where it made sense to share some of the new visuals as a teaser. Environments are well along, and we are tackling all the hard surface objects next. Then, we will redo characters and creatures too. It should all add up to a pretty significant change in the game’s style, though we are sticking to a somewhat stylized realism look since the games market is currently chock full of photorealistic games that are indistinguishable from one another. All of this is also coming with pretty significant optimizations as well, resulting in smoother framerates and general performance. Plenty more to do! I thought you might be amused to see just how far we have come, so here’s a selection of images from way back when to now. When we first announced and got pushback on the graphics, we said we would keep working on it. Well, iteration takes time. But I think it’s really cool to see the incremental steps forward over time. I know plenty of folks are probably wondering, “okay, but what about gameplay?” This update is about visuals, but there’s been quite a lot of game stuff rolled out since I last posted! Banks, player run shops, combat updates, and more. Multiple player cities have been built and destroyed this year so far, and we have even blown up a few entire planets. And coming real soon: player governments. If you want to check out the state of gameplay, there are tons of videos up on the Stars Reach Youtube channel.

Gaming

Design

0 views

The Jolly Teapot 1 months ago

October 2025 blend of links

Some links don’t call for a full blog post, but sometimes I still want to share some of the good stuff I encounter on the web. Why it is so hard to tax the super-rich ・Very interesting and informative video, to the point that I wish it were a full series. Who knew I would one day be so fascinated by the topic of… checks notes … economics? jsfree.org ・Yes, a thousand yes to this collection of sites that work without needing any JavaScript. I don’t know if it’s the season or what, but these days I’m blocking JS every chance that I get. I even use DuckDuckGo again as a search engine because other search engines often require JavaScript to work. Elon Musk’s Grokipedia contains copied Wikipedia pages ・Just to be safe, I’ve immediately added a redirection on StopTheMadness so that the grokipedia domain is replaced by wikipedia.com (even if Wikipedia has its problems, especially in French). Also, what’s up with this shitty name? Why not Grokpedia ? I would still not care, but at least it wouldn’t sound as silly. POP Phone ・I don’t know for whom yet, but I will definitely put one of these under the Christmas tree this winter. (Via Kottke ) PolyCapture ・The app nerd in me is looking at these screenshots like a kid looks at a miniature train. (Via Daring Fireball ) Bari Weiss And The Tyranny Of False Balance ・“ You don’t need to close newspapers when you can convince editors that ‘balance’ means giving equal weight to demonstrable lies and documented facts. ” light-dark() ・Neat and elegant new CSS element that made me bring back the dark mode on this site, just to have an excuse to use it in the CSS. Eunoia: Words that Don't Translate ・Another link to add to your bookmark folder named “conversation starters.” (Via Dense Discovery ) Why Taste Matters More ・“ Taste gives you vision. It’s the lens through which you decide what matters, and just as importantly, what doesn’t. Without taste, design drifts into decoration or efficiency for efficiency’s sake. Devoid of feeling .” Tiga – Bugatti ・I recently realised that this truly fantastic song is already more than 10 years old, and I still can’t wrap my head around this fact. The video, just like the song, hasn’t aged one bit; I had forgotten how creative and fun it is. More “Blend of links” posts here Blend of links archive

Design

CSS

Web Development

JavaScript

0 views

Dayvster 1 months ago

AI’s Trap: Settling for Boilerplate Over Elegant Code

We are all familiar with Picasso's "The Bull" series, in which he progressively simplifies the image of a bull down to its most basic, yet still recognizable form. Steve Jobs was famously inspired by this concept, leading him to advocate for simplicity and elegance in design and technology above countless features and excessive complexity. Distill a concept even as complex as software or UX down to its essence, and what you are left with is something beautiful and elegant that fulfills its purpose with minimal fuss. ## So Why Do We Accept Ugly Code Then? I've noticed a worrying trend in programming that, as tools around a programming language improve and automate more of our work, we increase our tolerance for boilerplate, repetitive, and frankly, ugly code. We accept it and we tell ourselves it's ok, the linter will fix it, the formatter will fix it, the compiler will optimize it, in the end it's all ones and zeroes anyway, right, why would any of this matter? Since AI has entered the equation, tolerance for boilerplate and excuses for ugly code has only increased. We tell ourselves that as long as the AI can generate the code for us, it doesn't matter if it's elegant or not. After all, we didn't write it, the AI did. So why should we care about the quality of the code? After all, we relinquished ownership of the code the moment we asked the AI to generate it for us. Now, you may not be someone who uses AI to generate code, and kudos to you, welcome to the club, however, even as someone who relatively early noticed that AI does not produce something that I could sign off on as my own work proudly and with confidence. I have engaged in the practice of using AI to generate some more tedious tasks for myself, such as just taking a JSON response from an API and asking Copilot, ChatGPT, or Grok to generate a type definition in the language I am currently working with. I work on many personal and professional projects, and I encounter different types of people and teams, some embrace AI, others shun it. However I have noticed that in teams or projects where AI is embraced or even encouraged or mandated as part of the development process, tend to produce a lot of boilerplate and a lot of very ugly inelegant code that few wish to take real ownership of, because it is not their creation they handed ownership of it to the AI and therefore abandoned the developer - code relationship that is so essential to producing quality software. ## Developers Should Love Their Code I harp on this a lot, development is a unique one of a kind blend of engineering and creative expression, those two aspects of our craft should not be at odds with each other, but should rather complement each other. When you write code, you should love it, you should be proud of it, you should want to show it off to others who can understand it and appreciate it, in essence, your way of expressing your way of thinking and how you tackle problems. I've briefly touched upon the fact that handing off ownership of your code to AI means abandoning that relationship between you, the developer, and your code. I want to expand on that a bit more. If you don't care about the code you write, if you don't love what you are doing or the creative process to solve a specific problem, you will forever lack understanding of that specific problem that you are solving. It will get solved for you by the AI, and you will rob yourself of the opportunity to learn and understand that problem on a deeper level. This is something that has kicked me in the ass a fair few times in the past, I'd get a problem to solve, think oh this is easy, draft up an initial solution solve the problem at a very superficial level and then in the coming weeks get 10 QA tickets filed against that problem because there is more to the problem than meets the eye and there are often things that you miss or do not even consider during your first implementation. AI will do exactly the same thing every single time. The difference, though, is that every time I was given a problem to solve, it resulted in fewer and fewer QA tickets because I understood and learnt from my past experiences and mistakes and knew how to approach problem-solving more effectively. AI will not do any of that, it will always solve the problem given to it at face value without any deeper understanding or context. It will not learn from past mistakes, grow, or adapt its mindset to shift its approach based on new information or insights. It will always solve the problem, and worst of all, it will never learn to understand the problem so well that it can simplify the solution down to its essence and produce something elegant. There is a certain beauty to solving a problem and all of its potential side effects in a very minimal and easily readable way. That is an ideal that I strive for in my own work, and I encourage you to do the same. Love your code, be proud of it, and strive for elegance over boilerplate. ## The Cost of Boilerplate Boilerplate code is not just an eyesore, it comes with real costs. It increases the cognitive load on developers, makes the project less enjoyable to work on, and increases the time to onboard new team members. And increases the time to fix or resolve issues, which directly impacts the experience of the end user of your product. As a third-order effect, it also increases the soft requirement for more tooling and more AI assistance to manage and maintain your codebase, which is a dangerous spiral best avoided altogether. A question I've been asking myself is how much of this is by happenstance and how much of this is by design. I don't want to get all conspiracy theorist on you, but it does make me wonder if there are vested interests in making us accept boilerplate and ugly code as the norm, because it increases the demand for AI tools and services that can help us manage and maintain our codebases. I'm not confident enough to attach any weight to this thought, but it's something worth pondering. ## Aesthetic Responsibility It's very easy for us as developers to simply dismiss aesthetics as something superficial and unimportant in the grand scheme of things. After all, we are not building art, we are building software that solves problems and delivers value to users. However, I would argue that aesthetics play a crucial role in the quality and maintainability of our code. When we write code that is elegant and beautiful, we are not just making it easier for ourselves to read and understand, we are also making it easier for others to read and understand. We are creating a shared language and a shared understanding of the problem we are solving and the solution we are implementing. When we write ugly and boilerplate code, we are creating barriers and obstacles for ourselves and others. We are making it harder to read and understand, we are making it harder to maintain and evolve, and we are making it harder to collaborate and share knowledge. We're increasing the friction instead of reducing it. It always feels nice as a human to look at something beautiful, whether it's a piece of art, a well-designed product, a sports car, a building with stunning architecture, and so on and so forth. But when it comes to code, we often dismiss aesthetics as unimportant, after all, it's a means to an end, right? I would argue that as developers, we have an aesthetic responsibility to ourselves and to others to write code that is elegant and beautiful, not just for the sake of aesthetics, but for the sake of quality and maintainability. But it is very easy lately to just let the tools we have been given and AI do the heavy lifting for us, and in doing so, we risk losing sight of our aesthetic responsibility as developers. ## How Does AI Increase the Tolerance for Boilerplate? You know the drill: you are working away on a piece of a project, and you're on a tight deadline with a backlog full of features to implement and bugs to fix. You think to yourself, "I just need to get this done quickly, I can refactor it later(a mindset I generally encourage)." So you ask the AI to generate the code for you, and it spits out a solution that does not work, so you refine your prompt and try again, and again, and again until you get something that works. Now you have a working solution, great! One quick glance at your `git status`, **HOLY SH.. WHY ARE THERE 32 FILES CHANGED? AND WHY ARE MOST OF THEM NEW FILES?** Ok..OK, you have a working solution. It's best to open up a PR and let the Copilot PR bot handle the code review, and maybe a couple of co-workers will spot some things and suggest improvements. Once you have more time on your hands, you will absolutely go back and refactor this mess down to something elegant and beautiful. You just need to get this next task done first, oh, and it's on a tight deadline as well... Before you know it, you have a codebase full of boilerplate and code that could easily be done in half as many lines or less, you will never go back and refactor it because there is always something more urgent to do, and the cycle continues. Maintenance? Not a problem, we can just use AI to generate documentation for us or explain code blocks for us. Testing? AI can generate tests for us, no need to think about edge cases or test coverage. Performance? AI can optimize our code for us, no need to understand the underlying algorithms or data structures. It creeps up on you slowly, but surely. AI stands as an excuse to not care about the quality of your code, but only the quality or functionality of your outcome. There's a lot to be said and discussed about this topic. You might be rightfully asking yourself, does it even matter if the code is ugly and I feel no pride in it, as long as the end user gets the functionality they need? ## "Good Enough" Is Not Good Enough I always liked the saying, "How you do anything is how you do everything." It has multiple different explanations and interpretations, but to me, it boils down to this: if you accept mediocrity in one aspect of your life, you will accept mediocrity in all aspects of your life. Or, how you do the little things is how you do the big things. If you accept "good enough" code, you will eventually have a good enough product on your hands that might have to compete with products that were built with care and pride. Do you want to deliver good enough products, or do you want to deliver great products that you can be proud of? Completely ignoring the market and financial viability of this approach, will you be happy with the work you do if mediocrity is the standard you hold yourself to? Or worse, if mediocrity is the modus operandi of your team or company? If you truly believe that "good enough" is good enough, then by all means continue down that path. But I urge you to test that belief, challenge it, start a project that you may never finish or get paid for, but attempt to take a complex concept and distill it down to its essence in the most elegant way possible, do what Picasso did with his bull series, and see how far you can push yourself to create something beautiful out of something complex while still maintaining its core functionality and purpose. ## Conclusion AI is a powerful tool that can help us be more productive and efficient, but it should not be used as an excuse to accept boilerplate and ugly code. As developers, we should strive for elegance and simplicity in our code, and we should take pride in the work we do. We should love our code and our craft, and we should never settle for "good enough" when it comes to the quality of our work. **Write code you would sign your name under.** If you've enjoyed this article and made it this far, thank you sincerely for your time. I hope it was worth it and that it sparked some thoughts and reflections on your own approach to coding and craftsmanship, and I sincerely hope it did not feel wasted. If you have any thoughts or feedback on this article, please feel free to reach out to me on [Twitter](https://twitter.com/dayvsterdev). I'm always open to discussions and feedback, or just general chit chat about just about anything I find interesting.

Programming

Design

JSON

0 views

Manuel Moreale 1 months ago

Romina Malta

This week on the People and Blogs series we have an interview with Romina Malta, whose blog can be found at romi.link . Tired of RSS? Read this in your browser or sign up for the newsletter . The People and Blogs series is supported by Piet Terheyden and the other 122 members of my "One a Month" club. If you enjoy P&B, consider becoming one for as little as 1 dollar a month. I’m Romina Malta, a graphic artist and designer from Buenos Aires. Design found me out of necessity: I started with small commissions and learned everything by doing. What began as a practical skill became a way of thinking and a way to connect the things I enjoy: image, sound, and structure. Over time, I developed a practice with a very specific and recognizable imprint, working across music, art, and technology. I take on creative direction and design projects for artists, record labels, and cultural spaces, often focusing on visual identity, books, and printed matter. I also run door.link , a personal platform where I publish mixtapes. It grew naturally from my habit of spending time digging for music… searching, buying, and finding sounds that stay with me. The site became a way to archive that process and to share what I discover. Outside of my profession, I like traveling, writing, and spending long stretches of time alone at home. That’s usually when I can think clearly and start new ideas. The journal began as a way to write freely, to give shape to thoughts that didn’t belong to my design work or to social media. I wanted a slower space where things could stay in progress, where I could think through writing. I learned to read and write unusually early, with a strange speed, in a family that was almost illiterate, which still makes it more striking to me. I didn’t like going to school, but I loved going to the library. I used to borrow poetry books, the Bible, short novels, anything I could find. Every reading was a reason to write, because reading meant getting to know the world through words. That was me then, always somewhere between reading and writing. Over the years that habit never left. A long time ago I wrote on Blogger, then on Tumblr, and later through my previous websites. Each version reflected a different moment in my life, different interests, tones, and ways of sharing. The format kept changing, but the reason stayed the same: I’ve always needed to write things down, to keep a trace of what’s happening inside and around me. For me, every design process involves a writing process. Designing leads me to write, and writing often leads me back to design. The journal became the space where those two practices overlap, where I can translate visual ideas into words and words into form. Sometimes the texts carry emotion; other times they lean toward a kind of necessary dramatism. I like words, alone, together, read backwards. I like letters too; I think of them as visual units. The world inside my mind is a constant conversation, and the journal is where a part of that dialogue finds form. There’s no plan behind it. It grows slowly, almost unnoticed, changing with whatever I’m living or thinking about. Some months I write often, other times I don’t open it for weeks. But it’s always there, a reminder that part of my work happens quietly, and that sometimes the most meaningful things appear when nothing seems to be happening. Writing usually begins with something small, a sentence I hear, a word that stays, or an image I can’t stop thinking about. I write when something insists on being written. There is no plan or schedule; it happens when I have enough silence to listen. I don’t do research, but I read constantly. Reading moves the language inside me. It changes how I think, how I describe, how I look at things. Sometimes reading becomes a direct path to writing, as if one text opened the door to another. I love writing on the computer. The rhythm of typing helps me find the right tempo for my thoughts. I like watching the words appear on the screen, one after another, almost mechanically. It makes me feel that something is taking shape outside of me. When I travel, I often write at night in hotels. The neutral space, the different air, the sound of another city outside the window, all create a certain kind of attention that I can’t find at home. The distance, in some way, sharpens how I think. Sometimes I stop in the middle of a sentence and return to it days later. Other times I finish in one sitting and never touch it again. It depends on how it feels. Writing is less about the result and more about the moment when the thought becomes clear. You know, writing and design are part of the same process. Both are ways of organizing what’s invisible, of trying to give form to something I can barely define. Designing teaches me how to see, and writing teaches me how to listen. Yes, space definitely influences how I work. I notice it every time I travel. Writing in hotels, for example, changes how I think. There’s something about being in a neutral room, surrounded by objects that aren’t mine, that makes me more observant. I pay attention differently. At home I’m more methodical. I like having a desk, a comfortable chair, and a bit of quiet. I usually work at night or very early in the morning, when everything feels suspended. I don’t need much: my laptop, a notebook, paper, pencils around. Light is important to me. I prefer dim light, sometimes just a lamp, enough to see but not enough to distract. Music helps too, especially repetitive sounds that make time stretch. I think physical space shapes how attention flows. Sometimes I need stillness, sometimes I need movement. A familiar room can hold me steady, while an unfamiliar one can open something unexpected. Both are necessary. The site is built on Cargo, which I’ve been using for a few years. I like how direct it feels… It allows me to design by instinct, adjusting elements visually instead of through code. For the first time, I’m writing directly on a page, one text over another, almost like layering words in a notebook. It’s a quiet process. Eventually I might return to using a service that helps readers follow and archive new posts more easily, but for now I enjoy this way. I don’t think I would change much. The formats have changed, the platforms too, but the impulse behind it is the same. Writing online has always been a way to think in public. Maybe I’d make it even simpler. I like when a website feels close to a personal notebook… imperfect, direct, and a bit confusing at times. The older I get, the more I value that kind of simplicity. If anything, I’d try to document more consistently. Over the years I’ve lost entire archives of texts and images because of platform changes or broken links. Now I pay more attention to preserving what I make, both online and offline. Other than that, I’d still keep it small and independent. It costs very little. Just the domain, hosting, and the time it takes to keep it alive. I don’t see it as a cost but as part of the work, like having a studio, or paper, or ink. It’s where things begin before they become something else. I’ve never tried to monetise the blog. It doesn’t feel like the right space for that. romi.link/journal exists outside of that logic; it’s not meant to sell or promote anything. It’s more like an open notebook, a record of thought. That said, I understand why people monetise their blogs. Writing takes time and energy, and it’s fair to want to sustain it. I’ve supported other writers through subscriptions or by buying their publications, and I think that’s the best way to do it, directly, without the noise of algorithms or ads. I’ve been reading Fair Companies for a while now. Not necessarily because I agree with everything, of course, but because it’s refreshing to find other points of view. I like when a site feels personal, when you can sense that someone is genuinely curious. Probably Nicolas Boullosa Hm… No mucho. Lately I’ve been thinking about how fragile the internet feels. Everything moves too quickly, and yet most of what we publish disappears almost instantly. Keeping a personal site today feels like keeping a diary in public: it’s small, quiet, and mostly unseen, but it resists the speed of everything else. I find comfort in that slowness. Now that you're done reading the interview, go check the blog . If you're looking for more content, go read one of the previous 112 interviews . Make sure to also say thank you to Jim Mitchell and the other 122 supporters for making this series possible.

Web Development

Design

Music

1 views

Chris Coyier 1 months ago

Plates

Like, that you eat off. I asked about them the other day: Who’s got a set of dinner plates they really love? Having a fairly direct relationship to an artist would be nice… Otherwise, shopping! IKEA — GLADELIG . $5.99 for a 10″ plate is a good deal and it’s a classy look. (via Nicole ) Corelle — Winter Frost White 18-piece Dinnerware Set The ultimate classic for me. This is what I grew up with. They are thin, light, and strong. And only $79.99 for 6 of each large plate, small plate, and bowl. (via Chris ) Noritake — ColorWave The ColorWave sets are pretty simple and classy looking. $139.99 for 4-of-each. They have showier stuff like a Frank Lloyd Wright set and My Neighbor Totoro set as well which appeal to me. (via Montster ) East Fork — Starter Set This is actually what I had before, and honestly they are really nice. I love those unglazed rims and the spotted look. They are just pricy at $426 for a 4-of-each set. Wanted to try something new. (via Zack ) Crate & Barrel — Mercer $74.95 for 8 plates is a pretty good deal. Create & Barrel was where my mind first goes for something like this and I’m sure it would have been a good choice as well. (via Cassidy ) Fable — Dinner Plates Love the look of these. So plain but with just tiny bits of waves/variations. $104 for 4 (just plates) (via Brian ) Fiestaware — Skeleton Duet This is what I went with! ‘Tis the season, I guess, but I loved the design and I’m gonna rock them all year long. I paired the small orange Skeleton places with these black larger “Dinner Bowls” , a couple of oblong Skeleton serving platters, and got a free Skeleton dish towel. (via Bryan ) Get a local ceramics artist to do them . Love it, do it if you can. It will probably be expensive and take a while. It’s also subject to the style of the artist and likely won’t be simple/plain if that’s what you’re after. Find a ceramics artist on Etsy you like. Good luck, Etsy is so full of garbage these days I find it hard to find anything decent in any category.

Design

Culture

0 views

David Bushell 1 months ago

Croissant Favicons and Tauri Troubles

Croissant v0.4 is out! I fixed a few minor bugs and added favicons. I’ve had a surprising amount of feedback. I wasn’t expecting anyone to care about an app I designed for myself. Thanks to all who managed to navigate my contact form . Croissant’s design philosophy is vague because I’m just making it up as I go along. Essentially it’s an experiment in keeping it simple. Not “MVP” because MVP is nonsense — and not “minimalism” because that does not mean good. Croissant is just basic and unbloated. The three most requested features have been: Folders is never going to happen, sorry! That would literally double the codebase for a feature I’d never use myself but have to maintain. Bookmarks is possible. Croissant is just a reader not an organisation tool but I see the value of “read later”. Not sure how this will work yet. I do not want to build a bookmark manager. Favicons has happened! When I declared “no icons” I was talking about the craze of UI icons everywhere . Icons without labels! Meaningless béziers from self-important designers that leave the rest of us saying “WTF does this button do?” Favicons actually serve a purpose and improve the design. Favicons are a simple feature but were not easy to implement. Tauri is causing me headaches. I’m starting to rethink if I should continue the native app wrapper or focus solely on the PWA . The web platform always wins. How many cautionary tales must I read before I accept the truth! Why am I wasting time debugging Tauri and Apple’s webview for issues that don’t even exist in Safari? Wasted time and energy. I’m accruing non-transferable knowledge in my (very) limited brain capacity. Croissant v0.4 might be the last native macOS version. It only exists because the PWA requires a server proxy (CORS) that has privacy concerns . Maybe I can add a “bring your own proxy” feature? Podcast feeds include an image tag but basic RSS does not. There are standardised ways to provide an image/icon with and web manifests . These both require parsing the website’s HTML to discover. I’m relying on “known” root locations; namely: These locations aren’t required for either icon but browsers check there by default so it’s a good place to guess. For the 200-ish blogs I subscribe to I get a ~65% success rate. Not ideal but good enough for now. I really want to avoid HTML spelunking but I may have to. Expect an improvement in the next update. For now a croissant emoji is used for missing icons. I’m using the Offscreen Canvas API to generate a standard image size to cache locally. Favicons are currently cached for a week before refreshing. First I tried using a service worker to cache. Tauri was not happy. Second I tried using OPFS with the File System API. Tauri was not happy. I dumped Base64 into local storage and Tauri was OK with that but I wasn’t because that’s horrible. Finally I went back to IndexedDB which is perfectly happy storing binary blobs. So you can see why Tauri is on thin ice! I don’t want tech choices dictating what parts of the web platform I can use without jumping through non-standard hurdles. That’s all for now. I hope to have another update this year! Visit CroissantRSS.com to download or install Croissant as a progressive web app. Oh yeah… and I kinda messed up deployment of the PWA service worker so you may need to backup, remove, and reinstall… sorry! Thanks for reading! Follow me on Mastodon and Bluesky . Subscribe to my Blog and Notes or Combined feeds.

HTML Pwa

Design

Web Development

0 views

Compline - A colorscheme for deep contemplation and work

Recommended posts, 2017-2025

Notes From an Interview With Jony Ive

Learning photography: composition

Towards Better Word

Making a Small RPG

Modality, tactility, and car interfaces

5 Pixel Art Tips for Programmers

Tahoe’s Terrible Icons: The B-Sides

Maximum Iteration

Thumbs Up 👍

Game design is simple, actually

Can You Still Learn to Draw in the Age of AI?

Frank Chimero

Stars Reach visual upgrades

October 2025 blend of links

AI’s Trap: Settling for Boilerplate Over Elegant Code

Romina Malta

Plates

Croissant Favicons and Tauri Troubles