Platformer (Climber)

[Aange10]

Not sure whether to post this Alpha in the help forum or here. So I put it here.

I'm making a game with a friend just to put everything I've learned together, and make something I'm proud of. I'm posting this here to ask a few questions, and get some key feedback:
1. Do you see any flaws?
2. Is the coding messy/repetitive/inefficient?
3. Is the game's collision too messy?
4. Is 3. easily noticeable?
5. Do you have any suggestions to add (no flaming/sarcasm please)?
6. Any links you think would benefit me?
7. Did you like this first level? (It's an intro "level")

NOTE: This is not the full game, nor is it close to the final product. This is just testing the collision/graphics engine of the game, and the omniscient narrations.


If you'd like your name on the credits list, comment below!

[Zren]

Okay, that should get you started, but I doubt that's everything.

~

If you get the "not nuff mem to indent file" because you've got lines longer than x chars, you can do:

Turing:

if true         and true         and true         then     put "whoa" end if

~

Your types need work. Typically you do player.x or platform.w instead of platform.plat_width. I remember reading this in another thread I think. If you want to change it in this code, backup the file then use Search > Replace .var -> .newvar and click replace all.

~

Turing:

plat_height (1) := 50 plat (1).plat_y := (ground_y + ground_height) + plat_height (1)

Why'd you make a whole extra array (plat_height)?

Also, hardcoding values will be a pain no matter what. Consider loading platforms from a text file (x,y,w,h). Check out the example given for flexible for loading in a unknown size of data. Once you've gotten that, you can just edit the data in that text file _or_ you could create a level editor! That saves platforms to an array on a mouse click - drag - release. With a save button that will save to your platform.txt format.

~

You've hardcoded the number 12 a few times. What's it's significance?

~

Turing:

proc debug_show     loop         if show_debug = false then             show_debug := true             exit         end if         if show_debug = true then             show_debug := false             exit         end if     end loop end debug_show

That has to be the worst implementation of toggling a boolean I've ever seen. Why in gods name is there a loop?

~

I'd move the collision detection to a function that returns a boolean personally. That way I could just use something like:

fcn collision(a, b:Rect) :boolean
result a.x + a.w .....

~

I'd also move the common variables from both of your types to a subtype. Both platform and player types are rectangles, so I'd give it it's own rect type, then have each of the super-types have it's own r:Rect instead of their own w,h,x,y variable.

~

Example pulled from old code.

Turing:

type Point :     record         x, y : real     end record type Rect :     record         x, y, w, h : real         a, b, c, d : Point     end record fcn point (x, y : real) : Point     var p : Point     p.x := x     p.y := y     result p end point fcn rect (x, y, w, h : real) : Rect     var r : Rect     r.x := x     r.y := y     r.w := w     r.h := h     r.a := point (r.x, r.y)     r.b := point (r.x + r.w, r.y)     r.c := point (r.x, r.y + r.h)     r.d := point (r.x + r.w, r.y + r.h)     result r end rect fcn pointInRect (p : Point, r : Rect) : boolean     result r.a.x <= p.x and p.x <= r.d.x and r.a.y <= p.y and p.y <= r.d.y end pointInRect

[Aange10]

Zren wrote:

Okay, that should get you started, but I doubt that's everything.

~

If you get the "not nuff mem to indent file" because you've got lines longer than x chars, you can do:

Turing:

if true         and true         and true         then     put "whoa" end if

Alright, good to know. But I can indent my own code, so do you think it'd be smarter to do that? I personally think that having it in different lines for one command is ugly.

Zren wrote:

Your types need work. Typically you do player.x or platform.w instead of platform.plat_width. I remember reading this in another thread I think. If you want to change it in this code, backup the file then use Search > Replace .var -> .newvar and click replace all.

Wow. I can't believe i didn't notice the redundancy. Thankyou, fixed!

Zren wrote:

Turing:

plat_height (1) := 50 plat (1).plat_y := (ground_y + ground_height) + plat_height (1)

Why'd you make a whole extra array (plat_height)?

Also, hardcoding values will be a pain no matter what. Consider loading platforms from a text file (x,y,w,h). Check out the example given for flexible for loading in a unknown size of data. Once you've gotten that, you can just edit the data in that text file _or_ you could create a level editor! That saves platforms to an array on a mouse click - drag - release. With a save button that will save to your platform.txt format.

I don't know why i didn't realize i could implement it into the data record. Fixed! As for player maps, that is really an excellent idea!It sounds awesome, and thank you for telling me how to go about it! But what makes it more effective to put the coding in a txt file? Accessibility? (When not planning on a map editor)

Zren wrote:

You've hardcoded the number 12 a few times. What's it's significance?

This is because my collision isn't perfect, so i use it as a "grace" period at which my character may be by the box and it be considered collision. 12 because 12 + 12 was 24 and that's close to my character's height with 2 pixles above & below as margin for error. [Old thinking, really. Now that i think about it, that argument doesn't really matter too much]

If you have a suggestion/link/explanation/tutorial/fundamental or any other piece of advise i can analyze to make my collision perfect, PLEASE show me. I have read the perfect circle collision.

Zren wrote:

Turing:

proc debug_show     loop         if show_debug = false then             show_debug := true             exit         end if         if show_debug = true then             show_debug := false             exit         end if     end loop end debug_show

That has to be the worst implementation of toggling a boolean I've ever seen. Why in gods name is there a loop?

Fixed after looking up the not command in the turing reference. Sorry didn't know it did that.

Zren wrote:

I'd move the collision detection to a function that returns a boolean personally. That way I could just use something like:

fcn collision(a, b:Rect) :boolean
result a.x + a.w .....

Well considering my grace i have in affect, I need to teleport my character ontop of the platform so he's not hovering. (I know don't yell, i'm trying to get it perfect)

If you notice i do have most of my collisions pass booleans aswell, it makes it easier if i need to know about it later.

Zren wrote:

I'd also move the common variables from both of your types to a subtype. Both platform and player types are rectangles, so I'd give it it's own rect type, then have each of the super-types have it's own r:Rect instead of their own w,h,x,y variable.

Oh you mean like classes? Polymorphism, i think is what it's called. Parent class [well record in this case] Rectangle, then child classes player & platform?

~~~~~~~

Thank you so much for the critiquing, Zren! This is exactly the kind of help i need, and I'm thankful that you've given it to me. Definetly on the soon-to-be-implemented credits list!

[Aange10]

Version 0.6 is now released!

Changes:
~ Added a bit after the portal
~ Added a stick man as a character instead of a box. (Later will start as a box, and change to a stick man "As the game progresses...")
~ Added in a few more cheats (After implementing the new character, they are broken, however.)- Am planning on implementing new cheats.
~ Fixed up some messy coding with records.
~ Tidied up some redundant coding.

- Planning on implementing Saving

[Tony]

Reading v0.6

code:

var time_

there's an _variable convention that typically means "internal"; sometimes even __variable for some magical variables. Underscore at the end seems like an odd naming choice.

chars2 is declared but is not used.

code:

var ... sand_free ... : boolean := true

followed right after with

code:

sand_free := false

confusing.

Boolean variables can be used directly in conditionals. Instead of

code:

if sand_free = true then

you can simply say

code:

if sand_free then

The entire proc free_pics is not needed (and is not used anyway). If you have just those 3~4 pictures, you can keep them in memory until the program ends. Loading them back and forth is expensive (takes time). Freeing resources is important when you dynamically create and load a lot of new ones, but this is not the case.

player_clip_1, player_clip_2, ..., player_clip_6 this should scream "use an array", and it would be right.

code:

var plat : array 1..5 of Platform_data % Platform Record var plat_height : array 1..5 of int % Distance off the ground

plat_height sounds like it belongs to Platform_data

code:

plat_height(1) := 80 plat_height(2) := 160 plat_height(3) := 230 plat_height(4) := 310 plat_height(5) := 800 plat(1).plat_color := 7 plat(1).plat_x := 220 plat(1).plat_width := 30 plat(1).plat_y := (ground_y + ground_height) + plat_height(1) plat(1).plat_height := 10 ...

separation of code and data! This kind of stuff (map data) belongs in a map file. You could then just read the values in from a loop.

[Aange10]

Tony wrote:

Reading v0.6

code:

var time_

there's an _variable convention that typically means "internal"; sometimes even __variable for some magical variables. Underscore at the end seems like an odd naming choice.

Fixed. Renamed to fps_timer. Thanks

Tony wrote:

chars2 is declared but is not used.

Made the two variables when i first started the project. Fixed.

Tony wrote:

Post RE:Platformer (Climber)

code:

var ... sand_free ... : boolean := true

followed right after with
code:

code:

sand_free := false

confusing.

My bad, i put it in with a bunch of other variables that were boolean := true, and just made it false. Fixed.

Tony wrote:

Boolean variables can be used directly in conditionals. Instead of

code:

if sand_free = true then

you can simply say

code:

if sand_free then

Hmm interesting, didn't know that. However I think it makes it to put the = true. Is it really necessary to change it? If so I will

Tony wrote:

The entire proc free_pics is not needed (and is not used anyway). If you have just those 3~4 pictures, you can keep them in memory until the program ends. Loading them back and forth is expensive (takes time). Freeing resources is important when you dynamically create and load a lot of new ones, but this is not the case.

player_clip_1, player_clip_2, ..., player_clip_6 this should scream "use an array", and it would be right.

Ahh but, not so true D:. I've read in the tutorials it's good practice when using pics to unload them after they are done. I realize the mistake with my range on freeing the pictures, and I've set it to be just below the 2nd "level". Now it will correctly free pics, though do remember you can't go back down, so they won't be loaded back and forth.

Alright, pictures are now made into an array. Thanks for the heads up!

Tony wrote:

plat_height sounds like it belongs to Platform_data

code:

plat_height(1) := 80 plat_height(2) := 160 plat_height(3) := 230 plat_height(4) := 310 plat_height(5) := 800 plat(1).plat_color := 7 plat(1).plat_x := 220 plat(1).plat_width := 30 plat(1).plat_y := (ground_y + ground_height) + plat_height(1) plat(1).plat_height := 10 ...

separation of code and data! This kind of stuff (map data) belongs in a map file. You could then just read the values in from a loop.

First problem is fixed.
2nd: Yes, I guess I'll look into indexing and pointers. D: . I know I also need to implement a save system.

.....

Thanks a ton for your critiquing(:! If you see anything else please don't hesitate to let me know!

[Tony]

Aange10 @ Thu Oct 13, 2011 4:41 pm wrote:

Hmm interesting, didn't know that. However I think it makes it to put the = true. Is it really necessary to change it? If so I will

A lot of the points are more in terms of style and software engineering practices. Is it necessary? No. But I think it improves readability of the code.

[Raknarg]

Does it really? Js, to me it makes more sense to add the = true after so you know it's a boolean, a lot like you would put a string after a string and a number after a number

[Tony]

only when it comes to literal values. If you have code like

code:

if x == y

then you can't infer the type of either variable. So it comes down to a naming convention. You can assume that name_of_sheep and num_of_sheep are string and integers. Similarly you can figure that is_a_sheep is boolean. Ruby has a neat convention of ending function names with a question mark to denote that they return a boolean value.

[Raknarg]

I suppose thats true

[Aange10]

Version 0.7 Is now released!
Getting closer to the official release; 1.0!

Changes:

~ Cleaned up a bit more redundant code
~ Now correctly freeing recources via Pic.Free
~ Fixed some spelling on the cheat codes
~ Redesigned the admin cheat
~ Fixed source code variable typos
~ Implemented Saving and Loading systems based off your user name.
~ Graphics for the buttons!

Whats to Come:

~ A feature to remember the last username entered, and ask if that player is you.
~ A feature to show all your saves
~ Many more gameplay/levels
~ Many more working Cheat Codes
~ Witty narrorations and more graphical gameplay and characters.
~ Minor bug fixes
~ [Hopefully] A new physics engine
~ Intro screen/Story
~ Idle animations, interactive backgrounds, and MUCH MUCH more(:

Stick Around!

[Raknarg]

What I thought was interesting was how you made it so that your animations don't have the annoying white box around them, which is why I now only use turing drawing functions. How did you accomplish that?

[Aange10]

picMerge will accomplish that(:

[Aange10]

I feel very productive to be coming out with new versions so rapidly(: . However, do know that the next version will be a game content expansion, so expect an extended amount of time before its release!

But now let me interest you in Platformer V0.8!

Changes

~ Fixed collision bug with the first platform
~ Now saves in Data files instead of Txt files.
~ Fixed coding bug
~ The Douggie(:
~ Recommended Usernames (Saved Files)
~ Cleaned Variables
~ Appropriate storing of files
~ Massive improvement of physics engine
~ Full Commenting
~ Flying Cheat
~ Case proofed all cheats

[Aange10]

Aange10 wrote:

I'm making a game with a friend just to put everything I've learned together, and make something I'm proud of. I'm posting this here to ask a few questions, and get some key feedback:

I think I have definitely achieved this. I'm very happy to have programmed this little game. I've learned many concepts making this game. However, one very important aspect to a game is the graphics designer. Unfortunately, my graphics designer has let me down. I have nearly-zero interest in drawling pictures, I only care about the coding.

As a result of undependability on my friends half, there won't be new game content added. Which sadly means this is more of a "I enjoy seeing the coding work" than a "I enjoy playing" game.

Albiet not adding new game content, I'm happy to release the Official 1.0 Version! If you find any bugs, or any place to critique me, please let me know. I'd be more than happy to fix these bugs/inefficiencies.

If you have any suggestion on something to add to the already existing game, do let me know, as I'd be happy to add neat things or play with alien concepts.

But, now without further ado, let me introduce you to Platformer!

Final-Edition Changes:
~ Fixed bug where being on the username page too long made you Douggie
~ Added a disclaimer on the cheat codes
~ Login rememberer now properly remembers names with spaces
~ Implemented new platforms
~ Credits
~ Added two custom platforms