The different types of approaches towards a problem and adding new functionality.

Because having worked with python a bit now and coming across all sorts of problems and solutions I just think we should go over these two questions.

1). What are the different types of methods for attacking a problem/bug/glitch in a game to fix it?

2). What are the different types of approaches for adding new functionality to a game?

Here are my answers for both of them.

1). The lazy hack
The lazy hack is a simplistic approach to creating a solution, usually it’s something simple like var=var2 * -1, it can be a simple addition to a line of code or another single line of code to shoehorn a solution that works. The big risk is that if you pile up too many lazy hacks where they’re everywhere and multiple hacks are piled onto the same line, problems down the road could be tricky and code could become very messy.

2). The normal hack
The normal hack is usually a hacky piece of code that can comprise of a number of lines or even a whole section of your script, it can be used to quick solve problems or quick give functionality to the game, but the risks are the same as in type 1.

3). Reshuffle, and regroup.
This type of approach is usually done to help keep code neat by helping to minimize duplicated code by use of things like nested if statements, this often comprises of code being deleted and copied into other places, pretty much anywhere that reduces duplicated code, risk of messing up your code is smaller, and could even make your code more tidy, depending on whether or not it bunches unrelated game elements into one nested group.

4). Simplify and add
This type is usually used to allow less code to do the same work and have less redundant code, it also is used to perhaps make it easier to add functionality in a way that the code is less convoluted and is able to be expanded more easily. This, like the above, can also be used to remove lazy and larger hacks and make a nicer, more expandable script that makes adding things to your game much easier.

5). Create a slottable system
This approach involves creating code from the beginning to give you the ability to slot in multiple features without resorting to too much hacking, changing, or rewriting, like an object respawn system, create code that allows you to easily slot in new objects as an addition to the system is paramount if you’re going to have tons of objects spawning in the game. Sometimes this requires large scale changes to the game logic if the game is already in an advanced state, but doing types 3 and 4 could help with that.

Now what approach types would you add or what would you change from what I wrote?

good thread.

Also, the more you try to figure out your own scripts instead of just asking the forum or something the more you learn.

If the script is complicated enough, I will use the “slottable” system (define functions).

Otherwise, I just try to be really OCD about keeping scripts neat, simple, and hack-free. Always try to aim for slottable though – I had a situation where I had to add an additional way to activate a feature in ~20min, and since my code wasn’t designed for that, I had to do a major hack. Luckily, it worked, and I never had to go back and fix it, since (it worked) and that project is closed now.

The short version: Modular. No hacks.

Sorry, I do not really know what you want to tell with this thread. What you describe is part of a “normal” development process. In this case the phases “implementation” and “bug fixing”. (see

There are different goals software developers try to achive. The main goal is always to meet the requirements! (sarcastic comment: This depends a lot on how the requirements are defined.)

secondary goals:

  • efficency (execution speed, memory ussage)
  • development time
  • readability of the sources (easy or really difficult)
  • easy to extend etc.

Not all of the goals are required, not all of them can be achieved (e.g. efficency vs. readability).
Also this can be a goal:

  • do not implement what is not required!

If you know this, you can add this secondary goals to the requirements.

1)2) is a Bugfix (see It does not matter how much sources you change to fix a problem, it is a change to the functionality (as the previous sources do not work as required).
[yes, you are right if there is not enough time for the normal bug fixing process, there could be a “lazy hack” or “quick and dirty” or “temporary” solution, etc.]

  1. is refactoring. That means you change the structure of the sources without changing it’s function. When you run the tests with the old sources, you get the same result as with the new sources.

  2. is half refactoring and half software changing. So if you do that and it does not work, how can you tell the problem is refactoring or the new processing? Better to split that up. By the way software changes can be seen as Bugfix (as it changes the function of the software, the bug is the previous requirement). So they fit into 1/2)

  3. is just how you design your project. That is the reason why usually experienced software architects write the design based on the requirements. They know the big obstacles and how to prevent them. If you do not have that experience you have to learn, fix and refactor.

My recommendation:

  • define your requirements and
  • verify that your requirements are met.

from a IT developer