Old code

[Opry99er]

I pulled Honeycomb Rapture out of the dust pile today and played it. It was challenging at first (which was cool) but then I remembered the bee patterns and it became dull. Once I got back into the groove, I racked up 10,000 points and 3 extra honeybees very quickly. Cool to play the ol' game again, but it got me thinking about the code and all the improvements I wanted to make but never did.

 

I pasted the code into Notepad++ and was HORRIFIED at the lack of structure, unnecessary garbage content, unoptimized subroutines, spaghetti, etc.

 

Now I want to 'finish' the game and restructure it for use with XB256 and the compiler.

 

 

How many of you have gone back to an old game program or application you wrote 5+ years ago and said "What the hell was I THINKING?!?!?!"

[Willsy]

Meh. I go back to code I wrote 5 *days* ago and think the same thing! It's a lot worse in Forth. You're like "Wow! Whoever wrote this was f***ing guru because I'm understanding NONE of this!" Then you realise that YOU wrote it and your heart sinks!

[+OLD CS1]

Five minutes... five days... five weeks... five years... yeah. When I pulled out the code for some of the programs I wrote in the early- to mid-80s I shrugged most of it off as inexperience and youthful indiscretions. When I pulled out the code for my BBS program which I worked on between 1989 and 1994, I thought a few things: "What the hell was I thinking?", "How (or why) the hell does THIS work?", and "Cool, I can bum a few bytes here."

[Opry99er]

Yea with Honeycomb, I noticed several little things that could be improved by just a simple switch of logic... Few little tweaks within a line here or there... The starting locations and/or speeds of enemy SPRITEs need to be randomized so that the patterns are less predictable. Instead of

 

25

 

I should do

 

INT(RND*18)+10

 

(or something of the like)

 

This would eliminate the same predictable pattern each time through the sequence.

 

 

Just a couple little things like these would make the game much more challenging and less like a kid's reflex challenge.

 

Anyway, the BIGGEST beef I have with the code is the lack of structure and flow. I basically came up with several pieces of the game, assigned them numbers, and tweaked it til it ran. Part of the main game code sits below my subroutine sections and the program jumps around all over the place.

 

It is good to look back and see the progress that has been made over the years in the flow and structure of my programming...

 

In 5 years, I'll look back at what I am doing now and.laugh...

[Tursi]

How many of you have gone back to an old game program or application you wrote 5+ years ago and said "What the hell was I THINKING?!?!?!"

 

I first started Super Space Acer in C in 1990 - it was my second ever C program. So coming back to it 5 years ago and porting to the Coleco was an amazing experience. "What the hell was I thinking?" was probably the most kind thought I had for Past Tursi.

[+Vorticon]

Once I consider a program done, I almost never go back to it unless there is a major bug. But it's out of cowardice because I really don't want to know about my past failings I'd rather spend the time creating new content instead...

[Opry99er]

^^definitely understand the 'new content' thoughts...

 

In this case, however, I actually consider what I am doing to be just that. Re-make the game (which is decent in content) to be compatible with XB256 (for the SCREEN1/SCREEN2 and music) and the compiler (in order to get the game onto a cartridge.)