Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers AppGameKit Corner / Bug hunting help (warning beginner code)

Author
Message
Vladimuffin
7
Years of Service
User Offline
Joined: 27th Nov 2016
Location:
Posted: 15th Jul 2017 20:07
Just want to apologize in advance to anyone taking the time to look at this snippet. I'm still learning and havent work out arrays and functions well enough to do this any easier yet.

I have been working on a game for my children to help with coin counting. Everything seems to work fine but sometimes the right answer triggers a wrong answer.



Again, its plum full or redundancies and quite volumnus. I am totally open to criticism, and hope soon to be able to recreate this program with 100 lines or less =)

I just can't figure out why I am getting wrong answers when the input value is correct.

Attachments

Login to view attachments
Vladimuffin
7
Years of Service
User Offline
Joined: 27th Nov 2016
Location:
Posted: 15th Jul 2017 21:10
Forgot the quarter

Attachments

Login to view attachments
smallg
Valued Member
18
Years of Service
User Offline
Joined: 8th Dec 2005
Location: steam
Posted: 15th Jul 2017 22:42 Edited at: 15th Jul 2017 22:42
hmm well i'm not sure about american currency so assuming the cheat answers are correct try it like this

but this means you need to insert the 0 for values such as .70 etc
life\'s one big game
spec= 2.6ghz, 1gb ram, 512mb gpu, directx 9.0c, dbpro and classic
Vladimuffin
7
Years of Service
User Offline
Joined: 27th Nov 2016
Location:
Posted: 16th Jul 2017 00:14
Thank you for the feedback. I will give that a try right now. That also makes me wonder if 0.01 and .01 would be considered equal or not depending on the call.

The bizarre part about it is that it seems completely random whether or not it will work for a correct answer.

I even wrote down all the inputs that caused the bug, thinking I could find a pattern, and I dont see one.
Vladimuffin
7
Years of Service
User Offline
Joined: 27th Nov 2016
Location:
Posted: 16th Jul 2017 01:00
Well it would appear your solution is perfect! I didn't even think about that. Thanks smallg for removing the monkey wrench from my code! You are a life saver.
Kevin Picone
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Australia
Posted: 16th Jul 2017 04:53
Vladimuffin,

Quote: "
and hope soon to be able to recreate this program with 100 lines or less =)
"



well bellow has nothing to do with the your functionality requirements, more some ideas on how you can reduce the code foot print..


Dunno if you're aware of them or not, but repeative chunks of code like the following make an ideal candidates to become function

so this,



could be more like this





Code like this , can be tweaked to avoid polling the getpointerpressed() function all the time.



what you could is query getpointerpressed() outside, if it's not pressed nothing else need to happen




Those types of things will help you remove some redundancy, but what you prolly do is store your Key Sprites ID's in an array so you can iterate through them, which will help you further reduce the codes foot print..



PlayBASIC To HTML5/WEB - Convert PlayBASIC To Machine Code
Vladimuffin
7
Years of Service
User Offline
Joined: 27th Nov 2016
Location:
Posted: 16th Jul 2017 12:04
Thank you, Kevin. I was aware of functions but not sure how to call them or write them. I will implement both of your suggestions, as I think it will make reading through the code more pleasant for everyone.
Dybing
12
Years of Service
User Offline
Joined: 12th Sep 2011
Location: Bergen, Norway
Posted: 16th Jul 2017 23:10 Edited at: 16th Jul 2017 23:45
One "trick" as it were to make nice structured code, is to story-board your project. Before writing a single line of code, imagine the steps you need take from a users perspective.

Write down each of these steps. Like in your coin app, that would be something like:

- Start the game
- See various coins
- Enter in numerical value of coins
- Win/Loss
- Back to start

Each of those make for good functions. Then for each give them more useful names and embellish what they do more fine-grained. Like for instance:

startGame:

- Zero out variables
- Draw Game Menu
- Check for start-button

drawCoins:

- clear start menu
- draw x number of random coins

...and so on. Each of these entries also make for good functions. Doing it this way, you compose your project before actually filling it with code that do anything useful. You set up the general flow and structure first, fill in the details later.

Each function should ideally do as little as possible and be as short as possible. that makes them easy to write, read and debug. The name of the game is to divide and conquer. If a function grows beyond say 20-30 lines, ask yourself if it wouldn't be more practical to break it up into smaller chunks. In the same vein, if you are repeating yourself, you're doing something wrong.

Next think through your variables and constants. Figure out which belong together and bunch them up in a type. That makes it much easier to pass around, and it structures your data. Very important as projects grow larger.

Now, with your data - ideally you only want constants to be global, the rest should be passed around manually to and from functions. though for convenience it can be helpful to have one type with various state-flags and counters be global. If used all over the place, it makes life a little easier.

Also, apart from variables only used internally in a function, all data should be wrapped in types and arrays of types.

For beginners, Rob Pike's rule 4 and 5 is especially helpful:

Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.

Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.

Example - in my own code for a project I am working on at the moment, I found this:



Obviously some copy-paste going on. I must have been tired and out of coffee when I wrote it

Though, since all my data is neatly organized in types, fixing it was easy:



So now if I need change what this routine does (get the input from user selecting one of three cards), I can do the edit once, rather as before where I'd have to do it three places - with the potential for inconsistencies that brings which again leads to bugs.
Vladimuffin
7
Years of Service
User Offline
Joined: 27th Nov 2016
Location:
Posted: 17th Jul 2017 00:20 Edited at: 17th Jul 2017 13:43
I definitely see what you mean about debugging. I thought that changing the order of commands might fix my bug, so I wanted to move onesinput = 0.01 above roll = 1 and click = 1, but because i had it in 40 different if statements, it was quite the lengthy process (which still didn't end up fixing the problem). Im sure as I learn more terms and commands, and what they can do, I will be able to create good functions and legible code. I really like what you said about story-boarding, and I might remake this program from scratch using all the helpful bits I've learned in the forum.

I sincerely appreciate the time and effort spent responding to my posts, and will do my best to absorb as much of the knowledge provided as I can. Thanks so much

Login to post a reply

Server time is: 2024-03-28 10:47:24
Your offset time is: 2024-03-28 10:47:24