Refactoring

I am working on a game engine right now, and I want to redo the tile system so that every tile is an instance of a class, and each tile object maintains its own individual properties, like the image(s) that get displayed (there can be multiple layers), whether it's a blocking or non-blocking tile (for collision detection), any events (such as enemy encounters, NPCs, or moving the player to another map), etc. Then all I have to do is create a 2d array of these objects for the map.

But right now, my game has similar functionality (from the end user's standpoint), but the code base is a bunch of spaghetti. It's not modularized, not using the object stuff I was talking about, and the collision detection is a big if statement with a bunch of ORs to check for individual tiles instead of a boolean property within a tile object (like tileObj.isBlocking or something).

So should I start from the ground up, since I would have to redo so many things, or should I just refactor what I currently have? Or should I just try to add additional functionality on top of the spaghetti code?

Re-write it in Idris.

>>1
Another victim of OOP brainwashing.
You code performance should centered on
1. Fast functions: simple, fast code
2. Operating on tiny datasets representing only the relevant parts: e.g. collision maps for collisions, graphics should be separated from logic/physics.
3. Without dynamically allocating or freeing memory. Use stack arrays and memory pools.

OP, you need to reconsider if you actually need this refactoring. each tile being an object with those properties is a good idea, but you should do it only if maintaining and extending your're are engine in its current state is tedious/difficult. also, sometimes an if statement is all you need - there's no need to go with all the boilerplate and ceremony of a myriad of classes if the same thing could be achieved with a small case switch. so, only refactor if it will make your're are life easier in the long run.

if you decide that your're are project needs refactoring, gradually changing the existing code is usually better than rewriting. if he code is extremely messy, fairly short or trivial, rewriting might be a better solution but otherwise, don't do that.

here are some refactoring tips:
- each refactoring needs to be an individual commit in version control - it can break functionality if done badly so you'll need to be able to go back to a known working state
- plan ahead - I know that refactoring might be popular with 'extreme' anuses who hate designing anything upfront, but that's silly; you should know how you want to modularize the project before you set out to do it - and when designing, think of potential caveats, edge cases etc.
- small steps - don't be afraid to just cut and paste a block of code to a separate function/class/method/file at first and work from there
- don't fall for the cargo cult - the enterprise java way of billions of classes for everything is dumb; the pure functional way isn't well-suited for stateful shit like vidya so while it's doable, you'll need to anally deform your're are brain to do it; even the typical vidya 'entity system' might not actually be what you need; consider your're are options, think of upsides and downsides and pick the right choice
- use the fucking tooling - it might be cool to shit on bloated IDEs on textboards, but refactoring is one of the places where they beat vim and even emacs; JetBrains shit makes redesigns painless

http://old.reddit.com/r/ControlProblem

-Write some fucking tests to prove the features what you think is the part that works ok and should be kept
-Refactor
-Run tests
-Fail
-Refactor

>>3
It's not brainwashing. One of my collision detection checks happens when you press a button to move the character and it's kind of like this (I don't wanna be doxxed so I'm not gonna post the exact source):
if (tile.type = "blockingType1" || tile.type = "blockingType2" || tile.type = "blockingType3" || tile.type = "blockingType4")
instead of something like if (tileObj.isBlocking)
and there's a bunch of other bullshit too, like graphics aren't tied to the collision, when in reality, if you want to place a rock on the map, it should contain the graphics, the collision, the position, etc all in a single object instead of strewn across multiple primitive data type 2d arrays and images that have no relation to each other. It technically works, but not in a good way. I currently have graphics, collision detection, movement, and menus. But I want to make it better before making more things, like the combat system.

Right now, you have to edit a lot of shit in order to add just one more kind of tile or event that you can put on the map, but I want to make it easy to have n kinds of unique tiles without having n or statements when checking for collision, and there are a lot of other issues with scalability/extensibility that don't matter if you don't have much content, but matter a lot if you want to add more types of maps instead of just super basic floor and walls

There's also a memory leak in the level editor (if you use it for an extended period of time and replace tiles with other tiles multiple times) because I made it so it just adds new stuff at a set position but because I don't have proper classes I don't have good destructors and the memory management is overly complicated and doesn't properly delete everything at the moment.

Go watch something by Mike Acton.

>>8
Mike Hunt

>>7
Not all things that are beautiful on the outside are good for performance. Simple, intuitive solutions often don't scale past X objects at once or incur overhead per each objects that grows enough to lower framerate.

>>10
first of all, check my dubs
second of all, I don't think such heavy optimization is required for a 2D game (which seems to be what OP wants). it's not AAAnus, it's some dude making vidya in his's is spare time
third of all, I don't really see how much of a tradeoff is replacing a list of ifs with a boolean field in a struct. if such downsides exist, I'd say redesigining from AoS to SoA will fix it anyway while still being more readable

>>7
For that specific example, if blocking type values are assigned sequentially the entire set of tests can be optimized to a simple range check. For maximum cleverness, define type values using bit fields and test traits by testing bits. Dumb stuff like that goes a long way; if you have lots of tiles you don't want to burn an extra 1-4 bytes for every trait.