Monster Train is a strategic roguelike deck building game with a twist. The game is Shiny Shoe’s first card game and largest roguelike-style game by far. While the game has enjoyed a lot of success, we made many mistakes along the way!
This talk is about the architecture of Monster Train and what we would do differently if we were starting again. While engineers will get the most out of this talk, designers with an interest in how a game is structured will also enjoy it. And while we used Unity to develop the game, the concepts discussed will apply to any engine.
The cost of casting a spell: one of the most impactful design decisions in your roguelike.
What mechanics will lead to interesting gameplay? Mana costs? Spells per level? Charges per spell?I will discuss the various popular systems, categorize them along various axis including but not limited to fungibility and replacability, and share some fun design anecdotes from various early RW prototypes.
Shattered Pixel Dungeon is a fork of the mobile roguelike Pixel Dungeon, which came into existence thanks to the Pixel Dungeon community. The community has helped guide development direction and drive the game's success. The end result is an approachable but fully-featured roguelike that fits in your pocket!
In this talk I'll cover some of the techniques and lessons I've learned while developing ShatteredPD. This includes using the Pixel Dungeon community to gain an initial audience, involving player feedback/analytics in the game's iterative update model, leveraging the community to monetize without harming gameplay (despite the mobile ecosystem!), and following community demand to help guide the game's long-term direction.
This talk is about "juice" and game feel within traditional roguelikes. Juice is all about adding polish, feedback, tiny details, and love to a game.
The talk will include a survey of the best examples of juicy roguelikes in the wild, break down some very easy to use techniques for adding juice, and talk about my journey from ignoring to embracing such techniques. As is tradition in this kind of talk, we will step through a demo of taking a static roguelike and adding polish to it until the end result feels like a completely different game.
I will present my work on general video game quest theory. Specifically, I want to have an in depth discussion of my proposed definition of a quest, as well as a new paradigm for classifying quests which can replace the old side/main quest model.
I believe this is relevant to the rogue-like community and in particular those who are interested in procedural quest generation because my quest definition is the first technical definition of a quest in academic literature. A technical definition like mine better supports technical applications of quests, and adoption of the definition in the PCG community could foster better collaboration within the community. The new paradigm that I would like to introduce allows for more flexibility in characterizing the constraints of the quest and purpose of the quest within the design space. I believe those interested in procedural quest generation can leverage this paradigm to better specify the kinds of generation they are aiming for. This is useful because it can help set the expectations of the system more appropriately, rather than a system producing main or side quests that do not fully meet the expectations of the user due to the baggage that the main/side quest terminology carries.
Additionally, this work is already being used in my company at improbable to better design quests and understand the design space we are working in, and has already proved useful in the practical development of our game.
i will discuss several typical Rogue spell/combat effects like bump-to-attack, Teleport, Polymorph, Poison. sketch out some of the possibility space that different games can explore from these basic ideas, and the considerations of how they interact with other design elements, drawing some examples from my own games.
e.g. consider 868-HACK's .POLY: a very cheap polymorph spell that affects all enemies on the level. this would be a huge and overly unpredictable effect if there was wide variance in enemy strength, but with only 4 enemy types of roughly equal power it's legit.
the goal is to inspire people to stretch genre tropes in a unique way to fit their own game. to see tropes as a flexible empowering toolbox and not a constraint.
This is a lightning talk.
The "year" of March 2020 has made parents experts in finding any source of reliable entertainment that doesn't drive themselves batty, yet keeps the kids engaged and learning something.
Roguelikes are an excellent solution to these problems with a few accessibility nods that make the games better for all players.
Parents have run up against a host of software largely made for an older player base.
This talk presents a few parenting-simulations you can conduct while playing your game to judge its suitability for parents. A few examples of failures and low-cost fixes are shown.
Before your cringe breaks make you hit the abort button, I'm *not* talking about theme/blood/and other items which are far more noticeable to you.
This is about issues like small hands vs big controllers, difficulties seeing and reading text, load screen post-confirm buttons, the realities of children and embarrassing information, and pause buttons that work for parents.
Addressing these issues can also broaden your game's audience to folks with issues with visual acuity, dyslexia, color vision deficiency, and more.
In this talk I will discuss the similarities between Ursula Le Guin's book The Tombs of Atuan (the second book in the Earthsea series) and traditional dungeon based roguelikes. The book takes place in an environment that is extremely similar to the dungeons of doom (including a hunger clock!).
I'll use pieces of the text to illustrate these similarities, and potentially do some digging into the source material of original rogue development to see if there is in fact a direct line of inspiration from the book to the original game.
How to build Roguelike elements into a game that wasn't originally created to be a Roguelike.
A high-level overview of procedural phonology generation, or how you can use phonology (the study of linguistic sound systems) to generate not only random names, but random naming languages (i.e., name generators), such that their outputs sound similar to each other and distinct from the outputs of other generated languages - much as each real-world language has its own unique character.
Fireballs. Super attacks. Fatalities. Summons. Limit breaks.
Whatever you want to call them, some videogame attacks are more complex than a simple punch or kick. And some games have ridiculous amounts of super attacks, each carefully choreographed, using sounds, music, particles, animations, and anything else the game engine can possibly display. We know that all this content was created by loads of hard-working developers working insane hours.
So can't we procedurally generate them?
I'm making a game called Space Warlord Organ Trading Simulator, about buying and selling the fleshy meat parts of sentient beings in a strange and evolving universe. This required making an intergalactic stock market. Which required defining the value of a given organ. Which required defining a list of organs. Which required defining what is and is not an organ in the first place, and so on, in an endless line.
The process broke our team. Not in terms of crunch, or mental health, but in the realization that so many of the systems and definitions used in every aspect of our reality are *invented*. False. Arbitrary decisions from someone else we'd never meet.
In this lightning talk, we're going to show the necessary and powerful existential hell of unravelling your game's systems to discover the implicit ethical considerations beneath. A seemingly simple or absurdist game can reveal the arbitrary nonsensicality of the systems we live within every day--and cause one to demand better systems in the process.
Existential crisis: the dev talk.
Radicalization via viscera.
Viva la revolorgan.
| ! % . . @ . @ . . @ . . . @ @ . \ \ \ \ \ . |