Marketing // PR // Getting your game noticed

Inspiration for roguelites

If it's taking days to find the problem, then you're probably doing something wrong. Learn from the experience, and improve your process.

Version control. Use it. Commit often. Work on a single feature at a time within any given branch. Use version history to quickly diagnose when a bug was introduced (either by inspection, or by bisection testing for it).

Tests. Write them. Unit tests are the simplest starting place, and will immediately help you diagnose when your code isn't even meeting your requirements for the desired use-case. Unit tests also make it easy to fix bugs, as you can practice TDD (test driven design) for bug fixes by introducing a test case that reproduces the problem -> fixing the problem -> success.

Tests. Build them. There's a lot of things in games that are easier to visualize than code. Have a test level that can contain a test layout for every single feature in the game. Have a spot to test the jump, the long-jump, the bouncy shot, the target tracking shot, etc. etc. etc.. Go there often, and make sure everything still works, and every new thing works as intended in isolation.

Tests. Record them. Sometimes things are hard to reproduce. Build you game with deterministic replay capability. Always record your inputs while playing, and have a mode to play them back. Here's a good GDC video for Retro City Rampage talking about how useful this technique is. This lets you easily reproduce bugs from yourself and from your testers.

Tests. Diff them. For visual systems, build a screenshot diffing tool. Using #4 as a starting point, capture screenshots every X frames. If those screenshots differ from your "golden" captures, then you broke something.

Tests. Smoke them. A "smoke test" is a test where you leave the game doing something all night (or on some kinda fast-forward) to make sure things still work in 24hrs. This is really important for things like open-world games with no loading screens which are going to be played for many hours in a stretch. Sometimes things creep up in the background over time (memory leaks, floating point errors, broken timers, etc.), and you wouldn't normally see them in your short REPL cycle of development.

Version control. Use presubmit checks against all the tests you just wrote. Keep yourself and others from commiting broken code to the repository.

Roguelike Rendering Pipeline - Layering of data

Units tests and roguelikes // Game unit testing // pragmatic unit testing

Selling consumer products is hard. Selling video games is, arguably, even harder. The market is huge but it’s also very crowded. There’s so much noise on Steam (21 new games/day in 2017 [1]) and other distribution platforms that it’s insanely tough for new game developers to figure out how to sell games and what metrics to watch. This article will go over, what I think is, the most important metric for any game launching on Steam, namely the number of wishlists.

Entity Component System programming pattern approaches explained for roguelike games

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)