Managing Relationships

General Discussions
#1

So I’m making game, and all of a sudden I want to refactor. So, I start refactoring, and these refactors are a key part of the game’s structure. Having deleted the old classes and preparing for a new Manager class that was missing before, I hit a roadblock. I have 3 (maybe four) main class types. I have Blocks, Entities, Items, and Script(s). This Manager class will be awesome, but I have to understand one thing first:

How do my types relate? Or: How do I want my types to relate?

I’m not exactly sure where to go with this. I want to design something that is flexible, but without unnecessary coding. I’m not sure how to visualize this, but I get the idea that a flowchart would be a good medium.

Anyways, how do you guys do it? Do you just jump in and program it? Or do you plan it out?

#2

That’s not refactoring. That’s deleting code and rewriting it.

[quote]How do my types relate? Or: How do I want my types to relate?
[/quote]
That’s up to you. Decide which are the lower level types and which are the less low level ones that will depend on them. How you decide that depends on which bits will change most, which bits are most generally applicable, and which bits do you expect to extend most.

[quote]Anyways, how do you guys do it? Do you just jump in and program it? Or do you plan it out?
[/quote]
Go read Martin Fowler’s ‘Refactoring’ book - what you’re doing is not refactoring, you’re throwing it out and starting again. That’s exactly the wrong thing to do and ignores all the good stuf you get when you refactor things properly. Refactoring should be a sequence of small, simple operations that move you towards a better design.

As an aside, monolithic ‘Manager’ classes are almost always bad design, and something you should refactor away from, not towards.

#3

Refactoring starts from the principle that new code is worse than old, mature code. You make the old code better by making small changes rather than making a lot of new code with new bugs.

Refactoring is not just bug fixing: you have some kind of long-term plan for how you want to improve the code (for example, remove cyclical dependencies, or break up a few bloated methods) and is always a good idea!

#4

Obligatory image

http://stevenadunn.files.wordpress.com/2012/09/code_refactoring.gif

#5

Don’t listen to Rorkien… Refactor! Refactor! Refactor!

#6

Well, first off, always plan out what you are going to do before you do it, saves headaches and bruises on the forehead of yourself and anyone who ventures into that code. The idea behind any good code is “set it and forget it,” in other words, you do it right the first time so you aren’t restructuring your packages every single edit. Refactorinig should be used to refine the code, not revamp it, so there’s a flaw.

I was debating posting a response here because it will hurt feelings with what I have to say, but, if you’re deleting completed classes then you’re doing it wrong. I refactor all the time, but I only delete classes that I create as place holders, in case I might need it only to discover it will complicate matters more, thus the classes I delete were never implemented in the first place and nothing else needs changing to accommodate it’s disappearance. I recommend you find a method of planning that helps you eliminate the need for class deletion, but nothing will eliminate the need for refactoring.

#7

Ok. Well, my code is backed up just In case I decide the old code was better. But I feel like my old way of doing things was sloppy. The new class is going to be a manager. It’s main purpose is to bind together the core parts of the game, and allow other classes to access core information easily. For example, the manager will allow class to get the player entity, or get the block at a certain position.

Also, I like to simplify everything. I try to have the least amount of classes and and the greatest amount of flexibility.

#8

Offtopic since you mentioned you had to back up your code:

Look into Mercurial or Git. They are versioning systems that help you track each change you make to your code.

This is a good explanation of how Mercurial works.

#9

Hehe, kittens.

#10

They are why I waste SO MUCH TIME on Reddit :frowning:

#11

Thats what I meant by I backed up my code. Sorry for not being clear.

#12

Ah ok that’s good! :slight_smile:

#13

… and another aspiring indie developer lost to design patterns and the art of code perfection. :emo:

What to do instead?
[x] get it to work
[x] get it fast enough
[x] polish it
[x] bring it to market

Nobody in the game scene cares about code quality, they care about the product.

If that takes a super big Manager class with a dozen static methods, by all means do it, because it’s easy to write, and manage.

In the next project, try to not make the same mistakes - that’s all there is to improving your code.

#14

Right-Click file on Eclipse > Compare With > Local History :yawn:

Not as spicy, detailed and clear as Git, but it has saved my skin (with a single click) a couple times

#15

Yeah, that’s why I don’t like/use it :stuck_out_tongue: