Conception Windows, Mac, Linux game

[Jan 29 – Feb 26] Conception: A Brainstorming Toolkit for Game Developers

Develop a tool that enables game developers, tabletop and video games alike, to test their limits and discover innovative ideas.

​Conception (V3.o) is a single-player user game which acts as a tool for creators to use as a jump-starter for developing a game. While only one person controls Conception‘s user interface through a mouse device, allowing a team of more than one person is another great option prior to a brainstorming session.

To use Conception as a brainstorming tool, the user selects the GENERATE! option which provides a randomly generated list of requirements for the creator to abide by. The list contains one constraint from each group: a topic, a mechanic, a dynamic, an aesthetic, a theme, and a genre/system. Once the constraints have been generated, the creator begins developing their game while incorporating those constraints.

• A topic is a game element defined by a narrative setting. This is the context and atmosphere of your project.
• A mechanic is an interactive game element that occurs between the player and an object. This is the rule that the developer chooses to implement into a project for the player to comply with– there is no game until a rule is set.
• A dynamic is an interactive game element where a player uses the mechanics provided to pursue an objective. This is the verb that the player embodies while following a rule– the player learns and uses the rules in a way the designer has intended.
• An aesthetic is an interactive game element where the player feels an emotion as a result of the player’s actions. This is the reason why a player plays a game, and the end result all artists aim for– the quality of the first and last (and everything in between) impression in which the player will remember the game by.

Understanding these four fundamental groups, and how the end result of each game element can be polished to the utmost quality while staying within their given constraints, is the creator’s goal.

The time limit is self-imposed by the creator. The tools (software, paper, pens, etc.) that the creator may use to develop their project are also self-imposed, but understanding the tools’ limits may play a large part in the creators’ success. If a generated mechanic is not what the creator’s tool is made for, re-generating the list or using a different tool is completely viable.

If the user/creator has a difficult time understanding a generated item, they may reference the TOOL GUIDE option built within the Conception toolkit. The Tool Guide allows the user to search through an entire catalog of available items within the toolkit, as well as a list of common genres and systems available for the creator to toy with at their leisure. Good luck!

Unlike past projects, which span over one week, Conception V3.0 spans over four weeks. I’ll keep all of the information within one post as usual, but it’ll be broken down into three distinct sections.

1. The Purpose of Conception
2. Research
3. Development

The Purpose of Conception

There are two main purposes for Conception. The first primary purpose of Conception is practice. I don’t really need to say it, but no one needs this toolkit to practice. You could probably come up with an argument that you shouldn’t use Conception as practice, seeing how I’ve set up the Tool Guide in the way that I did; I’ll talk more about that later. From what I’ve been able to find based on personal experience, you can learn how to develop a video game from a myriad of sources, from home tutorials to accredited courses. But if you’re like me, you’re a kinesthetic learner– you learn by doing and through socializing about the project.

Don’t get me wrong, I love finding great reads on anything that might be useful somewhere down the line, as well as videos and conference talks. But being able to find a learning source that is able to personally give you a helping hand is difficult. Many experienced developers are learning on the fly, too, and it’s a lesson I remind myself during each project whenever I feel discouraged about my work. This is the issue that Conception also seeks to solve in it’s latter purpose. You learn by doing, by giving yourself a generated set of real constraints to solve. Even better, the generated list you’re given is a blend of criteria that often aren’t needed together, making development more thrilling by being forced to find outside-of-the-box solutions, thus increasing the odds for finding a game mechanic that no one has used before. The other great benefit, though, is that I better understand the ins and outs of the software engine I’m using.

Going into the project, I had just finished Global Game Jam 2016 and started brainstorming for how I would approach revising Conception V2.0 into a video game format while fixing the flaws that it had before. The main issue that arose from V2.0 was this: by only generating a topic and genre as the creator’s two criteria, the genre category inhibited creativity due to a lack of understanding of any genre that was given. Providing a genre was vague to the creator, but it was also too specific. We developers have a general idea of what a genre is, so we’d attempt to work within that. So whatever that “general idea” is used to describe that genre, the creator would end up staying as close as possible within those bounds– if the creator was given a genre, they would work within the minimum requirement that allows their project to belong in that genre category. Which brings me to my second purpose.

The second primary purpose of Conception is to innovate creatively, and one of the strongest ways to innovate within the game industry (outside of new technology) is to find new mechanics and techniques that haven’t been used before. During my research for disassembling Conception and as much industry vocab as I could gather within a couple weeks, genres as we currently understand them may throw creative innovation out the window. To remedy this, I replaced the genre card deck from V2.0 with mechanics, dynamics, and aesthetics, based on the influential MDA research paper discussing the relationship between game developers, the player, and the game.

I’ll make this disclaimer right now. The Tool Guide terms within Conception V3.0 is a taxonomy that I developed to give myself a better understanding of what a game is composed of. The purpose of integrating the Tool Guide into the toolkit is to share that understanding to others, but that being said: my experience in game development is extremely limited. The taxonomy is the result of three weeks of research, and that’s not a lot of time. The lists within the Guide are incomplete, and needs much more trial and error AND fundamental learning to become academically accurate in a way many of us can be satisfied with.

Research

Alright, so from what research I have done, I needed to jump through as many time periods, cultures, and technology mediums as I could to find the throughline that defined what a game is. I don’t just mean Snakes and Ladders, Pong, or Gone Home where we’re constantly pushing the definition of a game. What about Tag, or finding all 50 states on license plates on a road trip? How about hunting, where we call our prize “game meat” and why that would be the case? What about a scripted simulation where player input is negligible to the end result, or the small games where you don’t need anything but a friend, like a staring contest? What about the games that we can’t even imagine, that are yet to be made? What makes all of them similar? Both developers and players have started to take pride in games over the years, to where it’s become a name that has to be earned with a specific listed set of criteria that can be argued on.

To “play” means to engage in an activity for enjoyment or recreation; a “game” is a structured form of play. That’s all! Failure states are optional. Challenges are optional. Stories are optional. Even a controller or a deck of cards is optional. It’s no doubt that all of these things can make the quality of a game much better, but they are all optional and are the result of an underlying rule for the player to follow. Even if that rule is to only be able to move as your protagonist, as is dubbed by the infamously named “walking simulators” (more aptly named “exploration games”), it is still a rule within enjoyment or recreation. As long as the play activity has a rule– a mechanic– and allows the possibility of a player to abide by that rule as a play activity, it is a game.

Referencing back to the MDA research paper, the original approach was to dissect each genre and sub-genre into only their corresponding mechanics. My reason for this is mentioned in Week 1’s post, but in doing so, I might better understand why an assortment of games might belong in that genre classification. I was a little more naive with that conclusion, and I later found out during my recent studying that genres are defined not only by their mechanics (rules), but by the emotions that are generated within the player (aesthetics), and how the game manipulates the player to feel that way (principles).

Mechanics, Aesthetics, and Genres

A player decides to play a game within a certain genre because they want to experience a particular emotion, whether they know it or not. If a player only plays games with high fidelity graphics, they’re usually looking for a sensation aesthetic. If another player is looking for a great narrative, they’d prefer a chronicle aesthetic (renamed from MDA’s “narrative” aesthetic to make Conception V3.0 a little easier with other terms, but it still needs work). The trend goes on.

But while discerning the mechanics that defined each genre, I found a few amazing findings that got me really excited, and are the reason why I postponed this project for a few weeks in an effort to make sure I wasn’t reading into it too much. Rather than defying all that we’ve learned in the history of the game industry up until now, what I found strengthens our fundamental understanding of game design. Please keep in mind, again, that my game development experience is very limited and I’m open to any arguments made against this project. With that being said, here’s the breakdown of my findings while breaking down each genre.

1. What we already know:
   1. Both players and developers understand genres as a method of categorizing games into comprehensible groups by their underlying mechanics or aesthetics.
   2. Sub-genres have qualities that resemble their parent genres.
   3. Genres are useful for finding other games that players may have an interest in. In turn, genres are useful as a marketing arm. (If a player enjoyed game A from genre X, then that same player might enjoy game B that also belongs in genre X.)
2. Common fundamental understanding with game design:
   1. As with most art, our goal as game developers is to fulfill what the audience (the player) wants, which are categorized into aesthetics of play.
   2. To generate a certain aesthetic, we create a game that allows that emotion to be felt and expressed by the player.
   3. To create the aforementioned game, we use mechanics to generate an emotion from the player. Ergo, to allow the generation of an emotion, we begin with the mechanics for the player to mess with (dynamics), as stated by the MDA paper.
3. Findings presented during Conception V3.0‘s development:
   1. A player will experience a specific emotion while playing a game that can be classified within a certain genre (common knowledge).
   2. Also, each genre can be distilled down to a specific set of mechanics and aesthetics, thus matching each genre with a theme or two. (my intended method for finding out what makes a genre what it is).
   3. As a result, a player experiences a specific aesthetic while playing a game that contains a strangely specific type of mechanic (unique finding).

In Layman’s terms, we had usually understood a genre as a set of vague surface elements in a game. “If the game had a gun in it, it was a shooter. If you leveled up, it was an RPG.” A genre was also classified by why we play a game within a certain genre, not just what underlying mechanics exist within it; this is how we understand genres as they currently are. By initially breaking down each genre into only it’s core mechanics, there’s a strange parallel: certain types of mechanics would generate a certain emotion. We’ve always known this to a grey-area extent, but seeing it in pure black and white was pretty amazing.

The Conception Taxonomy

To explain this phenomena more clearly, we need to use the Conception taxonomy. Luckily, it’s easy to grasp.

The taxonomy is based on current vocabulary, summing up all current terminology into a cohesive (and hopefully future-proof) definition, and is meant to require very few adjustments in how we communicate about games. Originally, the only purpose for this taxonomy was to help me categorize different mechanics into different types so I could comprehend what I was doing. But the more I learned and understood, the more it felt like I didn’t know anything, so I tried finding a way to interpret everything I found into a versatile database.

I knew that I wanted to bring Conception online for other developers to try out for themselves. Because the project felt so lackluster the entire time, I didn’t want to upload a project where no one could understand why I used the terms that I did, which is where the Tool Guide came from. But again, when I set up the Tool Guide, there were many sections that were bare and I wanted game devs to refer to the Tool Guide as a reference for other aspects of development. Examples of this are filling the dynamics section with psychology principles, and adding a genres section despite the original intention to not provide them.

Conception is available for download and is pretty comprehensive if you need to look anything up. (*Believe me when I say that most of the time was spent on research. The rest was spent on trying to learn code and having just shit luck.)

So for example, let’s say that I’m a player who really enjoys action-themed games, and you’re the developer making the game for people like me. You understand that I’m the kind of player who’s looking for a high-paced challenge and that I also want to kick the snot out of other players. To create that kind of game experience, you wouldn’t use narrative mechanics as the core of your game, since I’m not looking for a story. Instead, you’d employ conflict mechanics.

But hold on, how would you know that you should develop a game that is heavy on conflict-type mechanics? Why would using conflict mechanics aid in your sales while narrative mechanics, as your core mechanics, would not? It could be the adrenaline rush mimicked from simulating a real fight, but one thing is clear: conflict mechanics have proven to be the core of successful action-themed game titles. Fighting game genre? Short-range conflict. Shoot ’em up genre? Long-range conflict, bullet-hell conflict, and linear-direction image. When you comb through each and every action-themed genre, there are absolutely none that you’ll be able to find in which a conflict mechanic is not the fundamental core of the genre. Furthermore, all of those genres are able to reliably generate a strong sense of challenge and competition, with varying degrees of success. Therefore, you develop a game that uses a conflict mechanic as its core, polish it to a T, send it on its way, and I’m playing another game that I thoroughly enjoy.

One more example. Let’s say that this time, I’m a player who enjoys strategy-themed games– long-form challenges, more or less, but with an extended build of tension. To create this kind of experience, you’d rely on control mechanics, and you’ll need a lot of them.

Why would you need a lot of them? What’s the difference between having one control mechanic and four of them? Because that could be the difference between a Strategy-themed game and a Casual-themed game. That’s the difference between generating a sense of challenge or a sense of abnegation. Again, if you comb through all of the mechanics embedded within the strategy-themed genres and all of the casual-themed genres, you’ll notice a stark difference between the two. Strategy games rely on a wide variety of objects to balance and control, where all of which are necessary to complete their objective. Casual games, on the other hand, only rely on one clear and easily digestible objective. When it comes to strategy games, the chances of me failing my objective are much higher, thus increasing the challenge factor by a few notches.

We could go on and on, but you might get it by now. If you go through the Tool Guide, you’ll be able to notice a similar trend.

Dynamics and Principles

Deciding to elaborate on dynamics was a bit of a last-minute decision. I had a difficult time figuring out how to add it to the toolkit since its so fundamental to how we understand player interaction, but I felt that it would be beneficial to bring one of the most powerful tools for a game developer: being able to manipulate the psyche of the player through thoughtful design.

Initially, I added this category as the 15th mechanic type labeled “principle”, but it was a game element that acted very differently compared to the other mechanics. The player wasn’t interacting with any rules; principles acted as if the presentation of the game itself interacted with the player, or even the developer themselves were interacting with the player. I decided to define principles as the presentation of a dynamic which focuses on how the player is influenced to elicit a specific interaction. These principles are only used effectively when the player plays the game, ie. when the player is going through the dynamics of the game, which is why I decided to put it there. These principles act as the intermediary between setting the mechanics in motion and the player playing the game for their aesthetic purposes, by using principles to nudge them into thinking in a way that enables their aesthetic purpose to become a reality.

Systems

There’s one more thing I need to mention before I wrap up this research, and it’s the subject of systems. Systems are nearly identical to genres, except that a system is created as a result of a successful game. Unlike genres, which are mostly static, a system is born from a set of mechanics within a game that have become widely popular with many players. Examples of such systems are the Nemesis system or the MetroidVania system. Systems serve a similar purpose to genres, however– categorizing a newly developed game into a system means that the developer aimed to create an experience similar to the original game, rather than creating an experience from an aesthetic.

Additionally, if a game has more than one such memorable system, each system is designated with roman numerals– the numerical order doesn’t mean anything except to differentiate the systems from one another. A Rogue (I) system (or a rogue-like), for example, is based on the video game Rogue. For a game to be considered one of the popular rogue systems, the game requires the following mechanics.

• Rogue (I) System [rogue-like]: Permanent death event, strict turn-based event, procedural generation AI, tile-based image, isometric image, labyrinthine movement.
• Rogue (II) System [rogue-lite]: Permanent death event, persistent progression event, procedural generation AI.

If a peculiar game is released that doesn’t fit any genre classification criteria, listing it as its own system works fine.

Conclusion

The longer I worked on Conception, the more I wanted it to be presentable to other game developers. Otherwise it wouldn’t have taken three weeks to do the research alone. At first, I just focused on topics, mechanics, and genres. Then I looked into genres that had originated from games: the -likes of the industry. Then I looked further into the MDA paper and other definitions of a genre, and incorporated aesthetics. Finally, I read a book called Universal Principles of Design for the game design book club I joined this month, and wanted to share the useful knowledge with developers in a way that could be relevant to our industry– these terms came to be known as the dynamic principles.

I also added two new aesthetics and four themes.

The first aesthetic is abnegation, which was a neat add-on by the team over at Extra Credits. The second aesthetic is tension. Players enjoy being scared, only to realize that they’re perfectly safe and everything is okay, and those kinds of players love that experience. There weren’t any aesthetics that really fit the bill, which is why I added it. It also works strangely compared to the other aesthetics; relying on mechanics and aesthetics alone aren’t enough to make it a tension aesthetic. A game with tension creates anxiety, which can only be done by messing with the player’s perception of the game and reality itself. This requires a dynamic principle that allows the developer to nudge the player into thinking one way, and then messing around with the player’s ideas. The most powerful of these is the mental modeling principle, which so happens to be a principle that Frictional Games use so well, as proven by their games Amnesia and Soma.

The four themes I implemented are channel, cadence, party, and horror. Horror works in a similar way to tension, and many players are familiar with party games– except when we want to talk about what counts as a party game. We can go about it in two ways: a video game with lots of people, or a real-life game with lots of people. So there’s a lot of camaraderie there, but how do you talk about the latter? This is what a concession game is, which is a genre I implemented into the taxonomy. What counts as a concession game? Beer Pong, Hide and Seek, etc. With a party theme in place, we can talk more about games that people used to play before the invention of video games, or even the smallest games such as Rock, Paper, Scissors.

The other two themes are a little strange, but they’re incredibly useful. The channel theme allows us to talk about games that are dependent on the medium being used. Virtual reality, augmented reality, and alternate reality games are categorized here, alongside tabletop games, light gun shooters, and twin-stick shooters. The final theme is cadence, which is dependent on audio. Rhythm games, music games, and audio games have been sitting as outsiders of the industry, partly because it’s a niche market. But without a cadence theme, games such as Panoramical or Papa Sangre II are left to sit in the dust due to these three genres standing on their own with little support.

The tool is not complete. By the time I figured out I was missing other key genres such as MUD, CCG, TCG, and many others (I probably should’ve added a genre that Superhot and Quantum Break could belong in), I was already too far into the development stage to add them to the list. There are other systems, mechanics, dynamics, aesthetics, and topics that are missing. Sports is a big one that I completely forgot about, and will probably need to be the odd 11th theme. But I’m confident that the next time I work on Conception, it will be the final product with continuous updates.

Development

With as much time as I spent working on Conception, I wanted it to be as polished as it could be. Yesterday, I thought it was. Today, not at all. I found mistakes I didn’t catch during the last test session prior to uploading (was in a rush since my uncle visited this weekend). But per the rules of this blog, once it’s uploaded, that’s how its going to stay.

Initial Planning

From the beginning, Conception has been a pretty utilitarian project. It needed to be attractive on the sole basis of what it could offer to a game developer. Similar to Tooth Baby (look, it’s a terrible name I made on the fly), it has a black-and-white 8-bit aesthetic to save on time while allowing the project to look cohesive. And don’t worry, I won’t be using black-and-white for these next few projects.

After doing some introductory research during the first week, I did a little bit of sprite work and made most of the symbols that are seen at the top of each section. I was also figuring out how to add a custom font into the project, so that I could create words that the player to click on and a description would appear. I spent three days on that task alone. Development was going nowhere, so I spent the following day doing more research, which is when I got caught up in it and spent an extra two weeks on research. The fourth week was spent solely for development, and I promised myself that I would get it done before this week was over because it’s been way too long as it is.

The Tool Guide

Developing this project is easily the most tedious work I’ve ever done in my entire life.

Finalizing the Conception taxonomy ended up taking 40 pages worth of documentation on Google Docs, over the course of three weeks. My programming skills are still god-awful, so instead of writing code that allowed a typed-out word to be made, I drew every single NES-fonted word in the game. I found a reference for the original NES (Nintendo Entertainment System) font, and drew each symbol as it’s own sprite on Photoshop. Afterward, I looked up each term in my taxonomy, and created a template for me to drag each letter into, so I could create each term as it’s own sprite. I continued this process over the course of week three alongside my research. There are a total of over 415 terms, and over 450 sprites used. Once the sprites were implemented into the project, I converted nearly every sprite into an object, creating about 430 objects in total.

Within GameMaker, the developer can create a room, which is where all objects are placed for the player to interact with them. Again, my programming skills are non-existent, so I couldn’t make objects disappear and re-appear as well as I would have liked. As a result, there are over 120 rooms instead of what could have been ten rooms (maybe). Afterwards, I gave each clickable object the ability to move from room to room, as presented at the top of each page. Each page that you can find within the tool is a room, with objects individually placed within them.

Constraint Generation and Descriptions

The next big task was to actually have the Generate portion of the tool working properly. During the first week where progress was halted, I was having a difficult time comprehending data structures as a solution to a customized font. In an effort to save time this time around on the fourth week, I asked my game jam partner from Ludum Dare 34 for some programming help with both custom fonts and having objects within a list appear. He gave me a couple solutions, but he wasn’t too sure either. The great thing, however, is that by looking into his suggestions, I was able to find some other solutions that could help me out.

The custom font never worked out as I had intended, which was to have the descriptions appear with an NES font alongside the drawn objects. I asked for help on the forums as well as using some other links, but I ran out of time before I could implement the solution they provided, and I eventually added the descriptions with a font that already came with GameMaker.

After hitting a dead end with a custom font, I looked into object generation. I learned a bit about arrays and, with more tedious work, assigned over 415 objects with a 1D array. That didn’t work the way I wanted, so I went through the list again and replaced the 1D arrays with 2D arrays, with each array corresponding to a Generate section, and it worked nearly perfectly; it kept running the same seed each time, so it wasn’t truly random, but it worked as intended.

Afterwards, I looked for a way to have the descriptions appear whenever the player hovers their mouse cursor over a word. Luckily, adding the descriptions was easy after deciding to omit the custom font, but it was still tedious. I gave nearly every object (430+) their corresponding descriptions, but they weren’t aligned properly and would stretch past the tool’s display window, if the description was long enough. So I went back into each description to make sure they were all aligned properly.

The last thing I want to mention is why I ordered the Generate categories in the way that I did. As it is right now, the terms generates in this order: topics, mechanics, dynamics, aesthetics, theme, and genre/system. The developer chooses their constraints, but only by moving downward. So if a developer wants to use a Cadence them, they have to use all of the game elements presented before that. In the case of this picture, the developer would also have to use the airborne topic, step-based conflict, the edge alignment principle, and the tension aesthetic if they wanted to use that theme. So why did I implement that rule?

Most beginner developers start with a narrative setting. If you’re a beginner, you don’t know that it’s a bad habit yet, and you just want to make a game with a great story, or you want to practice your art. Conception lets you do that and indulge. It’s a bad habit, but it’s also a driving force to keep learning. And what good is game development if you aren’t invested? Many starters quit when it gets difficult, and starting with a topic helps you stay invested.

The next step is the mechanic, or the building block of any game. If you aren’t thinking in terms of mechanics, you definitely will at this point, and this is where it gets rough. Making a certain mechanic work as intended will force you to be familiar with the tools you’re using to make your game. You can fall back to your topic as a handicap for ideas if you’re unsure of how to implement it. And if you use this tool often, there will be times where you’ll get a strange mechanic you’ve never seen in a game you’ve played. As a result, you’ll toy with your game engine in a way it wasn’t intended for, which is a neat way to find the limits of your tools. If you get a third-person image mechanic on a 2D game engine, good luck.

The third step is the dynamic principle; this step asks you to start thinking more about the person playing your game. How are you going to get them to do what you need them to do? If your game’s design is unusable and your player doesn’t know what to do, your game is a bust. Sure, you can teach them by explaining through text, but there will be instances where you won’t be able to use words to ask the player to interact with something. If you’re able to successfully implement every principle through artistic design, you can make the player do anything and they won’t even know it.

The fourth step, and some might argue that its the most important step, is the aesthetic. This step asks you to start thinking about your audience. Players decide on what game to play based on the game’s aesthetics of play. Before the player purchases your game, they will be looking at the art and gameplay trailer. Based on the emotion that image evokes within that person, a first impression is created. The stronger your game’s pitch is to your audience, the better your game will sell. At this point, you’ve seen a lot of topics, mechanics, and dynamics. There are plenty more, and only a select few will get your audience to start talking and to start pulling out their cash as soon as they see it. At this step, your job is to create a game experience strong enough to get your audience to do just that.

The fifth step is the theme. Each theme is categorized by certain mechanics and aesthetics, with horror being the one exception that also contains a dynamic principle. This step asks you to expand your audience across different gaming communities. If your intention is to make an action/casual-themed game, you have a long road ahead. None of those themes’ mechanics or aesthetics match, and in most cases, conflicting aesthetics results in alienating both audiences rather than uniting them, as was the case with Crypt of the Necrodancer versus Darkest Dungeon. It’s not to say that doing so is impossible– just difficult. Widening your reach is the most difficult thing for you to do.

But in the context of Conception, I lied. The sixth step is the genre/system. In a typical hierarchical order, the genre would be the step before the theme, since all genres can be categorized within a theme and not the other way around. Your audience is narrower. However, this step asks you to do some pretty impossible things– develop a game that exists as a particular genre, while attracting your theme’s audience. If you draw a party theme, followed by a turn-based tactics genre, you’re going to have a bad time. If you manage to pull off developing a game as contradictory as that, and make it sell over 50,000 copies, I wouldn’t be surprised if you get an award or something.

So there’s the reason why it’s ordered in the way that it is. It definitely wasn’t arbitrary or something. Ha. Ha. Ha.

Polish and Conclusion

On the final day of working on Conception, I cleaned up the main menu and gave each menu option a small description if the mouse hovered over it, to let the player know how to use the tool. A how-to description was also implemented on the Generate section, though I didn’t realize that a word was cut off until today (as I write this).

Again, more could have been done to clean this up. At the time of me uploading it, I triple-checked it to polish what I could, and still found mistakes. The intention of adding a checklist capability was there, so players could customize what could be generated for them, but it ended up not happening. There was also another idea that ran through my head, where only certain terms were available via a minor level-up system, and players could unlock more terms after finishing their first project. This idea felt moot since the current version of Conception is more about self-encouragement and providing a reference, not to provide a structure to learn. The project is better this way, I think, so that if there are developers who don’t really have a vocabulary to speak about games yet, they might be able to do so with this toolkit. So I’ll probably add a learning system like that in the final version, since that might be what some game devs have been asking for.