Jump to content


Structured Code Question

4 replies to this topic

#1 Lolkiu64 OFFLINE  


    Space Invader

  • 26 posts

Posted Sun Apr 29, 2018 2:14 PM

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.  :P 

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?

#2 Random Terrain OFFLINE  

Random Terrain

    Visual batari Basic User

  • 29,018 posts
  • Controlled Randomness
    Replay Value
  • Location:North Carolina (USA)

Posted Sun Apr 29, 2018 5:04 PM

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

#3 Lolkiu64 OFFLINE  


    Space Invader

  • Topic Starter
  • 26 posts

Posted Sun Apr 29, 2018 6:27 PM

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  :thumbsup:

#4 vcsrocks OFFLINE  


    Space Invader

  • 46 posts
  • Location:Germany

Posted Mon Apr 30, 2018 8:35 AM

The problem with spaghetti code is that it can be difficult to debug and even worse to maintain.

#5 ultima OFFLINE  


    Chopper Commander

  • 216 posts

Posted Tue May 1, 2018 9:15 AM

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:
-titlescreen (sub)
-gameover screen (sub)
-setup new game
-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
-goto Mainloop
- vblank (reflect players)

I'm sure other more experienced programmers have even more tricks to share 🎮

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users