I wasn't aware of things improving, it just happened over time. The biggest problem of about any language is the potential to make a mess of your code. The more mess, the less chance you could ever read it back after half a year. So, before you start thinking about something big, first think of how you are going to program it, prior to actually program it. It's easy to say 'oh, I need another global variable for this and that', and before you know it your whole application becomes a mess because you'll end up with hundreds of badly named variables that are all messing up.
The key to organization is data-hiding: no globals, everything is local.
Another aspect of data-hiding might be called code-hiding: make functions that are so generic and well described that you never need to look into the function code again. You could put all these generic functions into some include file and use it all the way. You truly use a lot of stuff then, but you won't need to know how things work, they just work.
If a space shooter is too hard, then don't do it. I see this again and again: people get into Blitz assuming that the first thing they will ever make is a shooter, RPG, whatever. Although understandable from a BRL-sales point of view, the "make your own games" slogan is way out of bounds. Blitz is just a language as any other language. It comes with handy gfx functions, it hides techstuff, that's all nice -and certainly suitable for beginners-, but it's still a normal language, not a RAD gamebuilder. So, if you had put your hopes on making a serious looking game within a few months.. well, sorry to pop your balloon.. but that ain't gonna happen.. :P
It'll take you years to become a procedural master, then when you finally feel you know the drill, then procedural Blitz won't cut it anymore and you'd wish for an OO approach and you'll end up spending years on BlitzMax again.
How to improve yourself? First think/design, then code. Don't start coding major chunks before you know what you're going to make. Split problems into smaller problems, identify whether multiple situations could use the same code-solution, if so: make sure that this one single code-solution can handle multiple situations. Do this for all your functions.
The key to organization is data-hiding: no globals, everything is local.
Another aspect of data-hiding might be called code-hiding: make functions that are so generic and well described that you never need to look into the function code again. You could put all these generic functions into some include file and use it all the way. You truly use a lot of stuff then, but you won't need to know how things work, they just work.
If a space shooter is too hard, then don't do it. I see this again and again: people get into Blitz assuming that the first thing they will ever make is a shooter, RPG, whatever. Although understandable from a BRL-sales point of view, the "make your own games" slogan is way out of bounds. Blitz is just a language as any other language. It comes with handy gfx functions, it hides techstuff, that's all nice -and certainly suitable for beginners-, but it's still a normal language, not a RAD gamebuilder. So, if you had put your hopes on making a serious looking game within a few months.. well, sorry to pop your balloon.. but that ain't gonna happen.. :P
It'll take you years to become a procedural master, then when you finally feel you know the drill, then procedural Blitz won't cut it anymore and you'd wish for an OO approach and you'll end up spending years on BlitzMax again.
How to improve yourself? First think/design, then code. Don't start coding major chunks before you know what you're going to make. Split problems into smaller problems, identify whether multiple situations could use the same code-solution, if so: make sure that this one single code-solution can handle multiple situations. Do this for all your functions.