Objects / Code in Objects / Object Placement

[RealsLife]

Hello, I was making my game and now it is starting to become bigger and I was wondering...
(Because every youtube tutorial is just a video about writing code and dropping an object in the room and done.)

1.What is the best, less code in multiple Objects or a lot of code in 1Object.

2.How do people keep track of Objects, do I need to place like 10invisible Objects in every map?

3.I've a resolution object placed in my first roomwhere I can press a number and the resolution changes but when I go to another room the resolution resets to the value of the viewport of the new room.

 

[Nocturne]

1) That depends on YOU more than anything else. I used to use objects for evereything, then as I got better I started to use less and less, until I had huge monster "control" objects that did everything. However now I use a mix of both... ie: one or two controllers for things like inventory and HUD, and then objects for everything else. Basically, there is no right/wrong way to do it...

2) Again, whatever feels right for you. Most rooms in my games have one or two controllers (HUD and special effects controller for surfaces, usually) and then the "visible" game instances...

3) Make sure to set the view, view PORT and window size. The window only needs set once, but every room will need it's view and view port set.

 

[RealsLife]

1) That depends on YOU more than anything else. I used to use objects for evereything, then as I got better I started to use less and less, until I had huge monster "control" objects that did everything. However now I use a mix of both... ie: one or two controllers for things like inventory and HUD, and then objects for everything else. Basically, there is no right/wrong way to do it...

2) Again, whatever feels right for you. Most rooms in my games have one or two controllers (HUD and special effects controller for surfaces, usually) and then the "visible" game instances...

3) Make sure to set the view, view PORT and window size. The window only needs set once, but every room will need it's view and view port set.

Alright for question 2) Is it possible to make the control objects in the first map and to make it follow trough the whole game? For 3) I've actually a script that changes the whole screen resolution you know like those that you have in the most popular games the script is pixel perfect and like if you have you screen resolution chosen it is just weird if jumps back the next room so how can I "save" the settings that it doesn't jumps back to the next rooms "room settings viewport and view" it's like the game forgets about the code i've just written and changed to.

 

[elementbound]

Mark your control objects as persistent.

 

[RealsLife]

Mark your control objects as persistent.

Oh really just that ? I Know it can be used for saving your character stats and settings but yea actually i'm just stupid thank you guys °-°!

 

[Nocturne]

3) I've actually a script that changes the whole screen resolution you know like those that you have in the most popular games the script is pixel perfect and like if you have you screen resolution chosen it is just weird if jumps back the next room so how can I "save" the settings that it doesn't jumps back to the next rooms "room settings viewport and view" it's like the game forgets about the code i've just written and changed to.

See the summary in particular: http://www.yoyogames.com/blog/66

 

[TehCupcakes]

1.What is the best, less code in multiple Objects or a lot of code in 1Object.

The other posters have already given you some great answers, so I'll just add on to this one.

Consider the single-responsibility principle. Basically, if your object is getting so big that it's controlling multiple unrelated tasks, there's a good chance it would be better to break it down into smaller objects. Where you draw the line is kind of a matter of preference, since some small games only require a few lines for an individual "feature", so it's not that big of a deal in these kind of games if you have a master controller that does a few different things. Just realize that as you scale your game larger, you will likely need to break things down into smaller objects in order to remain organized and efficient.

Your usage of scripts can also have an impact on this. Using scripts to separate concerns can reduce the clutter in your objects, so there is less of a need to break them down. Also, re-use scripts as much as possible, and write scripts for bits of logic that are repeated multiple times throughout your game.

On a related note, practicing good parenting will go a loooong way in keeping things clean and organized. It may look like having more objects clutters your project, but when you start adding variables like "character_type", this can result in a lot of if conditions or switches in order to ensure that each character object is behaving appropriately based on its type. Having a parent character object with multiple children allows you to separate the code for each type... And it's a lot easier to remember to add an object when you add a new character type than it is to update all your if conditions.

 

[Yal]

State machines and parents make for some really easy-to-work-with systems for enemies. My particular favorite method is using a script state since it's the most flexible... I call it 'infinite state machine' even though the term is a misnomer Here's an example of how I do it:


I'm also with the others about the single responsibility principle. Keeping your code separated between different objects makes it a lot easier to keep track off in the long run.
Also, I generally don't create all the invisible control objects in every room manually, I have the player object create them in its room start/create event... it's a lot easier to forget one of a bunch of invisible controller objects than it is to forgot the player object.

 

[elementbound]

Also, I generally don't create all the invisible control objects in every room manually, I have the player object create them in its room start/create event... it's a lot easier to forget one of a bunch of invisible controller objects than it is to forgot the player object.

I'm not sure about this last part tho, sounds a bit like code smell. An alternative is to create your control instances in the room's startup code. This way, you can always just copy it, or even put it into a script and call that in the room's code.

Other than that, a huge +1 for the previous two posts, really informative!

 

[Yal]

I'd much rather go with a script to reduce code DRYness over having explicit creation statements in every single room - in the off case that you need to add a new controller object as part of the standard lineup, it would be a pain to edit all of the room creation code separatedly. (And same thing if you need to do some other sort of revision - I've stopped using the audio functions directly and instead use my own bgm and sfx scripts due to having issues with having to refactor code from the old audio system to the new before that I don't want to have to repeat, for instance).