In case you feel less like reading.

Mass Effect Andromeda’s buggy Graphics…


No Man’s Sky’s Incomplete and sparse game-play…


Bethesda’s Bug-ridden releases in general…


Ride to Hell Retribution 1%’s… Everything.


If you stay in forums and comment sections long enough, you’ll notice a fair amount of people making fervent complaints about the AAA releases that seem to be substandard for a myriad of reasons.

One thing I’ve noticed is how lay gamers tend to complain as though game design were as easy as filing a tax return.

Case in point: 

I have been following the development of Yandere Simulator for a few years now, as well as the growing displeasure of the game’s slow buggy and feature-creeping progression. I’ve also been following the game’s coverage whenever I can. To describe the finalised game, once it’s complete, would be:

A small range 3D sandbox game with stealth based puzzle play, Role-playing Elements, Quick Time Events, inventory management and dialogue puzzles.

Now it’s time to think of the game as its base constituents since these factors make the game orders of magnitude more difficult to make as a team, let alone as a solo developer. 

Inventory management and Dialogue puzzles are simple to implement, harder to design successfully and in an intriguing manner. 

Role Playing elements in games usually entail managing player and NPC statistics. Not too much of a problem, if you plan ahead well enough.

Quick Time Events take time to stage, pace and effectively program such features without making it feel boring and unnecessary.  

Stealth Based play is harder in 3D than in 2D.  In stealth games, the main conceit is to avoid detection and execute the primary objective. Be it, collecting or hiding an item, following or avoiding an NPC, or killing an NPC in numerous varied ways.  

In 2D, like Mark of the Ninja, or Trilby: The art of Theft, avoidance is usually based in a single plane of detection (with the exclusion of isometric or top down games like the early Metal Gear games).


Once you start dealing with games like the Thief series, the Metal Gear Solid series and the Hitman series, movement and NPC AI prove to be more difficult to implement.


Now putting these elements in a sandbox, a situation where the game level is dynamically loaded to be a seamless consistent overall world map, think about all these constituent parts, how to effectively put them together and then design, implement and test all these features into a consistent gaming experience. 

Seems “easy” doesn’t it?  

For a solo developer to engage with all these functions in a game, as their second project, is dangerous. YandereDev has so much on his plate and hasn’t trimmed back the functionality. That is bound to cause delays, and a lot of hair pulling, due to the weeks and weeks of solo bug testing and debugging.

I have personally started, binned and restarted projects out of my own lack of intelligence and experience. Most of the time, it is due to one major issue: Scope and boundaries. There are other issues: poorly placed deadlines, publisher intrusions and unexpected events. I see this as one problem that affects gaming more than it does other software.

Scope is what you’re allowed to put into your software. 

Boundaries are the limit to the features you will add to your software. 

These two terms are often used interchangeably due to their similar definitions. This is a problem with Games. This is what makes bad games. A mixture of biting off more than you can chew (adding too much to your scope), or pulling a Mr Creosote and not stopping yourself when you are already full (not having strict boundaries). It is a major issue of planning without keeping in mind what core features your game can and can’t survive with.

Mass Effect Andromeda’s buggy Graphics were caused by having one initial set of Scope (including engine being used) and having to make late state changes because they did not leave enough room for potential issues.

No Man’s Sky’s Incomplete and sparse game-play was due to too much scope and no boundaries (at least that’s the perception the general public had due to the advertising). 

Bethesda’s Bug-ridden releases (in general) are caused by trying to work on the complete system at once instead of core features first then ancillary features that can be dropped; Not having a specific basic scope in a “please all; please none” attitude; Creating a game engine with this mentality without specifying a basic set of criteria that the game, or engine should accomplish.

Ride to Hell Retribution 1%… That was just bad decision making all round.

Published by James Agbotta

Software Engineer and Game Designer (Watch this space)

Leave a comment