This is a shockingly comprehensive, and at the same time very easy to read, introduction to game design. The book touches on aspects ranging from game mechanics, aesthetics and technology considerations, to teamwork advice and design documents.
Overall, the book gave me a lot of respect for the complexity and size of the field. As a game designer, you have to draw from a big number of disciplines such as anthropology, psychology, sociology, architecture, probability theory or graphic design. You have to think about what needs of the player your game satisfies (think Maslow's hierarchy, but not only), how to maintain the difficulty curve so that the player is in the "channel of flow" (not too easy, not too hard), how to balance your game with respect to different axes, what theme the game will have and how to use every aspect of design to reinforce that theme, and so on and so forth. There is also some advice on brainstorming and working with a team which can be easily applied outside of the field of game development.
All these ideas are neatly categorized in the book's chapters, and in each part I found some interesting insight. To give one example, there's a concept of game venue as something that defines the type of play experience. The author mentions venues like the hearth where people gather together (modern hearth being, well, the TV with a console), your personal workbench where you concentrate on things (desktop PCs would fill this niche, with PC games being more "serious" and less casual), the reading nook where you sit comfortably with a book (or a tablet), a table for board games, public spaces like arena for competitive games, and so on.
Another example is the well-known notion of "emergent gameplay" that somehow always felt like a magic to me – my understanding of it was "create a sufficiently complex game and it will magically become more interesting because of what the players come up with". The book breaks it down nicely: a game can have basic actions which are basically rules of the game (for instance, move a piece or capture a piece) and strategic actions which are implied by these (for instance, move a piece to protect another one, sacrifice or exchange pieces, force an opponent to do something…) It's generally good to have a small number of basic actions from which many strategic actions can emerge. A good way to achieve that is to make each of this actions meaningful, e.g. have far-reaching consequences instead of just local ones.
That's just a small sample of things I took away from The Art of Game Design. I borrowed the book from a friend but I think I will be buying my own copy, since I definitely plan to return to it in the future.
I just came back from PyWaw Summit, a two-day Python conference here in Warsaw. Here are some interesting take-aways I had:
- A great talk about "diving into the rabbit hole": a tendency of programmers to go digging themselves into deeper and deeper trouble trying to solve a problem. Sort of a dark version of the flow state - time flies really fast, you become fixated on the issue, have a feeling that you're always "almost there", neglect human contact… What you can do is get better at recognizing these situations, step back, have a rest, and talk with someone else.
- An interesting point about unit tests. Programmers learn relatively early not to change the code from
n = 1 to
n = 2, they change the code from
n = 1 to
any n, i.e. generalize properly. Notice that the first opportunity to do so is right when you're writing tests for your code and learn that you have to isolate some part. Instead of hacky solutions like
mock.patch, take the opportunity to refactor your function!
- IPFS - ambitious project for universal peer-to-peer content-addressed storage, sort of like Git, Bitcoin, or BitTorrent. I wonder what will come out of it.
- PostgreSQL has
SELECT to_json(...), I guess it can come in handy when you want to write something quick and dirty and get the data to your application.
- A horror story: you know how you can have Python stored procedures in Postgres? Some people were using them to import Jinja2 and render templates. On the database server.
- Also about Python stored procedures - you can actually keep them in a versioned Python file, and just call functions from that file in your database procedures. This way, your procedures can be under version control, and you can actually unit-test them (by providing mock data to function instead of running through database).
- Case in point for microservices: they make onboarding new programmers easier, since a new programmer doesn't have to understand the whole system immediately - they can read a single program and be ready to hack on it from day one.
- Inspiring keynote about "sharpening your tools": bad tools can slow you down, it's important to spent some time automating your work, and pair programming is actually pretty useful for that - you see the other person doing something crazy fast with their computer, and get new ideas on how to improve your own setup. Examples: shell history and tab completion, editor auto-indent, incremental search (search as you type), editor auto-linting (jshint, pyflakes), aliases and scripts for common commands, storing your dot-files in version control.
- testmon: a neat project that monitors code changes and re-runs only the relevant test (by checking code coverage). I'm looking forward to trying it out.
- Ola Sitarska told us the story of Django Girls, Django beginner tutorials for women. Pretty awesome how big the initiative is getting - just look at how many cities the events are being held in.
That's all for now - until next time!
- Interesting talk about not using any frameworks (I imagine the JS programmers tend to go overboard with these sometimes) - makes you notice that sometimes all the dependencies force you into a specific way of coding, and forces you to actually learn more of the underlying technology. I guess a first step would be to learn modern JS language and DOM features without using jQuery.
- URI Templates are a thing - a standard way to specify resource URLs, like
- JSON can have a schema too. Seems useful as a form of validation for APIs. Also, allows for automatic form generation on the frontend - just change a schema and appropriate fields will be generated, with client side validation even.
- Advice from a team that instead of preparing independed design mock-ups for pages, decided to develop according to a "style guide" of visual content - a gallery of available classes, colors and so on. Seems like like good idea. They even have software that automatically generates these, and allows editing them in browser.
- A guy from Yammer described their problems with scaling up the codebase and the team. Main takeaway: instead of writing documentation, make it executable (write clear tests instead of describing the functionality; make JSHint part of your build instead of having a coding style guide).
- Scalable and Modular Architecture for CSS. Interesting idea, if too radical at times (advice to use single classes in the format
.block__element--modifier looks like abuse to me).
- Web Components - an upcoming standard (and existing library) allowing you to define your own HTML elements. Want to have an in-place AJAX editor? Instead of copy-pasting necessary markup all over the place, just define a
- Fun story about a test that suddenly started failing mysteriously. They were validating a purchase of child insurance, and used some testing data for that. One day the guy just became too old for child insurance :) Moral: instead of refactoring a group tests to have common, complicated set-up procedure, use many simple helper functions.
- Pretty 3D fractals in browser. The audience suggested using Oculus VR…
Finally, there was a closing keynote about diversity in tech that I found valuable. The fact that the tech scene is demographically monolithic, and at times very unfriendly to women and other underrepresented groups is quite well documented, but the speaker also touched on a few other issues.
- One was that we actually make this stuff for everyone else, creating technology and online spaces that the rest of the world uses. This is important when it comes to accessibility (there are more blind people worldwide than the whole population of Poland), but also things like real-name policies that are downright harmful, social network designs that encourage online harrassment, or failures like making your a phone work well only for right-handed people because nobody on the design team foresaw possible problems.
- Something I still have to make my mind on is shipping culture considered harmful. The downsides of "moving fast and breaking things" include launching badly thought out products and subsequent feature creep, stressful work pace, and an environment where only the engineers' contributions are appreciated since they are the only ones directly shipping.
- Another controversial idea was that meritocracy doesn't work, in that it's easy to make your environment resistant to change - if you value only the merits that you have, and dismiss the rest as irrelevant, in the end you'll only invite more of the same people and keep out others that would also bring value. See Linus's famous abuse that keeps potential Linux kernel contributors out if they're not thick-skinned enough.
The talk (and a positive response from the audience) gave me much respect for the British frontend scene, especially compared to the Polish one (post in Polish, and a somewhat unpleasant reading).
That's all I have - I hope you enjoyed my writeup!
Yes, the "r" is no mistake - this is a book on what it means to be a professional programmer, someone who has a programming job and takes it seriously.
The book teaches you to take pride in what you're doing, to stick to good practices (especially under pressure) because that's the ethical thing to do, to not cave in and "just try to do it faster", but at the same time to take responsibility for what you're committing to. It reminds you that requirements are not set in stone, that the client might not know really well what they want and it's your duty to help them figure that out.
It also gives good advice on several subjects both technical and soft, like estimation, TDD and different kinds of testing, mode of work, and time management. The author shares many war stories from his 40-year-long software engineering experience, talking about how to avoid his mistakes.
Some of it is very opinionated (it's Uncle Bob, what'd you expect) and I didn't agree with everything, but some things rang very true for me and actually were painful to read. I had to look at the areas where I'm not behaving like a responsible professional; overlooking broken windows, not managing my time properly, concentrating on broken requirements instead of the overall goal.
On the other hand, it was nice to see some confirmation about things that I'm just discovering for myself now, like the effectiveness of pair programming or that one person shouldn't juggle several projects.
I highly recommend the book to all professional programmers.
Some of my takeaways:
- you can commit only to something you know that you can deliver (for instance, you cannot commit to fixing a bug if you haven't investigated it yet)
- programming in isolation can (perhaps) make you personally more effective, but it almost always makes the team less effective
- similarly, the state of "flow" is, by the author's account, overrated - it's pleasant, and you work very fast, but you lose the wider view
- I learned about human-readable acceptance tests that are supposed to help business communicate with development - I'd like to see them in action
- "teams are harder to build than projects" - so you shouldn't form a team around a specific project, you should built a well-jelled team that can tackle many projects, even at once
- even if you were invited, you absolutely should excuse yourself from meetings where you waste your time
I just finished PolyConf, a two-day "polyglot programing conference", and I'm really excited. There were a lot of really interesting talks so I want to share it all with you. Here are some of the things I saw:
A guy from Wunderlist team talked about using 10+ different programming languages on production. Apparently they have a lot of microservices. Some interesting takeaways: if you write it, you run it (and that includes convincing other people to learn your language!); and a service should be simple enough so that (as a last resort) you will be able to recreate it in one day.
Interesting talk about teaching programming to people with completely different backgrounds (e.g. humanities). Apparently you will struggle with lack of mathematical rigor and basics (such as computational complexity). On the other hand, you get a lot of "domain knowledge" when cooperating with them, and (not sure if that's a plus) they are much more willing to do repetitive tasks than us lazy programmers :)
Very nice lightning talk about Commodore 64. The guy showed us a program in assembly: look, here is this program, it runs in a loop and does this animation. But then I take the address of this loop, and put it in an interrupt handler, and look! It still executes but I can type text at the same time! So we get asynchronous programming on an 80s machine.
Good insight from Elasticsearch guys that decided to make their HTTP API more accessible - they said that "clients are part of the distributed system" and decided to write the clients for their API in various languages as well, to ensure that the users will have a good experience with Elasticsearch. Then they were able to adapt one test suite to all these languages.
A demo of immutable data structures in Clojure. You can have an immutable "vector" (internally a tree) that you can modify with a (small) logarithmic overhead, and keep both versions around, sharing the common parts. Sort of like Git. So for instance you can have an editor storing all versions of a file and effortlessly add undo-redo functionality. I really want to use all this to make a time-travel game sometime.
An interesting but quite frightening talk from a manager in an "agile company" - a large Poznań-based Python software house (STX Next). Highlights: whole team in one room (nice!), there has to be a woman in every room (ok…), everyone uses time-tracking (uhh….), there are huge screens everywhere and every employee is on camera (get me out of there).
A talk about NoSQL and domain-driven design. I think I undestand more about what the fuss is all about - it's not about being able to store amorphous, complicated JSONs, but the fact that value objects (e.g. price+currency pair) don't really make sense as database tables; and relational joins don't have to be the only way of representing relationships. (Well, also scaling.)
Awesome coding session with a guy making snake game in ClojureScript (another language compiled for the browser). He was really excited about being able to hot-swap the code in browser without having to reload (and keeping the state), enthusiastic about Paredit mode in Emacs, and got everyone fired up about the technology. "Can I have two more minutes? I can make it eat berries in two minutes!"
A talk about cross-platform Ruby being translated to all different technologies including Arduino and Objective-C on iOS. Also with a healthy serving of "hexagonal architecture" thrown in (write platform-agnostic code and write "adapters" for absolutely everything external). Sounded like too much of a good thing, to be honest…
At the end, a great presentation of automated test generation by John Hughes of QuickCheck fame. He told us "don't write tests - generate them!" and presented the approach on several examples, ranging from a toy circular-buffer program in C to verifying huge amounts of code in automobile software based on a 3,000-page standard. We have a rudimentary tool here at Codility for challenges, maybe it's time to resurrect it?
And that's not even mentioning everything (there was also F#, some Rails Girls and PyLadies, a few more philosophical talks…) So all in all, a great conference that I'll definitely attend again next year.
I hope you enjoyed this write-up and feel encouraged to attend more events like that!