Making Efficient Coding

[Aange10]

What is it you are trying to achieve?
I'm trying to make my coding efficient, and clean. And I have a question about procedures.


What is the problem you are having?
Well I'm looking to put my collision detection into a procedure, in hopes to clean up what could amount to 100s of lines of code ( across various levels that is)

EDIT: Also, if you'd note the part of my collision that has the variables +12, that is me saying that if your withing 12 pixles of this place then you've hit it. Is there a way I can stop doing that, and get perfect collision between rectangles? I'm willing to work with Trig, and I've read over the perfect circle collision as well.

Post any relevant code (You may choose to attach the file instead of posting the code if it is too long)
I'd like to know if the two lines

code:

player_y := (platform(a).platform_y - 2) - player_height             map_y_velocity := map_y_velocity * -1

will still activate, and work cooperatively with the rest of the game if this is run by a procedure.

Turing:

%Collision on bottom & side of platform     for a : 1 .. 4            if player_x >= platform(a).platform_x and player_x <= platform(a).platform_x + platform(a).platform_width and player_y + player_height <= platform(a).platform_y + 12 and player_y + player_height >= platform(a).platform_y then             player_y := (platform(a).platform_y - 2) - player_height             map_y_velocity := map_y_velocity * -1         elsif player_x + player_width >= platform(a).platform_x and player_x + player_width <= platform(a).platform_x + platform(a).platform_width and player_y + player_height >= platform(a).platform_y and player_y + player_height <= platform(a).platform_y + 12 then             player_y := platform(a).platform_y - 2 - player_height             map_y_velocity := map_y_velocity * -1         end if         for d : 0 .. player_height             if player_x + player_width <= platform(a).platform_x + 12 and player_x + player_width >= platform(a).platform_x and player_y + (d) >= platform(a).platform_y and player_y + (d) <= platform(a).platform_y + platform(a).platform_height - 1 then                 hit_side := true                 exit             end if         end for     end for

Please specify what version of Turing you are using
4.1

NOTE: My lousy player_y and such variables will be replaced as records later on, and I just am not doing that right now for simplicities sake. But before the first version is released (of this game) I will clean up my variables.

[TWizard]

Well, to make things easier on your eye's you could just shorten the words instead of having player_height maybe use playerH that way it should not drop down lines, other then that everything else looks to be good. But i don't fully get what your trying to fix, i know you want an efficient way of building your programs but, in what way? for example making it run smother, or making it easier to comprehend.

[Aange10]

Oh, sorry for the misunderstanding. My variables are fine, I like them. My problem was really just a question. I'm asking if I put the code i showed, into a procedure, and ran the procedure would it correctly work with the rest of my game.

E.G
if I have all my collisions set into one procedure, and I run that one procedure in my loop will collision still work? Or will whatever happen in the procedure not affect the rest of the game (hence forth it not work)

[Tony]

It would "work" if everything is a global variable, but there are a number of software engineering problems with that.

1 -- you have global variables, which are typically frowned upon (scope issues, unrestricted access, etc).

2 -- the procedure is not generic enough to be reusable.

You'd want to design your logic into generic functions that return some value. Something along the lines of

code:

function is_platform_hit(player : Player, platform : Platform) : bool    ...

Then the use could generalize to

code:

for a: 1..4    if ( is_platform_hit(player, platform(a)) ) then       put "Player has hit platform #", a    end end

[Aange10]

Hmm, global variables are frowned upon? But they keep things accessible D: ... who's going to be changing it other than the programmers? haha.

I kinda see what your saying on it not being generic enough. Though I thought using a for to go through all the platforms in the game would cover it. (Or just go through the ones that are within 200 pixles of me.. easy enough if statement there).

Tony wrote:

It would "work" if everything is a global variable, but there are a number of software engineering problems with that.

1 -- you have global variables, which are typically frowned upon (scope issues, unrestricted access, etc).

2 -- the procedure is not generic enough to be reusable.

Then what do you suggest I do?

[Tony]

Often it's a better design when internals are not accessible. At least not directly. Imagine that you have some variable called "counter" that you design to only be incremented by 1 when some condition occurs. If it's a freely available global variable, another programmer might just set it to any value directly, breaking your design. Alternatively, how many different "counter"s might occur in a large enough project? Million lines of code, thousands of files... you will not want to keep every global variable in mind.

Design is more important when a project grows in size and you get that second developer working on the same code base. This is also true for libraries that other people might use.

[Aange10]

Hmm I see. Thankyou. Tomorrow my game shall see many improvements!

[Insectoid]

Your variable names aren't horrible, but you're sort of missing the point of records.

platform[i].platform_y could (and should) just be platform[i].y. No need to call it platform_y because the record already specifies that we're working with a platform.

Similarly, player_x, player_y, player_height, etc. could (and should) be in a record. Same with map variables. Doesn't player.x and player.height and map.x and map.vel_x look better than map_x, map_vel_x or player_height? And it makes it so much easier to add players, platforms and maps!

As for global variables, well, in a lot of cases 'user' doesn't mean 'using the final end product'. Often a user is a a developer, using that code to write more code (for example, game engines).

Continuing the game engine example, the engine is a product to be sold. The developers do not want the users to know how it works (or they'd just write their own, right?). They also don't want the user to mess around or change any variables 'cause then the engine might not work. If every variable were global, it would be much easier to figure out how the engine works or accidentally break it. From this stems object-oriented code which (more importantly than the whole 'it's how our brains work' argument) makes it very easy to hide or show exactly what you want to hide or show.

But I digress.