Gamedev
categories: hacking
Description/Summary
Game programmingContent
Gaming,learning and programming.
Languages
Cakelisp: a programming language for games
Rustlisp for game dev: https://gamelisp.rs/
Posts and videos
Shirky’s Law and why (most) social software fails
The third reason developers fail to obey Shirky’s Law is that it’s difficult to do. The most successful social software starts out doing one task supremely well. That task is simple, useful, and original. It’s easy to come up with a task which is useful and original – just combine existing ideas in a new way, perhaps with some minor twists. But finding something that’s also simple is hard. It has to be a single task that can’t be reduced or explained in terms of existing tasks. Inventing or discovering such a task requires either a lot of hard work and social insight, or a great deal of luck. It’s no wonder most social software fails.
- Not only skills but also a way of thinking
- Get something on the screen as soon as possible
- Create by reacting
Two Games with Monte Carlo Tree Search
Video: Alan Kay - Programming and Scaling
Video: Bret Victor - The Future of Programming
goals and constrains
“What you want to do”, not instructions about “How to do”
Pattern matching
Charles Isbell and Michael Littman: Machine Learning and Education | Lex Fridman Podcast #148
joy
Gamification concept.
The Future of Creativity and Innovation is Gamification: Gabe Zichermann at TEDxVilnius
Gabe Zichermann
Conquer a challenge -> feel great and feel successful -> do it more. The more success we feel, we more we are willing to keep doing it
Gamification to improve our world: Yu-kai Chou at TEDxLausanne
Ownership: gamers feel they own something, making them want to improve it
Social: The most effective way to chage a person’s behavior is showing them what their neighbours do
Unity: Devlog 2: Game architecture with ScriptableObjects | Open Projects
7 educational games that every developer should study
Learn Lua by writing a “guess the number” game
Making Crash Bandicoot – GOOL – part 9
Game engines are large systems consisting of many moving parts. Good software engineering requires simplicity – it is what allows a system to remain secure, stable, and coherent throughout its evolution. Simplicity itself requires a lot of work at the start of a project to reduce the idea to its essense, and lots of discipline over the lifetime of the project to be able to distinguish worthwhile changes from the pernicious ones. That is simply everything my game engine is not, because for such a complex piece of software such as a game engine, it is not easy to know HOW all the pieces fit together, just some vague idea. Complexity arises through the iterative process that is implementing and actually debugging problems with these features. Making a small change to get a engine feature to play nice with others could, and often does, adversely affects simplicity and elegance much later down the road during development.
Follow up to Gamedev, Sleep, Repeat
I am less interested in making games, and more interested in the design of game engines. A game engine is interesting to me because it requires discipline in many fields of study, and each implementation is different. The thing is, a game engine is a piece of software that manages the data flow for a particular game, or a particular category of games. It is nothing more than a set of choices someone made for you in order to write games in a particular way. Any given game engine could be productive or counter-productive in creating your game. Even using a general purpose game engine like Unity and Unreal is a trade-off, and for a significant game, you’ll find you still have to work around or reimplement core engine features at the 11th hour to get your game shipped.
What are game mechanics? October 24, 2006 by Daniel Cook
Humans are wired to solve black boxes. It is a fundamental aspect of our neurological learning wetware. We get real chemical rewards when we grok a problem or gain information that we suspect will help in grokking a black box. Evolution has selected for this behavior over thousands of generations since it is the biological reward system that encourages tool use and technological adoption. Without this built in addiction to problem solving, we would lack agriculture, medicine, architecture and other fundamental survival techniques that make the human species such a remarkably successful animal.
Boos that are worth reading
Programminguzzles
Tool: Publish interactive blog posts and explorable explanations with Idyll’s free hosting service.
Common Lisp Programming Exercises
L-99: Ninety-Nine Lisp Problems
Solutions to Ninety-Nine Lisp Problems
Tips and Tricks for Solving Advent of Code’s Puzzles
You should always keep in mind that Advent of Code puzzles were meant to be solved. The many considerations that go into making an Advent of Code puzzle include:
- For a given input (remember, every participant has their own unique input), there is one and only one correct answer.
- Avoiding expectations of domain-specific knowledge, including computer science. The puzzles aren’t made with the assumption that you’ve taken a data structures course or even any computer science course. You are expected to know how to do a little coding.
- Trying not to make the reader make any assumptions. In fact, the text of the puzzle often repeats and highlights important details. Eric has observed that “for every sentence, there’s a user that skipped only that sentence.”
- Every day has two puzzles, with the end of the first puzzle acting as a kind of checkpoint. The second puzzle is always a twist on the first, and it’s meant to simulate the real-world experience of changing requirements.
- Generally, the later in the month, the more challenging the puzzle. They throw in the occasional “off-difficulty” puzzle to control pacing and to keep participants from burning out.
- Some earlier puzzles may be simpler versions of more difficult puzzles that appear later. This is Advent of Code’s way of preparing you.
- The puzzles vary in type from day to day to keep things interesting, and weekend puzzles are more involved than weekday puzzles.
- Using a compiled language to solve the puzzles won’t give you any noticeable speed advantage over using an interpreted language. If your code is still working on a solution after about a minute, you’re probably taking the wrong approach. To quote the “About” page, “every problem has a solution that completes in at most 15 seconds on ten-year-old hardware”.
Advent of Code: How to Leaderboard
Another aspect is the unique two-part format of each puzzle. Even though they use the same input, you don’t get to see the second part until after you’ve solved the first one, a feature that Eric Wastl (AoC’s creator) has taken full advantage of in designing puzzles. The second part is often a surprising twist on the first part, which keeps you on your toes and challenges you to keep your code moderately general or refactorable in a way that I think almost no other programming challenges do. This sometimes even happens between days in a calendar, when a puzzle turns out to be about some model of computation you implemented two or five or ten days ago — hope you kept your code and remember how it works!
Looks old: Internet Problem Solving Contest