More 'o the same.....

I've been progressing with my BASIC interpretor slightly - as I thought, its slow going since I don't have a whole lot of time at night to actually do it. Still, at least its progressing.

I changed the way my token buffer works to allow multiple "basic" classes to have its own interface into the token buffer. This should allow multiple basic threads, which is fairly cool - even if it is just interpreted. I also added a token stack to allow items to be pushed back when they aren't needed. usually I only need a single item, but I added "N" depth just in case, although its yet to be tested.

Theres something odd with this code though, as Im having trouble following it a bit, which is usually a sign that its been over engineered an too complicated for its own good. So I'll have to take a step back and see what I've done wrong. I suspect I've just added a layer I don't need, or added it in the wrong place of course.

Currently I have the main program loop doing a pre-process, an then it calls ProcessTick() once "n" times a frame - or until its time allowed runs out. The Tick then in turn calls the TokenBuffer->GetNext() which fetches the next token and value/float/string if theres one attached. This is all very well, and fairly simple, which is why I'm wondering what I've done as it appears to be a bit more complicated that that.

Oh well... I must be doing something right at work, as I was playing with templates yesterday and did something Russell quite liked. This is pretty good as it shows I'm started to get the hang of it. STL gave me another kick in the teeth as theres another hidden option that lets you switch off range checking. I wish Microsoft would add a gamers switch that lets us go nice and quick, or at the very least TELL us about it! MS spend so much time telling us that games are really important to them, then ignore us completly when doing compilers and tools, it pisses me off no end.

A Basic Begining...

So, I've started doing the basic interpreter and I've pulled in my old lexical analysis class. It dates back to when I was doing a 65816 assembler (for the SNES) on the Amiga, and its been ported and updated over the years. It lets me jump into the deep end on these kinds of projects, without having to write yet another lex processor.

So, this looks like it'll be fairly easy and fairly good fun. So I need to start thinking about how I want to handle stacked variables and procedure calls etc.The basic construction is simple a memory block with an overlayed stack system and this give me a call stack as well.

I've also been thinking on the graphics interface and the virtual screen/sprite system. I think having simple SPRITE, TILE and PLAYFIELD system should give everything you need to make some fun games. Kind of like BBC Basic on a SNES, which is a good goal to aim for I think.

Basic part III

I've been talking over the idea of doing a simple BASIC with Russell, and although he thinks I should compile to a virtual machine from the outset. I've never written a compiler before, but I think it'll take enough time to actually write the basic in the first place, so I dont want to start writing a compiler as well! The good thing about this kind of stuff is that you can easily add a cimpiler at a later date, so I think I'll stick with my original plan.

Which is....

Simple Basic langauge based on spectrum and BBC basic.

Multi-plane CharacterMap and Bitmap screens

Simple sprites of variable size

Simple sounds via WAV sounds (or similar)

With these basics, you should be able to construct most 2D games. I really don't want to get into 3D, as the idea is to let kids learn, and you don't learn much by jumping into the deep-end from day one.

The best thing would probably be to pre-process the BASIC text file into tokens and then "run" them - kinda like the way old Sinclair Spectrum worked. This also lets me define global variables, procedures, and the main code.

Russ and I decided to get Andrew to write a small game to help train him up. I suspect that he'll manage fine, but the trick will be for him to carry the lessons over into his other projects. When I tried the other day to give him pointers, he didn't see why it was needed, and thought his code was fine the way it was. Part of the trick in games coding is writing something, and rewriting it over and over until its small enough, and fast enough, but these days with all the CPU power available to the average user, its easy to lose sight of that. Windows is a good example, in the days of Windows 3.1, it was actually around the same speed as what we have today, in fact in many ways it was way quicker. Whats changed? People have become used to all the power, and have wasted. Windows is full of really bad code, the fact that it can take a whole minute to enter a directory, or bring up the add/remove programs dialog shows this.

Beginners Luck

I've been thinking of that BASIC for a console again, and the more I think on it, the more I think its a good idea. I think I'd probably have to drop the idea about doing inline assembly, but the rest of it sounds good fun. I love the idea of giving Kids a simple toy to play with and learn at the same time. I also like the idea of writing a simple version of BASIC; never done one before so it could be fun!

I was looking though some code and have come back to the conclusion that I don't like the way C++ programers are heading. Theres too much use of the lanugage just for the sake of it. My view is that if I can do something simpler, smaller and faster than a fancy C++ templated STL'ed version then thats what I'll do. But the more I look at others code, the more I think they use all these features and extensions just for the sake of it. Russells usually fairly good with these things, so I hope that his usage won't pee me off when he finally gets around to writing it. If it does...that could be my signal to leave now. Its funny, Dave says he lets his team leaders manage the teams however they want as long as they produce the goods. In a way I think thats good, but in another... I don't like it. I can't put my finger on exactly why either...I'm sure its something to do with having at least a "basic" standard thought a company though, where as it looks like we're heading for at least 3 just now.

I've asked Russell to go over some code with Andrew to try and give him some pointers. He's doing fairly well but still has a bit too much "University boy" in him for my liking. All juniors start out like this, but it's a bit irritating that universities still can't teach "nice" code, although I probably shouldn't be too surprised since these places are usually around 5-10 years behind an industry. I'm not sure where he went to school, I know Abertay is fairly good with its games course, but Dundee University is fairly pants at its programming courses. I remember interviewing a guy from there that didn't know how many bits were in a normal "int", or how sign (+/-) was done. Thats just scary. But whats probably worse, is that these people actually pass!!

Basic programming.

I've been thinking more about writing a simple BASIC with some of the features I listed yesterday, and the more I think about it, the more I think Sony were on to something - if only they'd done it right. YaBasic on the PS2 was a great idea, but the BASIC was buggy and you simply couldn't do very much with it. Not only that, but there was no way to get programs out there to others short of handing over a memory card with a program on it. No, whats needed is an XBox arcade style thing where you can upload your programs and give them out in an easy to reach place.

Heres what I'm thinking... Write a nice version of BASIC, add some simple sound and sprite control, along with something for them to peek and poke, and perhaps even do a little bit of ASM when the mood takes them. The package starts up in a fullscreen editor just like the spectrum and C64 used to, which means all a kid needs to do is boot it up and go. Then, get it on a cover disk so that everyone can get it - or somehow sell it cheap or something. And then let kids have fun. A cross between spectrum and BBC basic would be great. Simple graphics controls, UDG graphics and sprites (which appear like the hardware ones on the C64) and perhaps even some sort of scrolling system. This should let anyone write a nice simple 2D game.

I dont think 3D should really be used. Things get complicated once you add that, and if you make it available, people want to jump right in and write Quake - thats not the idea. We need nice simple 2D games that let people learn, and then give them more direct access to the machine so that you can expand your understanding.

Now...while MS might let you sell a version of BASIC, Im not so sure about allowing assembler since that "could" then compomise the whole system. Once you can run user code... you can find holes and open the flood gate. Im sure it wouldn't be long before someone got a way to load hacked games from it. Perhaps running a simulated language 6502, Z80 etc. would work fine. Of course... it would probably be no quicker than the BASIC thats being run, so why bother... I need to think on it a little more.

Future games programmers.

I've been reading some other blogs on here, and a couple jump out. One of them go went on about how hard it is for young people to start programming. In the past (in the days of spectrums and C64's) you would switch on a machine and bang, you'd be ready to code. Now its very very tricky. Getting even the most basic program is way beyond what a 10 year old is able to do. But in the past you could give a child a TV, a computer and a very simple manual.

So what did these old machines - lets take a Sinclair Spectrum as the example - have to offer. First, as soon as you start your in the BASIC editor, this means theres nothing complex for a child to do in getting up and running. Second, you have direct access to the screen and simple graphics. Third having complete access to the machine and being able to PEEK and POKE everywhere allows very simple hacking and lets teenagers and the like get to know what a machines like and what makes it tick. Machines like the C64 add things like hardware sprites, character map screens, sound and music and rasters.

So, what does the modern machine offer? Well, they're big and powerful and have complex 3D built in not to mention great FPU support. But what do you have to do to actually use a PC to program? Well some sort of BASIC would be nice, but Visual Basic isn't "simple" by any means for a child to use. This means you would have to get some sort of QBasic, FreeBasic orYaBasic etc. Once you have all this, making graphics and sound etc. is still a fairly complex process.

All this adds up to a growing problem, computer programming is getting harder and harder and as such, professions like mine will become harder and harder to break into.

The other blog was on one that went into detail about just how hard it is to break into the industry in the first place. This blog explains that in rality there isn't actually a lot og games programmer jobs going around, and that with a lot of new talent comming in, theres less and less available.

Now, put these together, this adds up to less people interested in coding, and even less people having the interest in games programming. Normal programming is fairly simple, and even if you're bad at it, you can still make a living doing things like database coding, internal applications software and the like. But you dont last long as a games coder, if your hopeless; you might get by for a few years... but with the way games technology is heading... it'll outgrow you quickly.

Oh well....perhaps someone will bring out a "retro" machine that "Kids" can code again.