JC Software Posted April 29, 2018 Share Posted April 29, 2018 Hey guys back from the dead, but soon to be dead again. I won't be able to work on any bB or any 2600 games for that matter until summer begins. On to the question: So lately Iv'e been learning about spaghetti code vs structured (or lasagna) code. Then I realized my bB games seem to follow a little bit of both formats.I was wondering if spaghetti code is still as bad as a format for visual bB or if it's mostly for big programming projects made with C++ or Java. I mean to be fair bB is more limited than any big programming language, so you should have to use lots of goto's and if statements right? Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted April 29, 2018 Share Posted April 29, 2018 Seems like a lot of new users want to stick a bunch of gosubs in when they're not needed. If multiple places in a program need to use the same chunk of code, we use gosub to save space. Here is a related link: Parts of a Program 1 Quote Link to comment Share on other sites More sharing options...
JC Software Posted April 30, 2018 Author Share Posted April 30, 2018 Iv'e been doing most of the parts except for Subroutines, Code Blocks, and Data. I assume as long as I follow those steps I should be good.Thanks once again Random Terrain 1 Quote Link to comment Share on other sites More sharing options...
vcsrocks Posted April 30, 2018 Share Posted April 30, 2018 The problem with spaghetti code is that it can be difficult to debug and even worse to maintain. 1 Quote Link to comment Share on other sites More sharing options...
ultima Posted May 1, 2018 Share Posted May 1, 2018 I will add from my thread bogax quoted aprox 7 cycles for each if..then statement. So if you have 20 or so if..then statements in a row you can use a on..goto with 20 lables to make a select case style flow so it only needs to read which lable to goto then test the condition and do whatever then go straight out to the next section of the program. For my zeldaesque game the program structure now flows like this: -variables -titlescreen (sub) -gameover screen (sub) -setup new game -Mainloop -check if playfield is cue to draw, if true skip next 4 sections - player input - enemy movement - collision detections - test if playfield updates (jump to draw players) - draw playfield - draw players - update sound fx -drawscreen -goto Mainloop - vblank (reflect players) I'm sure other more experienced programmers have even more tricks to share ? 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.