roguelike talks, design information and programming advice - really good resource

1. Problems of MVC - it all gets entangled
2. Databases are details, the 'web' is a detail - it should all be abstracted out
   1. These details are plugins which require the underlying business logic but are never required by the business logic, operate completely separately from them, only invoking them through specific boundary objects
3. To abstract out:
   1. 'Entity' Objects (or Business objects) which do their work independently from any application
   2. 'Interactor' Objects which take 'Request' Objects, invoke the functions on Entity objects and return the result as 'Result' Objects (they are dependent on the application (i.e. the requests and results are different per application)
   3. 'Boundary' Objects (or Use case objects) which are implemented by the interactor objects and make sure that certain methods etc are always there for outside plugins to interact with (they make sure the attachment points stay stable)
   4. A 'Presenter' Object which gets the results out of the 'Interactor' object (through the points of interaction defined by the 'Boundary' Objects) and moulds the 'Result' Object into a 'View' Object
   5. The 'View' Object is finally pretty much just strings of things to display, formatting of how to display it (e.g. display it in red, or bool to grey out a button, or strings of menu items and so on)
   6. The 'Viewer' is completely dumb and simply displays everything contained in the 'View' Object

The majority of content on the web is words—and more than half of web browsing happens on mobile screens. It follows then that the way we set our words has a bigger impact than ever on design, usability, and brand differentiation. But while typography is clearly the most important aspect of great design and user experience, it can’t come at the expense of performance or we risk our great designs never being seen. Variable fonts are here, and will change everything: with a single font file that can scale in size, width, weight and even x-height—exactly as the type designer envisioned.

Meadows' book is foundational to systems thinking as we understand it today; it's also part of the first generation of similar books trying to make systems thinking less abstract (see also Senge's Fifth Discipline in business for example). It is not, however, readily applicable to game design.

Her book has long been a traditional entry point for people to understand systems, and was a great inspiration for me in writing Advanced Game Design: A Systems Approach. My focus there was to write a game design text explicitly based on the idea that games are systems. An understanding of sources, stocks, and sinks, and of reinforcing and balancing loops, is just the beginning; there's a great deal more that can be understood and applied in designing games as systems.

Pesonally I would put "Thinking in Systems" in the same class as Alexander's A Pattern Language; Hofstatder's Godel, Escher, Bach; Luhmann's Introduction to Systems Theory; or even Wiener's Cybernetics as sources of deep systemic knowledge useful for but not directly applicable to game design.

I do hope however that more and more game designers begin looking at their games as systems, and that understanding this way of seeing and thinking helps create more effective designs.

Monetize by having ~20 % of factions locked off at any one time. The factions rotate every x days and another 20% become locked off.

Think abt having a certain 'base' set never locked off

Simple, Easy, Ground Texture Tutorials with optional video walkthroughs (imgur.com)