As a person teaching gameplay and narrative design to the young generation for over a decade, I wanted to visit a few core problems with the current changes to the gameplay with a bit of contextualization to some of my critical points. First, I want to thank the developers, artists, designers, and gameplay teams for their hard work, as the recent changes show a lot of dedication to making visible changes to the project. I understand that you are working in a very stressful environment: the project is backer-funded, the changes are constantly criticized due to the open development model, and the need to reach concrete project milestones and set business goals weighs heavily on your shoulders. You are doing everything you can to reshape the project with growing pains, technical debt, and a demanding iterative process (revisiting older mechanics, redesigning ships to gold standard, fixing bugs, developing new solutions to server demands, and critical adjustments to new technology). For the effort of your teams, and dedication shown - thank you! Now, as an academic teacher working with young developers and gameplay designers, I often find myself showing them good and bad practices. It is a common practice to show brilliant solutions, but also to point out the reasons for project failures, drastic shifts in gameplay quality etc. I have used Star Citizen as an example of a brilliant diegetic gameplay design in the past, comparing it to the effects of some cumbersome interface design decisions in Elite Dangerous. Star Citizen has - for a long time - stood out as a project investing in the mediation of being a pilot, rather than the mediation of piloting - meaning that many gameplay choices were focused on playing the role of a person within a cockpit rather than directly mediating control over the spaceship/vehicle. I saw that as an interesting diegetic choice and a good testbed for playing with different levels of immersion. Looking at Star Citizen Alpha 3.24.2 I will be using this patch as an example of bad gameplay design choices due to several reasons I will list below. To make this as informative as possible, I'll also provide some solutions that I think might improve some of the identified issues. 1. The change of the original HUD layout into a more diegetic and nested system is a beautiful but decidedly bad design choice if the players are not given the option to have the classical HUD displayed either in the cockpit or as a cast into their helmets. This boils down to two things: a) HUD was originally designed based on years of research into pilot cognitive abilities, the need to focus attention on flying and information overflow, and as a means to limit the Operator Cognitive Load, easily measured by scales such as System Usability Scale (SUS), or Task Load Index (NASA-TLX). With current changes, the situation you are creating for players is - simply put - tiresome and will generate a sense of non-optimal, or excessive overload due to the need to refocus on multiple dispersed information panels. b) Disruption of information flow during stressful procedures requiring immediate response, especially for users with cognitive impairments or attention problems. What I'm trying to say is that you introduced changes working heavily against players with attention and or / cognitive disabilities. This is a bad gameplay design because it is not optimized to lower the User Cognitive Load - every interface for years now has been developed based on the idea of easing accessibility and lowering cognitive loads due to growing cognitive problems within the populace. 2. MFD power controls which have replaced the previous power triangle system require triple the amount of keybindings where the previous system was elegant in execution and was fully controllable with just 1 hat switch. This is another problematic design choice where significant choices impacting flight maneuvering, dogfighting, and pilot focus require cumbersome operations on the controllers. Within dynamic battle environments where action requires quick hand-eye coordination, the introduction of such interface changes effectively dooms many players to loose not because of the lack of proper skills, but because the proper controls designed for the spaceships are debilitating the flow. Here you have designed your interface mechanics against the notion of Flow, showing that there seems to be a significant problem with prioritization of gameplay design choices. This is not how depth is produced in gameplay, this is how frustration with the system is introduced and how you dissuade initial players from engaging with the product on a deeper level after the initial onboarding. 3. Multi-crew design choices are introducing confusion as to the player roles. This is a very problematic shift in gameplay design in a multiplayer game environment. Some examples are the Reclaimer Claw operator, and the new Corsair copilot lower gun controls. The first case is an example of a tiresome and destructive gameplay design choice. When scraping hulls or munching ships the pilot has almost no gameplay to focus on - they park the ship, and make small changes to the position, but their main play turns into waiting for other teammates to finish their tasks. This scenario makes the pilot change seats to play as a claw operator because the claw operator gameplay boils down to pushing 1 button - there is no control over the claw, and the operator cannot participate in scraping. The Claw operator function could easily be slaved to the pilot without any loss of multi-crew gameplay. If the economy of Reclaimer gameplay already requires the two-player scraping play, at least 1 player gameplay in the salvage processing, cargo hold, and salvage hold, and at least 1 player gameplay with drones in the future, there is absolutely no reason to neuter the pilot role by taking the claw operation from them. The current design forces the players to take roles that feel artificial and forced, probably because player roles have not been fully defined at this point, and gameplay loops have not been developed around these roles. The same thing applies to the Corsair co-pilot-controlled guns. This gameplay decision is forced balancing by delegating artificial, forced, and tedious gameplay to a player in the co-pilot role. This is a bad gameplay design -again - due to a lack of meaningful control design for the co-pilot. Instead of taking Corsair's pilot power from them, incentivizing co-pilot gameplay role should be your design priority. This role seems to be the least defined role in SC at the moment and forcing players to fill that role without proper gameplay loops to make it entertaining is destructive to the game you are building. 4. Balancing against the community is the most destructive thing a game developer can do, and creating rifts between the community supporting the project is another destructive strategy. The case of Corsair seems to be a good example. The balance changes affected the community in a destructive way - instead of building a sense of cooperation, a rift between supporters and this feeling deprived of original ship features has been artificially created. Look at how bad decisions against the community have worked for games such as Helldivers 2 - there was a similar rift due to players feeling that the balancing was made purely based on Excel numbers and not on the "fun-factor". The "fun-factor" seems to be the ultimate go-to not only as a metagaming solution but also because it seems the most enjoyable solution at hand. Instead of balancing against enjoyable and working solutions, good gameplay design focuses on multiplying these. In the case of Corsair one could argue that lowering the gun sizes would be a viable solution to the problem, but another option would be to look at the ships that players do not choose and make them more in line with the "overused" Corsair. That way you balance positively, by making more ships competitive, and you don't introduce rifts in the community. At the moment the gameplay decision to balance down Corsair does not make other ships more alluring, it makes players dumbfounded as to why they are made to push 1 button for the sake of Corsair nerf... I hope you don't take this as an attack on your development. As a teacher, but also an early backer of the project, I would prefer to use Star Citizen as a positive example, and not have to analyze bad gameplay design in order to show how not to develop gameplay. Bests