Before you try to convert your code into objects and classes, there's a couple of other places that the code can be improved.

def getgoing(): 

      ...

This function is absolutely huge. It would probably be helpful to separate the function into separate logically sound functions. For example, you can at your setup operations and your game loop (more separation would probably be good).

pillar3 = pygame.image.load("C:\Users\GGK\Downloads\\tube1.png")
pillar4 = pygame.image.load("C:\Users\GGK\Downloads\\tube2.png")
pillar5 = pygame.image.load("C:\Users\GGK\Downloads\\tube1.png")
pillar6 = pygame.image.load("C:\Users\GGK\Downloads\\tube2.png")

You mentioned already that these are not device independent paths. Aside from that, these string values can placed into a constant somewhere earlier. That way, when you change what "tube1.png" or "tube2.png" are, you can change a single variable - and the change will be reflected everywhere else in your code.

white = (255, 255, 255)
movey = 4
movex = 0
widthofwall = 20

I took these as being constants, but I wasn't able to tell at first glance. Normally, const values are differentiated based on some naming conventions (all uppercase andunderscores to separate words). For example:

MOVE_Y = 4   

There's also some parts that I thought could maybe use constants.

if event.type == 25:
    firstrectlength = random.randint(50, height / 2)
    secondrectlength = height - 50 - firstrectlength
    firstrect = pygame.Rect(200, 0, widthofwall, firstrectlength)
    secondrect = pygame.Rect(200, height - secondrectlength, widthofwall, secondrectlength)  

It wasn't clear what some of these numbers meant (they felt a bit magic). Referring to a constant for these values is probably helpful for improving readability.

def anotherdraw(scorecarddisp, width, height,firstwall1,firstwall2,secondwall1,secondwall2,pillar1dest,pillar2dest,pillar3dest,pillar4dest,bird,birdimg,background):  

That's an awesome lot of arguments. I think I had two points to make about this. It's probably helpful to pass some of these arguments inside of a collection (e.g., a list). Also, it would probably be good to start including docstrings for your functions (and comments in general...but more emphasis on the docstrings).

Best of luck.

Before you try to convert your code into objects and classes, there's a couple of other places that the code can be improved.

def getgoing(): 

      ...

This function is absolutely huge. It would probably be helpful to separate the function into separate logically sound functions. For example, you can at your setup operations and your game loop (more separation would probably be good).

pillar3 = pygame.image.load("C:\Users\GGK\Downloads\\tube1.png")
pillar4 = pygame.image.load("C:\Users\GGK\Downloads\\tube2.png")
pillar5 = pygame.image.load("C:\Users\GGK\Downloads\\tube1.png")
pillar6 = pygame.image.load("C:\Users\GGK\Downloads\\tube2.png")

You mentioned already that these are not device independent paths. Aside from that, these string values can placed into a constant somewhere earlier. That way, when you change what "tube1.png" or "tube2.png" are, you can change a single variable - and the change will be reflected everywhere else in your code.

white = (255, 255, 255)
movey = 4
movex = 0
widthofwall = 20

I took these as being constants, but I wasn't able to tell at first glance. Normally, const values are differentiated based on some naming conventions (all uppercase andunderscores to separate words). For example:

MOVE_Y = 4   

There's also some parts that I thought could maybe use constants.

if event.type == 25:
    firstrectlength = random.randint(50, height / 2)
    secondrectlength = height - 50 - firstrectlength
    firstrect = pygame.Rect(200, 0, widthofwall, firstrectlength)
    secondrect = pygame.Rect(200, height - secondrectlength, widthofwall, secondrectlength)  

It wasn't clear what some of these numbers meant (they felt a bit magic). Referring to a constant for these values is probably helpful for improving readability.

def anotherdraw(scorecarddisp, width, height,firstwall1,firstwall2,secondwall1,secondwall2,pillar1dest,pillar2dest,pillar3dest,pillar4dest,bird,birdimg,background):  

That's an awesome lot of arguments. I think I had two points to make about this. It's probably helpful to pass some of these arguments inside of a collection (e.g., a list). Also, it would probably be good to start including docstrings for your functions (and comments in general...but more emphasis on the docstrings).

It is completely procedural, and while I do want to make it object oriented to clean it up

It's not necessarily bad that's it's procedural, and following an OOP format for your code isn't sure to clean it up. I think that starting off with separating your code into smaller functions would be a good direction.

Best of luck.