Just One More Run: The Pitfalls and Strengths of Nostalgia in Contemporary Video Games
Advisor: Mr. Koppel
In recent years, the number of video game remakes being produced by video game studios has seen a notable rise. In the past decade, we’ve seen titles of all genres get remakes, such as Demon’s Souls (2009, 2020), Final Fantasy VII Remake (1997, 2020), Yakuza Kiwami 2 (2006, 2019), and many more. These remake titles serve dual purposes: to appease the old fans with a classic made new, and to modernize the system to introduce new players to the series. However, how do video game studios know how to balance these two goals? A company’s goal is first and foremost to make a profit, but the introduction of two separate, equally valid audiences introduces complications in reception and decision-making. My project, “Just One More Run: The Pitfalls and Strengths of Nostalgia in Contemporary Video Games”, seeks to address the complications in decision-making in the remaking of video games, diving into the psyche and trends of game studios limited by demographic, budgetary, and timeframe limitations. This project asks: how do game studios balance nostalgia and modernization when remaking classic video games? Using qualitative and quantitative data points taken across communities and official sources, this project hopes to establish the common traits of game remakes that produce a product both commercially successful and well-received by audiences by specifically studying the cases of Persona 3, Yakuza 3, and Metal Gear Solid 3. Furthermore, the results of my research will culminate in the production of one to two short 10-minute game demonstrations, one compatible with Game Boy constraints relevant to its time, and the other a subsequent remake product that synthesizes the research results to decide what is added or altered. In the analysis of the unifying traits that make up a successful video game remake, this project aims to allow greater understanding of the game design process and act as a bridge between developer and player priorities.
Project Blog
Week 0: Introduction
Hello everyone, my name is Archie Ho, and for my senior project, I will be diving into the world of game design and development. Specifically, my project is the result of the recent trends in modern video game markets to release video game remake titles, and how game studios decide what to cut, what to change, and the restraints surrounding their products. Based on my research, I hope to be able to cross-reference three game titles (Persona 3 Portable, Yakuza 3 Remastered, and Metal Gear Solid 3) with their modern remakes (Persona 3 Reload, Yakuza 3 Kiwami, and Metal Gear Solid Delta) in order to establish benchmarks in what defines a game remake that is both commercially viable and well-received by audiences.
As one could probably infer, I pursued this project for my interest in video games and the processes behind their creation. As for my credentials, I am relatively well-versed in digital media, having taken adjacent courses for three years in my time in middle school, two years of digital media camp experience, and having coded small game projects for my AP Computer Science courses. However, I've been interested in diving deeper into this interest as an avid enjoyer of games myself, with a library of at least 150 titles across platforms. Throughout this project, I will be distributing polls and gathering fiscal data across the named communities, of which I am already an established member. For my final product, I aim to create one to two small video game demonstrations: one made on GB Studio to be compatible with Game Boy systems, and one "remake" version made on the more modern Godot engine. For more detailed information, you can check out the details in my proposal. Stay tuned for updates!
Week 1: Straight Into the Fray
Welcome back everyone! While I've been waiting for responses for any potential on-site placements (fingers-crossed!), I've jumped into starting the quantitative research portion of my project. And right off the bat, one of the issues I was expecting to happen came through immediately: since these are private companies, and because the titles I am looking at are pre-2010 and Japanese, the custom to publish fiscal data regarding a specific game isn't really available online at the moment. So, I opted to leave this issue for next week, when I can decide the best way to approach the budget. Instead, I gathered other data, like initial release windows, initial sales metrics, gross revenue, and developer statements.
Out of these, gross revenue is the most interesting statistic, as it, like the budget, is not publically released data, though it is easier to surmise. This was a matter of estimating lifetime sales data using estimates across various platforms (like SteamDB or other aggregate sources) and applying a multiplier based on the various versions of the game available at different price points. Reading through a new article I found (https://generalistprogrammer.com/tutorials/game-development-cost-analysis-complete-budget-guide-2025) by the GeneralistProgrammer, as well as Richard Harris's "Game Development Process: Mastering the Art of Game Creation", I was able to learn more about the work and effort behind the creation of a game title. I also managed to read a little bit of the paper (https://doi.org/10.1016/j.teler.2023.100100) on the Video Game Industry as a business venture, which gave me some insight on the economic prospects of the creation (and by extension, recreation) of a video game.
And, my efforts did come to fruition: I did find out some fiscal data with effort and a little bit of digging. The most interesting case I've encountered is actually that of Persona 3 Reload's lifetime sales data. For context, companies typically don't publish their sales statistics (it would be bad for business), but these companies (specifically Japanese companies) do occasionally hold public press conferences and board meetings to discuss investment prospects to shareholders, often releasing the slideshow online later. What was so interesting about the one I looked at (SEGA Sammy Management Meeting 2025) is that the producers of this slideshow actually made a formatting blunder that became useful for this project. In an archived version of the document (which you can view here [page 25]), it's actually possible to highlight the grey box and copy and paste the sales data for SEGA's data for certain titles since the fiscal year of 2023. This document inadvertently reveals that Persona 3 Reload has a staggering 2.07 million copies sold in its lifetime.
Anyways, I have now compiled the necessary data aside from the estimated budgets for each game, which I will continue to work on into Week 2. Luckily, I have been reaching out to several individuals and organizations regarding an on-site placement, and I will be updating status as soon as possible! I've also begun to draft up some polls to distribute for the qualitative side of my project in preparation for next week.
Thanks for keeping up, and I'll see you again next week!
Week 2: Moving Along
Hello, and welcome back to Week 2 of my Senior Project!
There isn't anything new this week, so this post is probably going to be a short one. For starters, I've made some more headway in my quantitative data-gathering. Specifically, this week consisted of creating an tweaking formulas to accurately estimate the financial portion of my project. Taking into account regional pricing, various editions, and discount sales, I can reasonably surmise a range of gross revenue a game has made based on the most recent sales data. One neat thing about looking at more modern games is that they are more likely to release milestone announcements that I can then use to ground my estimates. For example, the official Metal Gear account recently posted on social media that Metal Gear Solid Delta: Snake Eater has officially sold 2 Million units, allowing me to construct a lower bound for my estimations. Furthermore, I've also been using aggregate sources like MobyGames as a credible compiler of some of the information I need, which includes the amount of people credited on working on the game.
In other news, I have contact with VFX artist David Hulin of Free Range VFX, and we've been discussing parallels between the Video Game Industry and that of film and other digital media.
With most of my quantitative data-gathering complete, I will be moving on to fully working on the qualitative portion (that is, the polling) in Week 3. As I've mentioned before, I'm already an established member of these communities (at least on Discord), and so I have preexisting insight on the controversy, general consensus, and overall reputation of each game I'm covering.
Week 3: Qualitative Polls Start
Welcome to Week 3 of my blog!
Another short entry this week! As I wrapped up most of the quantitative gathering from weeks 1 and 2, I started work on creating google forms questionaires for the communities I intend to poll. With this, I have also started looking into Bernevega’s paper on Exploring the Assetization of the Triple-A Game in order to better understand the business portion of the video game industry. While this paper focuses more on the GaaS (game as a service) formula of video games where the game relies on live service updates and events for profit and design, the monetization and economic thought-processes are still relevant in the creation (or recreation) of a traditional offline video game as well. It discusses the evolution of video games as a form of entertainment to a commercialized form of profit, rebalancing the scales between financial stability and audience expectation. To connect this to my project, this paper can be applied to the core struggle many studios face in the process of remaking a game: balancing appeasing veteran fans or catering to newcomers. This confirms and expands on my suspicions since before starting this project: that the shifting priorities to make a video game profitable impacts the aspect that makes a video game "memorable". To elaborate, many modern triple-A games follow proven methods of success seen in other titles such as the aforementioned GaaS model (i.e, Fortnite, Apex Legends, Call of Duty), the hero-shooter model (i.e, Valorant, Marvel Rivals, Overwatch), among others. With "safe" models like these, the recreation of older titles when these models did not exist and when games were more experimental, the profitability and confidence that investors want become less certain, thus leading to this contention between faithfulness and modernization.
While that's in process, in week 4, I plan to start the distribution of my questionaires and (finally) learning the basics of GB Studio to start work on my first planned product! To do this, I will be employing YouTube tutorials as well as playing around with the program and its documentation. To make things easier, I already have a set of features and gameplay planned for this project, with benchmarks as I progress the development of this product. This will be quite a demanding task, so I expect to run into a few bumps along the way, but with my experience with getting into new software, it is doable.
In other news, my search for a digital placement is still in progress - I am currently awaiting confirmation from Rochester's Strong Musuem of Play. I will keep you all updated, and hopefully GB Studio proves cooperative!
Week 4: Starting GB Studio
Welcome to week 4 of my blog! This week I started the distribution of the Google Forms and also secured a placement (finally) with a STEM faculty at Joseph B. Cavallaro, who specializes in teaching STEM topics (most relevantly, Video Game creation) to intermediate school students. Big thanks to Ms. Christine Zambri of IS281 for this opportunity!
As some may recall, I also started learning the basics of GB Studio and its documentation in hopes of creating a draft for my first deliverable product. Now, unlike more robust game creation studios, GB Studio is a visual scripting studio, meaning that it's much easier to create something than Godot or Unity - simply put, many programming methods are already implemented, it's just a matter of using logic and the interface to create something with it. Using tutorials from YouTuber PixelPete, I was able to get some work done on my tests! I used publicly available assets from Itch.io to create these scenes, and I expect to start working on the actual mechanics of my ideas starting next week.
Itch.io credits:
GB Studio Character pack by The Pixel Nook
Week 5: Progress
Hello all, and welcome to Week 5 of my Senior Project!
As you may recall, I started posting my questionnaires to communities at the end of last week. Right now, I have 52 responses across the communities, and am going to keep distrubuting across platforms!
Things are going decently with development, as I am currently in the process of figuring out how to create the core mechanics of my game, but because GB Studio is a visual creation studio, it doesn't have many customizable features (apparently it doesn't have elseif statements and you can't even use more than one boolean per line!), but I'm working through it with nested code. It's good that I had an idea of the core gameplay before I went in, otherwise I would be lost in what to do. As for what exactly that is, that would be spoiling the surprise! So expect to find out later down the line.
I've also noticed that people are asking why I chose GB Studio over Godot or Unity. The answer is: I'm not (at least I hope not)! My project is on the concept of remakes, so naturally, that's what I'm doing: making a basic 10 minute game demo in GB Studio, and remaking it in a more modern engine like Godot. This is of course a very big task, and even with prior experience will not be easy, which is why my grading policy for the remake product is weighed more as a proof-of-concept than an actual product just to see the synthesis of my research and programming.
Anyways, that's all for this week!
Week 6: Hitting a Wall and Building a Ladder
Hello all, and welcome to Week 6 of my blog!
This week, as I said last week, was filled with me trying to implement the combat logic for my first product in GB Studio. Unfortunately, given the visual creation studio nature of GB Studio, more specific features are kind of difficult to add. Thus, I've run into a bit of a snag in trying to get these mechanics to work, even if I have a clear vision in mind of what I want to do. But fear not! I have taken to consulting with the official GB Studio Discord server for advice on how to implement my goals, and they're pointing me in the right direction with this project. Hopefully, I can see meaningful progress next week.
In other news, I'm going to start distributing my polls on other platforms as well, because while 55 responses are plenty, I want to have a larger sample size to more accurately reflect the thoughts of the community, so I'm aiming for maybe 45 more to get a nice round 100 responses. To do this, I'm going to post in more general gaming communities (as I've only posted in the specific ones for now) to get thoughts on remakes other than the three I've outlined. Other than that, this week was just playing with the studio and figuring out the constraints. With that said, that's all for this post! See you next week!
Weeks 7-8: Figuring it out
Hello everyone! Welcome to combined weeks 7 and 8 of my blog! Last week I didn't post due to preparations for AP exams as well as attending a graduation ceremony, but now I'm back in the fray with progress to report! I finally got the sequence tracking down after a few hours of racking my brain on how to handle my combat system with GB Studio's constraints, and I've managed to come to a compromise I'm happy with. So, after redesigning the map a bit and implementing visual cues, I have a small demo of my system! This was what was taking up most of the last few weeks, so now all I need to do is work out the kinks and mechanics, and hopefully we'll see the progress as we go.
Video: https://www.datocms-assets.com/221631/1790627917-2026-05-20-14-09-21.mp4
To get to this point, I've run into all sorts of problems - most of them logic and syntax based within the visual editor. To understand one of the errors I've corrected, I need to explain my game plan. This game is going to be a turn-based structure in which the player, instead of the standard context menu, has to memorize input sequences to execute certain commands. The error I kept running into was that the controlled character would not move given a command. It turns out, two of the moves I had coded in were conflicting with one another, resulting in a sort of stalemate restricting the player's movement, because one move results from all 5 slots being identical, and the other occurs when you alternate inputs. (Ex: [AAAAA] results in a slash move, [ABABA] results in a guard move). The issue here was that the guard move was also reading the input from the slash move, because the guard move only checks that inputs alternate position-by-position, it doesn't verify that A and B are actually different inputs. In other words, as far as the guard move is concerned, a sequence of all identical inputs reads the same as an alternating sequence. I noticed this when bringing this issue up in a brief meeting with my advisor when we combed through each actor and their associated event sequences while also keeping an eye on the built-in debugger of GB Studio. The video depicted above is what resulted after I fixed this issue, though some more obvious errors are still in the process of being corrected (i.e, the HP bar having weird values and the occasional lag spikes likely caused by the onUpdate properties of the scripts). Another issue I need to keep track of is the Actor (entity) limit in any given scene. GB Studio is surprisingly restrictive with its capabilities, only allowing around 10 actors to be rendered on screen at a time given the actual Game Boy's hardware. If you look at the video above, you might notice some text or the enemy disappearing at times. This is because the text itself, as well as the buttons and interactables in the scene, are all actors - the same kind that the player character and enemies are. So, I need to carefully keep track of what I want on screen and dealing with keeping all associated scripts running smoothly.
Now for news on the second half of my project - its looking less like it would be an actual remake and more like a concept pitch given the time constraints (which is thankfully accounted for in the grading policy!) Games made within GB Studio lend themselves to be improved by more modern hardware, away from limits like the 20 actor restriction (10 can be rendered, but 20 can be in a scene) or the color scheme. The quadcolor scheme is also what gives the Game Boy much of its charm, which results in custom assets being published specifically for use in GB Studio. Thus, it becomes harder to find publicly available analogs to use in a remade version of the same game. This is reminiscent of real remake practices also- in a remake much of the assets are made from scratch, referencing the older and often less descriptive components of the original. While not a direct comparison I can make while using exclusively public resources, it stands to reason that large companies would try to cut costs and save time in removing or shortening content, even to the dismay of fans.
That's pretty much all I've done for these two weeks, but hopefully I can report more progress next post!
Week 9: Nearing the End
Hello, and welcome to week 9 of my blog! This week was composed mostly of bug fixes and refining the mechanics of the project. This post will mostly address specific issues I've faced, similar to last week. Just for documentation and for the sake of content, I'll be covering some of the issues here!
Move List - So I've finally gotten the actions for the turn-based system set up and working properly, though GB Studio's visual scripting format did occasionally make errors a bit difficult to pinpoint. For example, when I was adapting the fireball move to my input system, I had mistakenly left an event in the move-detection segment that would reset the intended action for all moves except for the basic attack. After combing through the debugger and comparing the detection logic, I eventually found that I kept setting the CurrentAction variable to an unassigned number, causing the move not to be registered in the turn.
UI Fixes- I've also managed to pinpoint the mistake made when adapting the UI. In my previous post, I mentioned an issue with the HP counter when the enemy attacks the avatar. To understand what went wrong here, we need to understand how the UI actually functions. As I also explained in the last post, the UI text elements are actually actors - in the same way that the enemy and player are actors, all taking up actor slots. More precisely, each digit is an actor with sprite states ranging from 0-9, which are combined with some mathematical operations in order to display the tens and ones place of any given value (Enemy HP, Player HP, Player Energy/MP, respectively, from left to right in my game's context). This system was taken from a publicly available turn-based system made by BadDesignBryan & Kalanakila on Itch.io. My error was simple - I accidentally only copied the tens place update event when the enemy attacked instead of pasting both update events for tens and one place of player HP. This was an easy fix, but it did take me a bit to figure out, as the debugger didn't flag anything.
With all that said and done, I am now looking at a final push to refine my product. With the presentation date soon approaching, I need to work on double-checking my data as well as creating a basic progression and tutorial for my game.
Week 10: Approaching the Final Curtain, and a Push to the End
Hello, and welcome to what seems to be the penultimate blog post for my project! As I've mentioned in the previous posts, all that remains for me is to finalize the demo and create the concepts for the remake, and then tying it all together in the final presentation. This blog post is going to be a similar layout to week 9, listing out the features I've added and my discoveries throughout.
Optimization - I've mentioned that the frame rate was low in the initial video demonstration of my gameplay, and that was due to the fact that I essentially had my gameplay running constantly on an On Update script of a single actor. This is incredibly inefficient, as it was basically checking move sequences for every single tick (basically the system's smallest unit of time), which, as you could imagine, slows down processes considerably with the five different moves I've programmed and their effects. This was fixed through some trial-and-error moving event blocks to the On Interact tab of the actor instead, where the check would only occur once when the player initiates a certain action. This fix led to huge improvements in performance and made the game overall more enjoyable, instead of getting choppy frames and misaligned inputs. This also means that I can add more to the gameplay loop without worrying about performance drops, meaning it made way for the next feature on the list.
Gameplay - With the smoothing of performance, gameplay became much more enjoyable. On top of finalizing all the moves and fixing associated issues, I also added things absent in my last video - music and sound effects courtesy of Yogi (and those affiliated) and Coffee 'Valen' Bat, respectively, on Itch.io. Furthermore, I added two more enemies to the existing slime seen in the first video: one slightly stronger enemy and one boss enemy, and I also made some adjustments to the balancing of stats for both the player and the enemy to make the game more enjoyable.
Video: https://www.datocms-assets.com/221631/1790627921-demo-2.mp4
As you can see, I've applied the codename "Project Legacy 0" to the project, and as I've mentioned in the description, the concept for the remake is "Project Legacy R" (R for remake!). Now all that remains here is to create the tutorials and the starting scenes where the game should take place (only around 2-3, not much to do there besides making the map and placing enemies), as all known bugs are done and dusted.
For week 11, I'm ramping up my work even more, as I have much to do from creating the presentation to actually making this game playable! See you then!
Week 12: Conclusion: The Curtain Closes
Hello, and welcome to the last post of this blog! Within the last few weeks, I've managed to deliver my final product(s) within the last two weeks and can happily say I can put this behind me! Most excitingly, I've uploaded my game demo to Itch.io, meaning that the entire product is completely playable and actually probably preferably played on any mobile device! Project Legacy 0 (its mechanics, at least) is actually a game concept that has been bouncing around in my brain even before I started senior year, so I'm really glad I got the opportunity to realize it in a productive and academic manner. I've had tons of fun working on this project, especially since the topic is one that I personally engage in every day (and, just so we're clear, I'm still buying Persona 4 Revival and the God of War Trilogy remake). With that said, here is the link to my final presentation deck. I've also decided to include the spreadsheets I used to actually gather this data in case anyone wants to see my work in the future.
All in all, I'm happy to have been given the chance to work on this project, and it's given me valuable experience to carry on to any future endeavors on this topic. Big thanks to Mr. Koppel for advising and encouraging my quantitative search, to Ms. Zambri for advising me through my product's design, and to Basis, for giving me the channel to work on this project (because I would definitely not have if left alone). And thank you, the viewer, for taking an interest in my project!
Logging off,
Archie H.