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 DBPro Corner / Feedback on game code, please?

Author
Message
gameangel147
9
Years of Service
User Offline
Joined: 2nd Dec 2012
Location:
Posted: 29th Sep 2013 23:36
This is a small game I have been working on and wanted to get some feedback on my coding and I was told I could post here. It is mainly finished, save for a bug or two and wanted to know if there was anything I could have done better or more efficiently, that sort of thing.

Since I made this game mainly to practice my programming and learn the language, I am only interested in feedback for the coding, not the art or design of the game.

Some notable bugs:

-After space bar is pressed to start the game, the game goes to a black screen but does not draw the game sprites or start the game. Application must then be re-launched.

-After losing and restarting for a couple of times, restart will fail to work and player will be stuck on the Lose Screen, and the application must be re-launched.

I have included all of the files. Any feedback would be appreciated and thanks for the help.

Attachments

Login to view attachments
Inflictive
13
Years of Service
User Offline
Joined: 16th Jun 2009
Location: Altis
Posted: 30th Sep 2013 04:16 Edited at: 30th Sep 2013 04:18
Pretty solid for the most part. I don't know why it randomly refuses to reset.

- You don't need 2 platform and 3 spike arrays, you should put them all into one platform and one spike array, and then individually check each platform/spike every loop to see if it's out of the screen and then reposition it.

- The random generation constantly makes impossible levels, try designing it and then making it repeat. Or design a few different "partial levels" and have the game randomly choose which one to create next.

- In the loss screen you don't need to constantly redefine the sprites:
sprite (x + 1), scoreNum.xPos, scoreNum.yPos, asc(mid$(playerScore$, x))
The sprites are drawn in the sync command.

- set window position 560, 240 :
If it's to center it on your 1920x1080 screen keep in mind that everyone has a different size monitor and you should calculate it instead.

gameangel147
9
Years of Service
User Offline
Joined: 2nd Dec 2012
Location:
Posted: 30th Sep 2013 23:41
The reason for the multiple arrays was so that I could keep better track of their Y positions, an array for one row of items and only worry about their X positions and not have to keep track of which ones go on where. It did create an unnecessary amount of arrays though.

And I am aware of the imbalance issues, as I have been more worried about getting the code to work right and fixing bugs. I will get to balancing the game soon.

Thanks for the tips though, you brought some things I need to work on to my attention. Much appreciated.
Phaelax
DBPro Master
19
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 1st Oct 2013 02:26
Took me like 7 tries before I realized that the "stars" weren't collectible items but instead they were spikes.

Code structure looks good. The only thing is, and this just might be personal preference, the comments aren't indented with the rest of the code. So for me that throws things off a little bit when I'm trying to scan the code quickly.

titleScreen
Instead of calling wait 400, it's probably better to display a counter to the user letting them get prepared to start. Like have a big number displayed counting down from 5 or something then GO! Providing feedback to the user is always better than sitting silently in the dark (even it is only .4 seconds).


createObjects
I see you duplicate a lot of the same sprites. An alternative would be to create a single sprite for platforms then use paste sprite. Build an array of platform locations, then every sync you would draw the sprite at those position. You could even skip using the sprite altogether and just use paste image as well but then you'd need to handle the collision manually.


positionObjects
Definitely needs work. Even though it's not likely to happen, theoretically speaking these loops could be infinite. Because the completion of the loop is dependent on random values not overlapping, there is no finite state to end the loop.

Quote: "-After space bar is pressed to start the game, the game goes to a black screen but does not draw the game sprites or start the game. Application must then be re-launched."

This is one possibility that can be related to the above issue.



moveObjects
This whole thing can be a lot more efficient. You have a lot of redundant subroutines that would benefit from creating functions instead. To fix that, I had to change how you track your data.



Here would be the updated code for creating the platform objects and building the initial array. A single array to store all platforms.





Now remember all that code you had for the moveObjects routine?


This is a better approach for several reasons. The first is obvious, it's far less code. When you find yourself reusing the same code in multiple places, you should ask yourself if a function could be used instead. The other reason you're making the code a lot more manageable by storing the sprite IDs within the array. If for some reason you wanted to make a change to the sprite IDs or add more platforms, there are multiple areas where you'd have to update the code.


pasteScore
Probably better off as a function. If I wanna get picky, the routine is called pasteScore but yet it also updates the score as well. In other words, two different functions are being performed. So if you want to keep it all together it's a better practice to create a name that reflects that. This would be one option:


Also, I'm not sure why you have some values related to the score (location) as UDT values but left the actual score value itself separate. This doesn't hurt anything, but I'd either include it as part of the scoreNum variable or make it part of the set of player variables. But your method won't impact anything.



lossScreen
Inflictive already touched on this a little bit, but I had something to add. Instead of deleting all the sprites, which you will most likely recreate, simply hide them instead. When you're ready to restart the game, unhide them. This will reduce the overhead of constantly removing/re-adding data into memory. It's not wrong doing it your way. In fact on a larger scale you probably would want to do this when moving between levels so you don't fill up memory with unneeded junk. But since your game reuses the same images/sprites each time, may as well just keep them there until the player exits the game.



p.s. I think this is my longest reply ever! (Even by Raven's standards )

Login to post a reply

Server time is: 2022-06-27 06:26:55
Your offset time is: 2022-06-27 06:26:55