Week 4: Media Theory Reading, and Game UI Update
Feb 24, 2025
Blog series: Bazaar.log (IDM Thesis Project)
This week, I read a book and several online articles about the open-source philosophy and the history of user interface, which inspired me a lot on my game logic design and UI design. With these inspirations, I updated my game logic and UI and started to refine my game story.
Try my game online (work in progress)Readings
This week, I realized a major difference between my game and Cookie Clicker (and Universal Paperclips): the two games tell the story of capitalism, in which the success of, say a cookie factory, can be reduced to one number: the amount of cookies. I tried to "reduce" my game data to one number but failed, and now I know why: this is because the success of a community is more diverse than that of a factory. A community can have many members but on the way of dying, and a small community can be vital and healthy with very limited member groups.
Therefore, I went to read two books: The Cathedral and The Bazaar by Eric Steven Raymond. This book not only supplements my knowledge of computer history, but also verifies a lot of my understanding of the connection between the open source community and the Internet. Many of the contents are very helpful to my programming and narrative design. I've read until Chapter 3, and below are some reading notes worth sharing from Chapter 3, which is about an Eric's experiment with the Bazaar mode of development, learning from the sucessful precedent of Linux.
...it's almost always easier to start from a good partial solution than from nothing at all. (P30)
This reminds me of using AI to write code nowadays. AI helps quickly start a coding project by providing the scaffold to develop, saving a lot of time.
Users are wonderful things to have, and not just because they demonstrate that you're serving a need, that you've done something right. Properly cultivated, they can become co-developers. (P33)
This quote validates my findings from open-source community: the blurry line between users and contributors. This also reminds me about my logic design: maybe instead of separating users from contributors all the time, users can be all (or partly) converted to contributors after forming an organization in my game.
"Given enough eyeballs, all bugs are shallow." I dub this: "Linus's Law." (P36)
Sociologists years ago discovered that the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers. They called this the ‘Delphi effect'. (P37)
This is one of the most important reason for the success of the Bazaar mode. It is about "maximize the number of personhours."(P36)
The total cost of maintaining a widely used program is typically 40 percent or more of the cost of developing it. Surprisingly this cost is strongly affected by the number of users. More users find more bugs. (P39)
Another characteristic of the open-source method that conserves developer time is the communication structure of typical open-source projects. Above I used the term "core developer"; this reflects a distinction between the project core (typically quite small; a single core developer is common, and one to three is typical) and the project halo of beta-testers and available contributors (which often numbers in the hundreds). (P41)
This quote is very helpful for me to learn the structure of a typical open-source community: one-to-one communications among core developers, and paralelle communications among contributors (i.e., no direct communications between contributors). This is also inspiring for data visualization.
Brook's Law: “Adding more programmers to a late project makes it later.”
Brook's Law predicts that the complexity and communication costs of a project rise with the square of the number of developers, while work done only rises linearly.(P41)
Still talking about the efficiency, Brook's Law suggests interesting dynamic between number of programmers and efficiency. It is possible to implement this mechanism in game.
The Brook's Law analysis (and the resulting fear of large numbers in development groups) rests on a hidden assummption: that the communications structure of the project is necessarily a complete graph, that everybody talks to everybody else. But on open-source projects, the halo developers work on what are in effect separable parallel subtasks and interact with each other very little; code changes and bug reports stream through the core group, and only within that small core group do we pay the full Brooksian overhead. (P41)
Explanation of why the Brook's Law is not fully compatible with a typical open-source group.
"wake me up when it's done" antideadline policy (P39)
Surprisingly, deadlines can be harmful to the quality of deliverables.
With these knowledge, I am more confident in narrative and logic design. I will continue reading the book and apply what I learn to my storytelling and programming.
UI Updates
To make my game more immersive, I re-designed my game UI in several aesthetics of different eras. I referred to the introduction to UI history in The Art of Unix Usability (Chapter 2. History: A Brief History of User Interfaces) by Eric Steven Raymond and Rob W. Landley, as well as other online articles. Below are my designs in Figma.
UI design to imitate pre-Internet retrospective CRT interface.
UI design in Web 1.0 aesthetics. I chose Windows UI as reference.
UI design in Web 2.0 aesthetics. Around early 2000s, webpages were excited to try out colorful fonts, hyperlinks, tile arrangement of images for background, and low-res GIFs and JPGs for decoration.
UI design in Web 2.0 aesthetics, static, with button style.
UI design in Web 3.0 aesthetics, light mode. In the Web 3.0 era, web design starts to pay attention to online accessibility, which includes san-serif fonts with high readability, the switching between light mode and dark mode, and so on.
UI design in Web 3.0 aesthetics, dark mode. In the Web 3.0 era, web design starts to pay attention to online accessibility, which includes san-serif fonts with high readability, the switching between light mode and dark mode, and so on.
At this point, my game UI can switch styles as the era changes, but I need some more time to apply my design to the actual game UI.
Other Resources
Next Steps
- Apply UI design to the game.
- Finish designing the narrative; create news lines and decisions for display in game to tell the game story.