Design Guide // Doing Better Research to Inform Your Hack's Design

Hello Fire Emblem Universe!

A while back I recorded a video called Hacks you should play if you’re making a hack.” This video provides a recommendation for hacks you should play to draw inspiration from across a number of dimensions when working on a project.

I’ve seen some discussion recently on the discord regarding hack recs, what people play for inspiration, and of course, general design ideas. I was inspired to make this post to take what I stated in the video a bit further and provide more practical, hands-on advice for getting better at doing research.

When I started hacking, I did a lot of research to understand what players enjoy and dislike so that I could make a game that would have broad appeal. This process, while perhaps overly rigorous for a hobby project, ultimately helped me become a more informed designer and allowed me to figure out what would make the game fun and distinct, while also showing that you didn’t need to reinvent the wheel to make good GBA-inspired FE. I want to share my process and expand on it in-depth with my experience and learning so that you can think critically about the research and design process.

Generally, we play games as consumers. We play as a designer intended for us to do, messing around in the sandbox and feeling emotions based on how the experience makes us feel. If you are making a hack, I recommend you play a hack (or vanilla FE game) as a researcher, understanding what makes certain things work, why certain elements make you feel a certain way, and what can be done to take an idea that doesn’t land and make it better.

It is critical to remember that “The thing I dislike =/= bad design”.

Most ideas aren’t bad on their own, it is all about execution of those ideas. We often use “bad” as shorthand for things that really mean “hard to execute well”.

Almost any gameplay related idea for FE that I’ve seen seriously proposed can work, but chances are it requires much more rigorous planning, testing, and execution to make it work. You also need to break this down further - why am I doing this and what will it achieve? There may be a better way to accomplish what you set out to do.

By reading this guide, you should be able to:

  • Identify and scope the different elements for your project that you will want to consider for development
  • Research projects using multiple methods to validate how different elements can come together to make something work
  • Test effectively to ship a quality project that both you and others will enjoy.

This guide will be broken down into sections and sub-sections that should help you establish a workflow. While the guide assumes you are starting from scratch (ie a vanilla ROM and a dream), you can do this throughout the dev process. However, for some core stuff, the more you can do upfront, the better you’ll be long term.

My goal in this guide is not to encourage homogeneity in what gets made. Variety is the spice of life. This should help you sharpen your focus and think more like a developer bringing a product to market. While everyone’s motivations are different, generally I find that folks who build FE hacks want to make something that they and others will enjoy, so this mindset is important.

I am assuming that you are building a Fire Emblem hack with custom assets, story, maps, etc.

Scoping

Identifying your player

The first step is understanding what sort of FE fan you want to appeal to. This cuts across a number of dimensions.

FE fans are diverse and have varied interests in what they like about FE. Some are more focused on gameplay, others more so on story and characters.

Recognizing what you like in FE and what you think others will enjoy is important in building something that people will want to play. While you should enjoy your work first and foremost, I know many folks express discontent when they feel like their work goes unnoticed. Part of avoiding this is figuring out the persona of your target player and understanding general trends of the hack playing audience.

Consider:

  • What difficulty makes sense for the target player?
  • What vanilla games does this player like?
  • What elements are most important to this player? Gameplay, story, supports, etc.
  • What sort of tone will this player want from a game?

You should answer these questions yourself. Generally, if the hack is quality, it will have a broad audience, regardless of whether specific mechanics or inspirations are popular. You will want to make sure that you’re generally consistent - for example, you wouldn’t want to build something that oscillates between the simplicity of FE9 normal mode and FE12 lunatic - chances are, these are different core audiences due to difficulty, mechanics, and gameplay/story orientation.

Ultimately, it’s all about execution, but that starts with having a clear idea.

Knowing this is essential.

The 5 elements of the hack

Now that you know who it is that you want to design for and what their preferences may be, it’s important to break this down into specific elements. Knowing these elements that make up an FE game will inform your research and design.

  • Difficulty - How would you frame the general challenge level of your game? For example, do you want the primary mode of play to feel similar to FE7 Lyn Normal mode, or do you want FE11 Hard 5? Gauging a rough difficulty will give you a good touchstone to refer to when designing the challenge level, and also in articulating difficulty to your audience. Ex “The intended difficulty of this game is comparable to FE6 HM w/o ambush spawns”.
  • Mechanics - Which mechanics do you want to focus on or include? These are often positioned as “features” in the first post of a hack, such as using dismount or capture. Different players will be biased for or against different mechanics. The opportunity for innovation is crossing over mechanics from different games and synthesizing into one package, or even taking what a vanilla game does and doing it better.
  • Writing - Do you want a serious story set in an immersive world? Do you want it to be grimdark or noblebright? These considerations will not only help you better align to a target audience, but can also shape how the other elements are interpreted. Similarly, is your story meant to be plot-focused or character-focused? How does the world work and function? Having these items organized will help you better position the hack’s narrative.
  • Aesthetic - What kinds of color do you want to include in the hack? This includes things like map and battle palettes, battle frames, menus, and portrait colors and design. Having a good sense of the colors you will use will help give a hack a distinct flair. Additionally, the type of music you choose to use w/ this will also pair with the visuals.
  • Gameplay - How do you want the hack to play? What sort of weapon triangle, weapon system, etc. - like mechanics, many of these fall under “features”, but generally lean more on manipulating numbers and existing systems rather than adding in new ones. Knowing how you want the game to play and understanding where you draw inspiration from is key in both executing on classic concepts/fundamental FE as well as innovative, “high-concept” style maps.

We are barely scratching the surface and you can do a deeper review of each element. The goal in this section is to give you the vocabulary to break down the different elements of the game broadly so that you can organize your research.

The synthesis of these ideas and how you execute them will culminate in your design vision, and ultimately in the finished product.

Your design vision

With these elements and an understanding of your player, you’re now positioned to define your design vision. It’s important to have this type of written understanding of what you aim your hack to be about so that you can share it with other players. More importantly, this will help you ensure that what you’re building is in line with your vision and foster consistency throughout the project. No one likes random difficulty spikes, hacks that have highly varied quality bars, or hacks that lack focus - it’s easy to tell when you threw in every feature imaginable, but hard to make that all work well and feel consistent.

This should be your guide, or tenets, around how you make decisions surrounding what actually gets put into the game. Knowing what your game is meant to be about will help ensure everything you do reinforces that vision and helps you realize it.

Considering the type of player you have and the elements above, you should be able to produce a fairly concise overview of what you’re setting out to create. Let’s bring it altogether to illustrate an example. In practice, you may do something simpler, but I am breaking down each element more in-depth for educational purposes. Regardless, thinking this through and having it to point back to will serve you well when doing research and building your game.

Ex.
Your player - Old school FE fans disgruntled with the direction the modern series has taken. Wants something more challenging than vanilla FE8 HM, but nothing that makes them think too hard. An even mix of gameplay and story focus, with preference towards gameplay. (Yes, I am describing myself for learning purposes).

The elements of your hack:

Difficulty - I want to make something that feels like FE6 HM, but w/o ambush spawns. You should be able to win if you pay attention and do some light math, and will lose if you get too comfortable. You have a decent margin for error, but you can’t rest on your laurels.

Mechanics - I want to do something that feels like vanilla GBA, but it has a few other elements like dismounting. I also want to try using Laguz mechanics since I think FE10’s implementation was bad.

Writing - I want to write a story that is serious, but isn’t afraid to inject humor. I’m more concerned with the plight of the protagonists and the world than I am with the events. I’d say it’ll be a character-focused story.

Aesthetic - I want to use washed out colors, with a particular emphasis on teal, brown, and grey. Tonally I like the MIDI electric piano and think some jazz could work well across the soundtrack.

Gameplay - I’m going to stick w/ a generally vanilla FE8class-set, but make soldiers not stinky. I also will add FE5-style Hunters, alongside mono-weapon cavaliers and armor knights. I’m going to make the triangle less important and design maps that empathize smart use of staves, like in FE5 or TRS. I want combat to feel like you’re playing a more difficult version of FE2.

Taking this example, you could put together a more concise feature-list and descriptive blurb for your hack. We’re getting into the territory now of “building” the hack, which is out of scope for this guide.

The main points here are that you need to understand the player, the elements of the hack, and determine what you want to make.

The next section will focus more on research to figure out how to learn what works so you can execute your ideas well. To actually build it, I recommend checking out my video here “How to finish your romhack”, which covers the more tactical elements of planning development. This remainder of this guide focuses on how you can organize the research that informs what you are creating.

Researching

Planning your research

Now that you have an idea of what you want to make and your goals, it is important to plan your research. Researching other hacks, Fire Emblem games, video games, history, and media broadly are all potential sources to draw inspiration from. I’ll focus on hacks and vanilla FE since it is most directly applicable. I may add a section to the guide that covers how I would research other forms of media later.

How you conduct your research should tie back to the 5 elements of the hack. Different FE titles will be able to provide you insight across the board, but some are better than others. For example, the average FE fan would probably tell you to take character writing cues from FE9 more so than its gameplay cues.

Good research starts with good planning. I don’t expect everyone to be rigorous in how they plan their research, but having a framework to fall back on should be helpful when organically playing and watching games.

I recommend approaching every game you play with an open mind, but to keep the 5 elements in mind as you review them. I challenge you to think critically about the emotional response you have to a game and reflect upon your experience engaging with it. Thinking about different elements individually when parsing a single map or a full game is important in figuring out what works.

Here are some sample spreadsheets you can copy to capture your thoughts. I recommend making your own copy and capturing your feedback this way so you have a running record of your thoughts and can easily reference other chapters.

I learned a lot from recording myself play FE and talking about my feelings after, so I would have the record of what I was experiencing. If you can record yourself playing something, I recommend it. If not, try capturing your own thoughts at a chapter-by-chapter or game level to ensure you don’t forget what you’ve learned. You’ll want to be able to assess your more informed opinions later on to parse everything.

The easiest way to start is to create a list of what you’d like to play or watch someone play. Chances are, if you’re reading this, you probably are well-versed in vanilla FE and possibly well-versed in hacks.

I recommend going into the directory and trying stuff out. I also recommend playing both [complete] and incomplete works - chances are you will have something to learn across the spectrum.

If you’re particularly structured, I’d download all relevant patches and make a list of what you want to play, capturing your thoughts on the spreadsheet. From there, you should decide what you should watch and what you should play. We’ll dive into these more in the sections below.

Playing

Playing FE is really the best way to learn how to make FE work well. If you play with a critical eye and analyze what you’re doing, you’ll likely be able to discern how different elements of the experience come together to make the hack work, and also assess why you like it.

Benefits of playing FE directly:

  • Assess your own feelings on a work.
  • Experience at your own pace.
  • You get to gauge your direct reactions to what is happening.
  • You can experiment yourself and see what the game allows you to do - how does this game appeal to you as a player?

Because there is so much FE out there to consume, I’d prioritize playing things that 1) you feel you are more inclined to like or learn from and 2) don’t have a lot of footage to go on. For example, if I was doing research from scratch, I’d likely only play incomplete hacks that don’t have a lot of airtime on YouTube, and lean towards watching LPs of vanilla games. However, this is entirely up to your preference. I personally did a mix during my own hack’s development.

When you are playing a hack, think back to the 5 elements of the hack. What stands out at any particular moment?

Below are a few specific items you should be asking yourself as you’re playing. As the player, you’re well-positioned to answer these questions.

Difficulty

  • How much margin for error do I have for mistakes?
  • Is the game punishing me when I get too comfortable?
  • Does the game create difficulty “fairly”? Am I getting sucker punched by reinforcements?
  • Is victory generally within my control?
  • Do boss battles feel good to participate in?
  • Is the “cognitive load” for each map too high? Does the level of difficulty enhance or detract from the experience?

Aesthetic

  • Does the color scheme help enhance the tone of the work?
  • Are the palettes pleasing to the eye?
  • Do the menu colors, battle frame, and other UI have a distinct look/color to them that makes them stand out?
  • Are the mugs pleasing to look at?
  • Do I get distracted by the quality of any of the work here in general?

Writing

  • Does the writing provide enough context for me to understand what’s happening in the story?
  • Are the characters likeable? Do their actions make sense in context?
  • Does the hack’s written tone stay mostly consistently?
  • Are character interactions and dialogue good? Do I find myself wanting to learn more about certain characters?
  • Is the plot convoluted or is it easy to follow? Is there enough explanation of the lore?

Gameplay

  • Is the game “smooth” to play? Do I find myself wanting to keep going or feeling like I need to stop?
  • Do maps have interesting objectives?
  • Do maps execute their objectives well?
  • Does the flow of battle feel thoughtful? Is turn-by-turn play satisfying, or does it feel unbalanced?
  • Do I spend more time attacking or waiting on player phase?
  • Is the game good about giving me enough money and items to do what I need to do?
  • Am I having fun? Do I want to play this again?

Mechanics

  • What changes did the author make to the vanilla ROM?
  • Do the mechanic changes make the hack stand out?
  • Do the mechanics enhance or detract from the experience?
  • Could any of these mechanics be executed better? If so, how?

^^ All of these questions are just a starting point. But as you’re playing, capture these thoughts and catalog them in your mind or write them down. I’m sure there are more questions you could ask yourself, but let’s go w/ these for now.

I am hesitant to give sample answers to these questions because everyone will have different preferences depending on their target audience and design vision. You’ll need to analyze the work and play for yourself.

Keep the above questions in mind as you play and look further into anything you find interesting.

For example, if you played The Last Promise and felt like Shon w/ the piercing sword was more satisfying than a typical rapier lord, take a deeper look at the numbers to see why - maybe it’s the MT of the weapon? Maybe it’s the stat balance between Shon’s strength and an enemy’s defenses? Maybe HP is at such a place where it feels like it takes the “right” amount of hits to kill on average?

You can expand on these endlessly, but the goals of the above questions are to help you firm up your opinion and label different elements accordingly so that you’re better equipped to think about, talk about, and design around them.

Watching

If you aren’t playing FE, watching FE is the 2nd best thing. Watching FE has a number of benefits.

Benefits

  • You can see how others react to what’s happening
  • You will get insight from individuals that helps you better understand potential audiences’ and their preferences
  • You can look at video chat logs or comments to see how others watching felt
  • You can do this passively while working on other things.
  • You can do this faster and skip around more easily to specific chapters/maps.

I recommend finding Twitch streams and YouTube channels that you like. Tune in occasionally to the #playtesting channel on FEU discord to watch people test their own works, usually for an audience.

When choosing what to watch, I recommend watching folks who are 1) analytical about what they’re playing, 2) can describe what they’re experiencing / emote well enough that you recognize how certain elements make them feel, and 3) are easy for you to listen to.

How you watch is up to you. I typically watch FE by keeping an LP on in the background, listening to it like a podcast, looking over to the window to see specific setups and get a sense for different elements. I’d tune in and out a bit depending on what’s happening, learning to hone in during parts where I was getting good insight based on the LPer’s reactions or what was happening on screen.

I recommend cataloging your reactions to what you’re watching on the spreadsheet so that you can easily reference this. For me, I watched a lot of LPs to not only learn about specific games and maps, but also to get greater insight into the player base and assess broader trends.

For example, almost every person I ever watched on YouTube expressed extreme displeasure at ambush spawns, at Plum’s recruitment in TRS, and generally anything that encouraged back-tracking through a map. You’ll likely pick up on trends as tastes change over time, but keep these things in mind. People recording generally do not shy from sharing their opinions, and that can help you get a sense of what players may enjoy / dislike.

While playing the game yourself gives you insight first and foremost into how you feel, watching others play gives you insight into how others feel. One of the biggest benefits to watching someone else play vs. seeing written feedback is you get to see their emotional reaction before they try to hedge it by being polite. Learn to look for that and use as a guide to better understand things that aren’t working.

Use the questions from the “Playing” but substitute yourself for the LPer. Of course, your own, second-hand reactions to their reactions are worth considering as well.

Be thorough and well-informed in your research and you’ll be better positioned to put together something compelling. Consuming FE in different ways and through different lenses will help you get a well-rounded picture of how to make these games work well and aligned to your design vision.

Discussing

As you consume FE, it’s important to also gauge how others feel about what you’re thinking. Oftentimes, designers work alone, at least when they are first getting started, so getting initial feedback on your ideas, especially prior to implementation (ie something for others to play) can be challenging.

I recommend using channels like #fe_design_meta on the FEU discord to bounce off ideas and get opinions from others. As you get started, it can be beneficial to put together a group of others whose opinions you trust to support you and help you brainstorm ideas.

Learning from research and throwing out a solution in discussion can be a good and fast way to get feedback on an idea, the technical feasibility, and insights into execution can be a much faster way to get a sense of what players may think about it. However, you must also use design meta wisely in order to get anything meaningful out of it.

When asking questions, framing is important. For example: “Is it possible to do X” is very different than “How do you feel about X?” - we thankfully live in an age where almost any mechanic or idea is theoretically executable if you put in the work to learn ASM or the eventing engine well. Getting opinions on how your idea may work is more insightful and will lead to better discussion.

It is also important to consider context. Like I said above, almost any idea can work, but some are harder to make work than others. Remember that showing things like stats and growths without any context is useless, and impossible for others to gauge. Most things ultimately will need to be tested when you are getting that granular.

I recommend using design meta to gauge how people feel philosophically about an idea or for recs on how you could execute something. It’s important to lay the context and share why you want to do something.

Example: “I want to make mounted units less busted than they are in vanilla. Do you think that players would rather me make their stats generally lower than infantry units or should I instead focus on using more anti-cavalry weapons + buffing them from vanilla? Perhaps both? What do you generally think about this?”

This kind of question, context setting, and framing helps open up discussion vs. getting a simple yes/no answer. Now you can gauge how different players may feel - your goal is to better balance cavalry units than in vanilla. You can achieve that through a number of methods, such as what was proposed - design meta discussion can be an avenue for exploring which path may be most pleasurable while getting to the intended outcome - better balance. Like anything, you need to do a macro view (how does this class function against all other classes?) but also a micro view (what specific interactions or decisions will help facilitate this broad view?) - if you’re unsure and keen to hear opinions, questions like this can foster good discussion.

Similarly, asking people for good samples to learn about specific elements in greater detail would be a good use of the design meta chat. For example, if I am looking for a hack that does difficulty well (ie is it fair and more difficult than vanilla), I may be able to source some recommendations that I can then prioritize for playing or watching.

Of course, take everything with a grain of salt as every person has their own bias. Learn these. With good insights, validated by yourself and others, along with a clear design vision, you are now ready to build & test.

The next section will focus on testing your ideas and ensuring they come together well.

Executing

Self-Testing

I will assume in this section that you know how to build and assemble your chapters. This section focuses on testing.

Playtesting your hack is important. Like with writing, revision is part of the process. The most popular and well-received FE hacks generally go through rounds of revision and review after extensive testing.

The purpose of testing is three-fold. 1) does the chapter work ?, 2) is the chapter achieving its objective?, and 3) is the chapter fun?

I break down testing into these 3 components because they reflect the different stages of quality.

Step 1: Making the chapter work.

  • This is the most baseline expectation for a hack. This stage ensures that you’ve removed all bugs and glitches that impact the ability for the player to complete a chapter. This is the bare minimum requirement for sharing your work with someone else (more on that below).
  • To test effectively, I recommend booting up the chapter and making changes live as you play through it, only resetting when you need to if something breaks. Things like text errors you can fix without stopping.
  • Your goal here is to ensure the chapter is in a playable state - can you trigger the end event and move onto the next chapter w/o any glitches or “unintended” items occurring?

Step 2: Assessing if the chapter is meeting its objectives.

  • Now that you have the chapter built and working, the next step is to consider your objectives. “Objectives” in this context can mean multiple things. Think back to the 5 elements of the hack.

  • Writing: Is the story/plot moving along as it needs to? Do the characters speak in their voice? Does it make sense?

  • Aesthetic: Does the music and visual palette strike the right tone for the chapter? Are all the backgrounds fitting?

  • Mechanics: Are all my mechanics working as intended? If my objective is to encourage use of a particular mechanic, am I able to achieve this with how the map is designed?

  • Gameplay: Does the flow of combat feel good? How does each turn play? Are events occurring at the “right” times (ie anti-turtle objectives, mid-map events, AI changes, etc.)

  • Difficulty: Is the difficulty generally aligned w/ the chapters that come before? Is it an appropriate level of challenge? Is it fair?

While some are more essential than others, depending on the complexity of your map and your design vision, you may be more focused on one element over the others. For example, when building a chapter 1, I am generally more concerned w/ getting gameplay and stats right and establsihing character voice. Chances are a chapter 1 map is very simple and has only one objective like defeating a boss and maybe a simple anti-turtle. For a mid-game map that is more complex w/ more eventing and objectives, like a “destroy supplies” map, I will probably be more focused on ensuring specific mechanics work and the overall difficulty compared w/ prior chapters.

At the end of this stage, you should feel good about the chapter’s ability to do what you want it to do and ensuring it aligns to your vision.

Step 3: Is it fun?

  • This final step in self-testing is an ongoing process. You could ruthlessly optimize and tweak forever. Eventually you have to accept that this is “good enough” and can share. This stage generally benefits from outside playtesting, but I want to include it here as you should also put in some effort to ensure what you’ve made not only works, but is also fun.
  • This stage generally involves more minor tweaks. At this point, you have a good foundation and are executing on different elements well enough that it is “passable”. Here is where you make smaller edits and tweaks to improve the flow of the game, clean up the script, and improve visuals and tone.
  • For example, while in stage 2 I may be debating what turn to add a brigand on to destroy a village by X time, in stage 3, I am going to think through their precise stats, what weapon they wield, and try to mitigate any sort of cheese that the player can pull on them that “breaks” the chapter.

Once you have completed these 3 steps, it’s time to get additional feedback.

Outside Playtesting

Getting outside playtesting is essential. As you get started, I recommend using the #playtesting channel on the FEU discord. For me, I brought in a number of folks willing to playtest chapters and share detailed feedback. Many of the best ideas in Vision Quest came from this group and from their experience with my first drafts.

For many, sharing their work before they feel it is “ready” can be tough. I challenge you to think like a product manager - you want to have a “minimum viable product” that is playable and meets the core objectives, then go to a playtester (ie, a sample of your target audience) and see what they think. Get a few opinions and tweak accordingly.

I generally like to have playtesting done once I’ve done enough work in steps 1 and 2 above. Outside playtesters are really going to give you a lot of good feedback on stage 3, and even stage 2.

To make the most out of outside playtesting, there are a few things I recommend.

  • Watching someone live stream - ask them q’s throughout and get their opinions. Gauge their emotional response, how quickly they beat the map, how engaged they seem, how they react to different elements - this will give you a sense of how the hack will appear to your audience.
  • Watching a recorded video - while you lose the direct communications aspect here, seeing a video of someone playing your work can give you a more organic view of their thoughts and feelings while playing. It also avoids the risk of “giving them the answer” if you’re watching live. Look for raw reactions here, similar to above.
  • Written feedback - If you can’t get the above two, written feedback, ideally chapter by chapter, is helpful.

Always ask questions about the feedback to dive more into what someone means. I made a video about giving and receiving feedback, which should help you get better at asking probing questions to dive into what they mean.

Ex.

Playtester: “I didn’t like this map. Defend maps are bad.”
Hack creator: “What do you mean by that? Was there anything specific that didn’t work?”
Playtester: “I felt like I was in the same place the entire time. There wasn’t much incentive to move. I just wanted to slam wait every turn.”
Hack creator: “So it sounds like an anti-turtle may help then?”
Playtester: “Yeah, there’s no reason to go outside the starting area. Adding some chests and thieves may encourage more dynamic play.”
Hack creator: “I will do this, thanks.”

Before you make broad, sweeping changes - look for trends. If multiple people playing who you trust to have a good sense of the design you’re going for (and this is important - giving you feedback to help you do better at executing your design vision vs. their vision), you should probably action it. If someone is telling you everything is bad and suggests something very outside of your design goals, thank them, but ignore most of it.

Ideally, your “outside playtesting” phase pre-release will predominantly include a trusted circle of folks who can help elevate your work prior to release.

Release

At this stage, your work has gone through a number of revisions. I recommend having at least 2-5 other people look at and play a series of chapters before you release to validate that your objectives are being met and that it is fun.

From here, you are ready to release and get public feedback. I recommend setting up a thread, detailing your design vision as stated above, and showcase features about the hack to set up player expectations accordingly.

Continue to gather their feedback and adapt it accordingly. I usually recommend releasing in phases (ie 5-7 chapter chunks) and using the initial post-release phase to do reworks based on feedback from others.

As with the above, remember to look for trends and seek feedback that helps you better execute on your design vision. However, if you are met with a lot of resistance, you may need to revisit this vision and adjust it accordingly or re-assess what you know about the playerbase.

Ultimately, this is an iterative process, but it starts with strong ideas, validating those ideas from good examples, executing them, and rigorously testing. Good luck!

Thanks for reading and I hope you find this useful. Would appreciate feedback + insight into how you do research and inform what you build.

See edit log below.

7-Feb-22: Guide includes intro and scoping section. Next will be diving into research. Wanted to get the bones set up for this and set the stage since the research section will be meaty and require more time to adequately put together. Appreciate your patience as I map this out.

8-Feb-22 Added “Discussion” sub-section under “Researching”. First draft of text added to all sections in “Researching”.

9-Feb-22 Added “Executing” language.

35 Likes

Reserved in case I need it.


Will be adding an example here. Stay tuned.

2 Likes

man this is going to be so helpful.

well for self testing, I generally play through trial and error and correct stuff until I’m satisfied with the map.

as for outside playtesting, like promoting, recruiting members for various tasks, I generally use the feu website or discord.

for release idk it depends probably post a versions and make improvements as per feedback or if you well don’t feel like doing it after releasing the hack publically, rigorous playtesting is required, after watching dark deity, well you need to do some playtesting for spotting out bugs and other mistakes at the very least.

1 Like

Glad you find it helpful.

Yeah having a thread + using #playtesting on the discord are both good ways to get test help. I plan to cover more surrounding what to look for and how to test effectively when I have time to finish it up.

the “release” section will cover broader playtesting from the public + working through feedback.

Added some notes in “discussion” around how to use design meta chat more effectively.

1 Like

The guide is now complete! Based on some feedback, I will be adding an “illustrative example” that walks through a hacker creating something end-to-end following this process. I’m not sure when I will get around to this since it will require more visuals, but I will aim to include this at some point.

For now, please enjoy the guide and let me know if you have any questions. Similarly, I welcome feedback and encourage you to share what works for you when researching and bringing those ideas to life.

I generally believe you need to know the systems of FE really well to build a strong hack. Having strong foundational knowledge and seeing ideas executed differently, while having the language to describe these elements will help you throughout the design process.

In the words of Picasso “Learn the rules like a pro, so you can break them like an artist.”

Thanks all.

7 Likes