GeekSpace

3:11pm: Edgar Allen Poe
I was on the train home from Sam's place the other day when I got myself into a rather strange state. Fittingly, it was quite morbid.

I was suddenly struck with an over-whelming need to know more about Edgar Allen Poe. I had a vision that was very scary to me, of lying on my deathbed, realising I still didn't know very much about Poe, and desperately wanting to find out more before I died.

Okay, not sure, that might sound odd :P But it's about knowledge, learning, and most importantly, understanding. I can't remember why it was Poe (I was reading J G Ballard at the time), but he was just a symbol, it could have been just about anything. I realised there was something I didn't know, and I felt compelled to know it.

I don't know why this is, or if it's just me. What's the point in learning something if you're going to be dead the next day? Why not just have fun? I don't know why, but I have a massive mental block there - I just couldn't do it. I have to know. Without continued learning, and the pursuit of knowledge, I don't know what the point of living is.

So I do spend a somewhat frantic existence sometimes, with my 30 Firefox tabs open, following up links and drifting off the subject. But I get a real buzz every time I find something out - it's not about, "Haha! I have this knowledge and you don't", it's about understanding things: the world becomes a slightly brighter, richer place for me, with even more going on than I'd realised. It's a wonderful feeling.

I'm not saying you should choose researching Poe over going to a party for your final night on Earth. If you really want to learn a lot about human beings, go to parties.

But do make sure they've got a net connection there, just in case.

http://en.wikipedia.org/wiki/Edgar_allen_poe

4:38am: GameClient_Win32 - 497 error(s), 30 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

I hate doing code re-orgs.

2:32pm: Well, I'm about to get my first polygons up.

I'm still writing my 2D graphics routines - colouring rectangles, drawing lines, copying images from one place to another, but I'm not doing it right. I like the immediacy of old-school blitter and pixel-level access, but it's not what today's 3D cards are interested in.

The fast way to display a rectangular image on the screen is to create two triangles to represent it (a quad), and then to feed those co-ordinates, plus the image you want drawn, straight into the graphics chip. That is what today's cards are designed to handle fast.

There's also some really annoying restrictions with blitting surfaces to each other old-school. There's about 20 types of 'surface' (if you take memory pool, format, and some odd stuff about 'offscreen' which I'm still trying to understand) and each type can only be copied to certain other types (not to mention that some of those support 'stretching' the image during the copy, and others don't).

I can't work out a coherent design which will always fit the imposed criteria (which do make sense when you understand the hardware, but are a bit of a restriction when you're just thinking in terms of copying one chunk of memory to another chunk of memory).

So, with that in mind, I'm implementing textured quads. This isn't a hugely advanced concept, but I'm trying to get it to fit well in the graphics subsystem. Quads have to be drawn in batches for optimal performance, and that makes them a lot like DirectX's in-built sprite system. So I figure, stuff it, I'll just extend my sprite manager (which really just suffles objects around) to handle my textured quads too.

By all accounts, the Direct3D sprite code is very fast, so it will be interesting to see how my quads will perform - my goal here at the moment is to treat textured quads as just another texture, with that level of functionality. For anything more complicated we can use ID3DXSprite (rotation, etc.). Of course, this may change once I start using the system more and get a better idea of how it's used by the game.

You do get a lot 'for free' when you do things the polygon/GPU way. Our textured quads will be able to have a different colour at each other four corners, which will blend with the image when it's drawn. That could be interesting...

Eventually I hope to have all this running using pixel shaders, that will be way cool!

That's where I'm at.

I've made one dramatic improvement to the main class. It's no longer CClientAppFramework in client_ClientAppFramework.cpp. It's CEngine in cl_Engine.cpp. Sometimes I just over-complicate things.

I've been having a lot of fun playing with DirectX. There's a hell of a lot to it. I've made a very stupid miscalculation, and that's that you can wrap a system in a class without having a deep understanding of it. It just doesn't work. So I'm just going to take a week or two to play with DirectX and see what it can do. Of course, this will entail me writing new code and coming up with better, more optimised designs. So that's nice too :)

I've been looking at nVidia's 8800 presentations with the new shader model and DirectX 10 - those guys are very bloody clever, and the stuff they do is awesomely cool. Multi-textured shader-driven materials, geometry built on the GPU. Not saying I won't be able to do it eventually, but man it's advanced.

Wish you didn't need Vista for DirectX 10 though.

Maff

9:37am: So, I've made it so that with one line of code (well, a #define switch), the game can switch between displaying the main menu (the test case which I'm using to develop the GUI), and the game demo (which I'm using to unit-test different components and generally play around with).  This was very simple technically, but should be extremely useful for productivity...

Running as the demo, the next thing I need to get working is the audio system (still totally dead, but will be oh-so-lovely when it's not).  Running as the main menu, I can develop the GUI code.  So those are two systems I can develop in parallel and which are almost completely uncoupled. 

Why is it such a good idea to develop multiple systems at once instead of concentrating on a single sub-system?  Well, there's times when the systems are supposed to be orthogonal, or they need to gel together very closely, and it makes sense, but other times it's just because I get bored very easily being stuck on one problem and not being able to move forward.

(I could have made the choice between the main menu/demo at the Engine's GameFramwork level, and essentially had two different games, but so far it's simple enough to do at the Game level, which means I get to maintain a lot less code.  And the #defined switch only needs to be used in the Game's constructor, destructor, PostInitialise (), Shutdown (), and Tick () methods, and that's not too hard.)

So, for 15 minutes work, I feel it's worth writing about :)

11:24am: Oops...
Well, I've managed to break the audio system while trying to add Ogg support, so I'd better fix that. But I think I'm getting there, it's just more complicated trying to set up for file streaming sound with multiple sound file formats.

I've done a bit more work on the GUI, it's very slowly coming together. I'm writing a virtual default CGUIElement Draw method, which will just draw a rect on the surface for now. But I need a CPen class for that, and the start of some draw primitive routines to handle putting pen to surface, so I need to cobble that together too, hopefully in an elegant way.

One thing I didn't mention is that the game design has changed again. I've decided to write an essentially 2D game first. This cuts out a lot of work, and it lets me solidify all my existing code while not worrying about meshes and the third dimension. If I can get a game to 'release' stage it will prove the engine is ready to be extended for the 3D stuff (I'll still be designing around a 3D world, though - for camera and physics and so on it will just generally be with the z-dimension ignored).

So, what's the new game? Well, it's called Plasm. It's about RNA transcription and protein synthesis. And it will be 'cute'. That's all I've got so far.

But as a benchmark in terms of design and polish, think Puzzle Quest: god, that is really well done. And it's completely 2D.

I think it's bedtime for me.

Maff

7:17am: Lazy
I haven't posted for a while...! Umm, I have been doing a fair bit, though - was very social for a while, think it's done my head in. Anyway, I had a couple of weeks off programming to focus on real-life stuff, and it took me a while to get back into things.

I've paused on the script language system for now - it's just too hard, and tedious, and I don't have enough information on what I need it to do to do a thorough enough design, let alone implementation. I'll go back to that when I've got more confidence/understanding/an alternative.

So I've been working on other systems. Firstly rewriting my sprite and image classes to be more robust for practical stuff (anticipating the GUI). I've also got a pretty good input manager going now (it's DirectInput only for now - at some point I'll support joysticks etc. through XInput. I should also allow WM_ message support for the keyboard for text entry stuff).

To test the sprite and input system I've had a simple little demo running, with an animated mouse pointer, and (2D sprite) balls bouncing and rotating around the screen. I forgot how invaluable it is to actually have something running to be testing things against! Just tweaking that demo has helped me fix plenty of places in the engine where I could have been more sensible or robust.

I've also been fleshing out my Direct3D management, and that's got a lot of features now: I've got mode-switching and full-screen/windowed stuff set up, along with the code to enumerate available display modes and formats and device capabilities, and so on. That's very close now, but does still need some rounding out and tidying up. I'm still scared debugging the window/full-screen switching code.

I'm also working on a resource cache to store all Direct3D-related memory for when the video card device is lost and restored. I wasn't even sure I needed to be doing that, but then I saw there's a sample class that comes with the DirectX SDK which seems to do the same thing, except it's written in Microsoft-ese and is largely illegible.

What I do need to finish working out is how to fit that GPU resource cache alongside the game cache. I've been trying to diagram a case study of how a texture should be found and loaded and passed on, and how the two systems should fit together, and notify each other of changes, and yet not make them tied together.

I've also started work on the audio manager and engine. Those balls were just begging to make sounds, and it's such a nice independent system that it's easy enough to work on in parallel to other stuff. At the moment it only supports 2D DirectSound buffers, and I'm still improving the 2D model. Later I'll tier on a 3D sound system with a proper listener/source/environment model. I'm going to add support for streaming .wav and .ogg files next, though, just so I can say I've got background music. "Slide in Next To Me", by the Red Riders, for now, to be precise - just because I love that song right now :)

What else? I've also been working on a real-time profiler class. If I can get it to behave the way I want, it will be very cool and give me a lot of useful information. But it's tricky to get it all in how I want.

I've started on the GUI coding today - this will take a few days to show visible results, but should be fun. I'm just putting together the hierarchies and making sure things are being passed around properly.

Hopefully, once I've got experience implementing complex things like the main menu GUI entirely programatically, I'll have enough information to go back to the script system and get stuff like that stored externally where it belongs.

At the moment I've got -no- memory leaks! But I do need to work on my memory management and reporting routines after this. I also, with all my additional understanding of the issues, go back to the first ever class I developed for this project: CErrorHandler.

And that's about it at the moment.

So, still busy, and it's nice to being seeing some results.

6:53am: Chronometrically Challenged.
So I woke up at 6am. Or... 6. It said 6:07 on my alarm clock.

I'm going to a party tonight with Sam. I have to be awake by 2pm. When I looked at the clock and 'saw' it was 6pm I completely freaked, jumped out of bed, and hunted for my phone. In doing so, I noticed my computer said AM. By that time I could actually feel my heart beating with panic.

I so totally suck.

So I'm going to just do some researchy stuff until, you know, I can breathe again.

God, I'm an idiot.

Here's something game-related I've been thinking about: how to play it.

It's actually quite tricky to work this out. We want, say, three different helicopters. But the one we really want is the Apache AH-64 attack chopper. Now, the Apache (like the Cobra) is a two seater: pilot and co-pilot/gunner (CPG). The gunner controls the 30mm chaingun which is on a 'chin-mounted turret' and allows the gunner to engage targets which are, you know, not directly in front of the heli. Hmm. Here's some stuff:

"The Apache's 30mm gun is an area fire weapon used to suppress targets at close (up to 4 kilometer) ranges..." ... that's... 'close'!? Holy crap.

"...it is capable of destroying lightly armored targets like armored personnel carriers (APCs) and air defense artillery (ADA) systems. The gun fires a High Explosive Dual Purpose (HEDP) ammunition. The gun fires 650 rounds per minute (fast for a single barrel gun), and can carry a maximum of 1200 rounds in the magazine located in the belly of the aircraft."

I don't know whether we want to be able to run out of ammo, though requiring re-supply will add an interesting element.

"The gun is capable of moving left and right in azimuth up to 86 degrees from the nose of the aircraft, as well as elevating 11 degrees and depressing 60 degrees."

Okay, so we can work with those stats. We can engage ground targets with the cannon, but they can't be too close: the gun has a limit to how far down it will point. I'm not entirely sure how 'azimuth' is defined here: either the gun can swing almost perpendicular to the heli (86 degrees), or it's half that and can swing 43 degrees. I'm also not sure which of those would provide the most fun gameplay.

(the Apache Longbow variant has the very cool ability to radar guide 'arcing' missiles - it can hide behind a hill and fire missiles over it. I don't think we need to add this complexity...)

So... what does the helicopter need to do? It needs to fly, and to fire guns and missiles. Duh.

The two bits that have me scratching my head are: controlling altitude, and dealing with the fact that some of the helis will have aimed mini-gun cannons and others are fixed.

Piloting helicopters in anything even approaching a realistic model is bloody hard work. Just ask any of my team-mates at the bottom of the ocean after I've been silly enough to try and transport a squad off of a carrier and to the mainland in Battlefield 2 (it's so much fun when there's 6 people standing around on a carrier deck all looking at the Black Hawk and waiting for someone else to be brave enough to try piloting the damn thing!) :P

Anyway... this is an arcade game, not a sim. For keyboard/mouse, we'll use WASD for basic flight: W and S to accelerate/decelerate (the heli pitches up and down as it does so). A and D to strafe and turn: when you initially hit left and right the chopper will bank and slide, and as the key is held down this will transition smoothly from strafing to turning.

Now, the shooty bits. As is standard for this sort of thing, if we're going to have aimed cannons and/or missiles, we'll use the mouse to direct the fire. So we'll have a little cursor reticule thingie that you move around the screen, and which directs fire there (it would be nice to have lag: when you move the targeting reticule the turret has to catch up, so pressing fire after moving the reticule from point A to point B sprays bullets across that path). So, left mouse button to fire cannon, right mouse button to fire missiles. When there's multiple missile types, we use the 1, 2, 3, etc. keys (or, alternatively perhaps, the scroll wheel) to select missiles.

But for fixed-cannon helis like the MH-6 Little Bird, mouse movement will have no effect: the reticule will always be right in front of the helicopter (I don't know how the gun is aimed up and down, it might just be done via the helis pitch? I need to find out.)

Anyway, this is a big gameplay discrepancy: some of the helis use mouse movement, others don't. One way of dealing with this is to ease the player into it: have the initial missions use fixed gun helicopters, and when they're comfortable with that, give them an Apache to play with. This could be a lot of fun. I don't know if it will work.

Now... altitude. Real helicopters control altitude by... umm.. I've never worked this out, to be honest. It seems to be dependent on pitch, but it's no way near as simple as for a plane. By the time I think I'm understanding the relationship between pitch, speed, and altitude in any realistic heli game, I've ploughed into the ground.

With the control scheme above it's going to be a bit sucky having additional 'up/down' keys. But I really, really, really want altitude to be a factor. We could easily 'cheat' and make, say, "Q" and "Z" just be up and down, but that's possibly a bit too arcadey. We need to work out an easier way to control altitude naturally.

(yes, all the keys will be configurable, but it makes sense conceptually to have a workable default layout! We also need to work out control schemes for gamepads and joysticks.)

I think I'll have quite a bit more time to think all this through, though. Like, at least until I've got a game engine.

Oh, found another wonderful US operation name: "Operation Gothic Serpent"..! It was the name for the op to capture the Somalian warlord which led to the whole "Black Hawk Down" thing.

*sigh* I like everything about war except the bit where real people get really killed. But the technology, strategy, logistics... fascinating. I read a wonderful quote from Steve Grammont, a designer of Combat Mission: Shock Force (realistic turn-based war-game that depicts a US invasion of Syria):

"Lastly, we have a few words about the political dimension of all this. We at Battlefront are military historians by hobby and training. We make wargames for their tactical and strategic challenges, to explore what-ifs, relive and reenact military history for entertainment and, in some cases, for education. We focus on the military aspects only and largely leave the political dimension out, except where it is needed to provide a credible background. Shock Force is not a political statement about past or current wars or any future conflicts. It is primarily an entertainment product for those of us who like military games, created with the utmost respect for those who unfortunately have to endure in reality what we armchair generals do from the safety of our desks. None of us would mind if we never again saw another war in the future to use as a model for our games. Unfortunately, this will probably remain wishful thinking."

You can be interested in war without actually liking it very much.

I think I should try and get back to sleep now.

1:15am: Whirlwind Fury Strikes Ferrets
So, amongst other things, I've been thinking about names.

It would be nice to have a name for, umm.. me? I originally used Bad Ferret as a silly random account name for lj, but it's growing on me. I think it's kind of a cute name for a game studio. So that's that sorted. "Bad Ferret" - just that, nothing appended, no "Games", "Entertainment", "Productions", "Studios". I like it. Until I come up with something better.

Next is the name for the engine. I came up with a few ("Kinetic" and "Inertia" are pretty physics-sounding, which, umm, doesn't reflect the current state of the engine). I like Catalyst. It works: the engine is the catalyst that speeds up game development. So that's that done. Until I come up with something better. Or I find out someone else is using it.

[Oh, bollocks, I'm an idiot: how did I forget that ATI's video drivers are called Catalyst? That's not gonna work. Bugger. "Impulse"? Too Star Trek and physics again. Oh well, will rethink it.]

As for the game name itself, I'm still working on it. I've been thinking of names used for military operations. The Americans love things about restoring Hope and having Freedom endure. Then again, they've also done operations in Iraq called "Slim Shady" and "Suicide Kings"... and don't even get me started on "Grizzly Forced Entry" and "Devil Thrust"...!?!

Oh, and they still swear "Operation Red Dawn" had nothing to do with Charlie Sheen and Patrick Swayze. Yahuh.

The UN are really dull, all they have is acronyms. The UNMWAWBH (United Nations Mission to Wander Around Wearing Blue Helmets) is not exactly a good game name.

One of my favourite books is "War Fever", a collection of short stories by J.G. Ballard. The story the title comes from is about the UN in Beiruit - it's a very neat little tale.

For the record, I'm a strong supporter of the UN. But they do leave themselves open to ridicule. Do you know they don't employ smokers? That's fucked up. If the WHO wants to reduce smoking (which is indeed a good thing) I don't see how alienating and losing the personal experience of people who actually smoke is going to help. They'd be much better off if they screened out applicants who suffer from intense stupidity. I'd suggest they extend that to actual member nations, too, but that would alienate the ones who need the most assistance.

Anyway, anyway, I've made a list of keywords which might help:

Surge, Strife, Blade, Sweep, Cyclone, Fury, Whirlwind, Strike. And, of course, Hope and Freedom. And Eminem.

Also, things like colours, and other neutral descriptors are pretty neat.

So the game name is Blade Mauve Fury Strike (Hope!!!).

Or maybe not.

I think I'll go to bed now.

7:46pm: Screw the Hostages
GameSpot have an article here:

http://au.gamespot.com/features/6165750/index.html?sid=6165750

... about pet game peeves. It's called "Un-Valentine's Day: GameStuff We Love To Hate".

Anyway, people have added their comments, and this one is very true, and relevant to one of my game ideas:

"Escort missions need to go. i hate when my progress depends on the survival of AI controlled goons who all but try to get shot. i don't want to protect the hostages. SCREW the hostages."

Guy's got a point :P

Hopefully I can get the AI good enough to make escorting make sense. AI hostages are notoriously stupid in games. In my game I kind of imagine them being surrounded and ushered along by AI team-mates protecting them.

But AI team-mates can be notoriously stupid too...

Hmmm.

6:11am: std::string.insert (0, brain)
It's gone 6:30am. And I'm still awake.

This is Wrong.

But I have done some coding that I'm really happy with, namely re-writing the CScriptReader class. Let's recap the script engine so far, it's pretty simple. Basically:

CScriptReader --> CTokeniser --> CParseTree

So, the script reader pulls in the file and cleans it up (strips out comments, whitespace, etc.), the tokeniser turns it into... well, tokens, which are then sent to the parser to build the parse tree.

So I've rewritten the script reader to use STL strings rather than messy TCHAR arrays. It's -so- much nicer!!! This is the first time I've really used the STL string class, and while I'm still not sure about using them for anything time-critical, once I got my head around it I was able to simplify the code heaps.

What's more, and this is the bit I'm really happy about: it took me about an hour to add a pre-processor in there, and it's working well. I was going to handle this further down the line, in the tokeniser or the parser, but getting it done here makes sense and takes a load off of both of those, which are doing way too much already.

The pre-processor is dead simple - it just uses #define syntax for basic search and replace. But it's solid: I build a map of find/replace strings, and it can handle multiple instances of different ones on a single line. It came together very nicely.

As an example, what this means is that if I have a script like:

// Define assets paths
#define AtlasFile "Art\MainMenuTexture.png"
#define BackgroundFile "Art\MainMenuBackground.png"

Here, every time it sees "AtlasFile" in the script it knows to replace that with the actual path to the texture file. So, for example:

Background = BackgroundFile;

... is replaced with...

Background = "Art\MainMenuBackground.png";

Pretty simple really, but oh so much nicer when you don't have to specify stuff like that every time you want to use it.

Oh, I was actually testing with this line, just to upset it.

1 AtlasFile2AtlasFile XBackgroundFile AtlasFileAtlasFile BlahBackgroundFileBlahBlah...AtlasFile

And it got it completely right, poor thing:

1 "Art\MainMenuTexture.png"2"Art\MainMenuTexture.png" X"Art\MainMenuBackground.png" "Art\MainMenuTexture.png""Art\MainMenuTexture.png" Blah"Art\MainMenuBackground.png"BlahBlah..."Art\MainMenuTexture.png"

So cute :)

(oh, also, it will only do the pre-proc search/replace after the #defines, not globally to the whole file. This makes a lot more sense, it's the right way to do it, and it would have been much harder to implement if I'd tried to do it further down the pipe - really, the ParseTree should not need to know what line number the script is up to!)

Oh, also, instead of pure text output, the file reader now outputs a proper structure for each line, consisting of the text, debug info, and so on. It's up to the tokeniser to concatenate multi-line statements and strings. Most of that code is in there already, and hopefully it'll gel well with the new file reader output. I'll spend a couple of days getting it solid, though.

I should sleep. This is the problem with all-night coding sessions, which I love, and remind me of being young again. You either screw everything up, and have to give up and go to bed feeling totally despondent, or you get things working beautifully and then you're so happy you're too wired to sleep.

But I'm not doing any more coding for now: I don't want to break it!

4:10pm: Okay, I haven't updated for a while. Mainly 'cause I haven't really been doing anything.

I'm pretty much in research mode at the moment. I'm re-thinking a lot to do with the scripting system. Mainly wishing I'd given in and used lua like everyone else seems to.

But I want my own. Because I'm like that. Also, actually - currently considering what it would take to wrap the whole scripting system up as a portable kit outside of the engine. Maybe I can open-source it and have someone else debug it for me :P

So I'm doing a pretty big re-write, mainly with the following requirements: proper UNICODE support, pre-processing support for #define style replacements (probably not #include, though, since that would be a bit of a nightmare to handle and isn't really required), more robust and easily debuggable system, and better script error reporting. And other things.

I think I've finally given up and will implement a UNICODE *groan* reg-ex system for tokenising. As the script syntax gets more complicated it's becoming increasingly obvious this will save time in the end. Also, you know, I'm kinda realising that everyone else considers regex to be the foundation of any tokeniser/parser system. Maybe they're onto something.

I've also been working out how the VM and symbol table, etc. will work and fit together. It still makes sense to me. I think that's a good thing. I do need a good abstract tree container (for parse trees and expression trees), though, asap.

This is a big system and I'm starting to dislike it greatly - it has everything and nothing to do with making the game.

I've been writing up milestones, doing a GANTT chart (my favourite type of fiction), and I've been drafting some more of those programming 'lessons', though I'm not entirely sure why.

I'm also going over a lot of fundamental C++ stuff (both standard language and in Microsoft-land) to work out the 'correct' way to handle things like strings (why can I not bring myself to trust std::string?), as well as UNICODE, exception handling, memory management, run-time debugging, etc. etc. And I'm reading a tonne of silly Microsoft articles and looking through other people's code to see how they're doing things.

I've got so many lists of things to do I'm considering adding "consolidate things-to-do lists" to one of them. I need to collect everything together, put it in order, work out priorities, and get rid of things I did 6 months ago.

I got a Valentine's Day message today. From GarageGames. It said, "Happy Valentine's Day! If you don't have a special someone, find a special game." :)

But, I want both :P

And I've finally found Jeff Minter's lj page again. So I'm putting it here. Spent fricking ages looking for "hairyyak" or "woolyllama". He's "stinkygoat" :D

And good for him :)

4:35pm: First Programming Lesson - Numbers
Well, I'm not working on the ParseTree anymore... I've somehow managed to break the Tokeniser, which is the stage before the ParseTree. It's a one-off bug: the first letter of all my variable names disappears because it's indexed one more character into the file than it should. But damned if I can trace where it's happening, or what I did to deserve it.

So I've given up on programming for now. I'm going to deal with real-world stuff until dinner. Like write in my journal.

So, here's a lesson about computer fundamentals. I believe it makes a lot of sense to learn the fundamental ways in which the computer works, rather than using a bunch of mysterious magic boxes that will work (until something goes wrong and you need a much deeper knowledge of programming). The first, most fundamental thing is the different ways computers represent numbers.

Numbers

Introduction
There's 3 major ways integer numbers can be represented: binary (base 2), decimal (base 10), and hexadecimal (base 16).

They're all the same to the computer (just different representations of the same number), but it's very useful to be able to count with them and convert between them. You don't have to be an expert at it, it's just important to know how. When writing binary and decimal it's usual to have a prefix or suffix to denote which base you're talking about. Hence 00000001b is an 8-bit binary digit equilavent to decimal 1, and hexadecimal 0x01 or #01 (0x is standard for C++, # and % are standard for HTML).

Binary
Decimal is our native numeric system, but binary is the fundamental one for computers. It consists of two values: on or off, true or false, this and that. It can be one of only two possibilities. It's therefore a base-2 number, and is represented as 1 or 0.

Frequently the bits represent a value: 8-bit (byte), 16-bit (word). In that situation it is standard (though not required) to use leading zeroes. The right-most digit of a binary number is worth 1. Every digit preceding this is worth twice the amount of the previous digit. For an 8 bit number, therefore, the value columns are: 128, 64, 32, 16, 8, 4, 2, 1 (if all columns have a 1 in them the number is 255. This, along with zero, gives us 256 possible values for the 8-bit number.

As an example, let's say we have a binary value of 00101011 and want to convert it to decimal. Since we have 1's in the third column (worth 32), fifth column (worth 8) and in seventh and eigth columns (worth 2, and 1), we get the decimal number by adding those values: 32 + 8 + 2 + 1 = 43. It's much simpler than explained here once you get the hang of it.

To convert back from 43 we reverse the process. First we look at the power of two needed to store the first 1. 32 is too small, but it's less than 64 - therefore, we set the first digit (32 is the fifth digit from the right) to 1 and subtract 32 from the decimal number. This leaves us with 11. This is smaller than 16, so write a 0 in the 6th digit (16 column) . It's not smaller than 8, so store a 1 there and subtract 8, leaving 3. Repeat until the decimal number is 0. This leaves us with 00101011.

Decimal
Decimal, of course, is what you're familiar with: numbers where each digit is between 0 and 9. A byte (8 bits) can hold 256 possible values. Two bytes (16-bit) can hold 65,536 (=64K) values. And 4 bytes (32-bit) can count up to 4 gigabytes. This is where CPUs get their '-bit' status from: it's a multiple of 8, and represents the 'native' number of bytes the CPU operates on at a time. By operating on more than one byte at once, processing is faster. Also, since memory is addressed using the same number of bits, more bits means more memory can be addressed. Current CPUs are 64-bit, and work fastest with 8 bytes (64 bits) of data (known as a quad-word).

Hexadecimal
Hexadecimal is my favourite. It's base-16, which means you, um, run out of numbers after '9'. To represent 16 possible values, you count: 0123456789ABCDEF. Seeing all these letters in things like error codes is probably confusing for a lot of end-users.

The beauty of hex is that it always takes two digits to represent 8-bit numbers, 4 digits to represent 16-bit numbers, etc. It's kind of the human-readable version of binary. It's mainly used to express things like raw data, values and codes, and any number that has a maximum value or values of 255; The colours in HTML are a good example:

font color="#203f99"

#203f99 is a hexadecimal value for a colour with #20 red, #3f green, and #99 blue. In decimal that's 32, 63, 153. This is not much red, about a quarter full of green, and more than half full of blue (remember, the max for red, green, and blue values is 256 - a byte). By storing the 24-bit colour as a 3-byte, or 6-digit hex number it saves space and is more native to the computer. Frankly, in HTML, I don't know why they've bothered doing it that way. In other circumstances, though, it's essential to work with colours as they're used by the hardware, and that's when you need hex.

Quite apart from appications like that, understanding hex and binary will provide a real understanding of memory, variables and logic operators, which pretty much completes the theory needed for understanding programming fundamentals. Hex is what you look at when you're examining the 'machine code' that your program is converted to and which the PC then runs.

Summary
At one point in high school, back when I was coding the C64 every day in machine code, I'd do all my maths questions by converting the numbers into hex, doing the maths in that, and then converting them back into decimal. I'd become better at arithmetic in hex than decimal. My teachers disapproved of my working out.

New and Exciting Episodes Still to Come!

• Logic and Maths
  
• Memory and Variables
  
• Control Flow
  

I don't know that I explained that very well. Questions? Anyone? Anyone?

1:54pm: I'm re-writing the ParseTree at the moment. Having had chance to think through the code, and what it has to do, and what it will need to be able to do in future (and considering it's buggy), I'm just rewriting stuff to be more elegant.

The best solution to a programming problem is the 'elegant' one. This means different things for different programmers: small code, a clever and non-messy way around a tricky problem, whatever. For me the major factor is debugability (I don't know if that's a real word but, ick, I hope it never is - actually, I think they call it maintainability, oh dear). For me, the major factor in an elegant solution is that it's modular, flows neatly between modules and calls, seperates the code from the data, and is made up of discrete units which can be debugged independently.

Having said that, my ParseTree.cpp file, even after the re-write, will be over 1000 lines long. Sometimes it can't be helped.

Oh, I found what seems like a great and very accessible and comprehensive article on debugging computer programs over on Wikipedia. I've only skimmed it, but it looks very well done.

http://en.wikipedia.org/wiki/Debug

Since I spend at least 50% of my programming time debugging, I really should keep thinking of ways to minimise it. But I think I'm doing a lot of the right things.

Okay, going back to ParseTree re-writing now.

1:25pm: I'm going to spend another 2 weeks on the scripting system. I think it's worth it.

If I can get the script system tied into the rest of the engine by then it'll be awesome (and since we're using the GUI as the test case, it means making a lot of progress on the GUI too. Getting the executable side of scripts even half working by then would also be great - we're making a lot of progress on a nice Virtual Machine design.

I started coding again yesterday. There's a lot to do.

1. FileReader
1.1. Modify to allow multi-byte chars
1.2. Make array indices strings (avoid script limitations)
1.3. Make the line number token a WORD (allows 65,536 line scripts)

2. Tokeniser
2.1. Add control-flow and maths/logic keywords

3. ParseTree
3.1. Add control-flow and maths/logic keywords
3.2. Implement AliasList post-processing (better to do this inline?)

4. Memory Manager
4.1. Display leaks

5. Assembler
5.1. Convert "true" and "false" to 1 and 0
5.2. Expression table
5.3. Symbol table
5.4. Generate op-code stream
5.5. Write VM

6. Script
6.1. Allow access to symbol table
6.2. Re-write ParseTree value functions

7. GUI
7.1. Register constants, functions, classes
7.2. Streamline access to script
7.3. Display loaded GUI

Okay, that's quite a lot. But two weeks might get me well into it. My current bug is really annoying: the ParseTree is failing to read "-1", because it recognises '-' as the minus operator, not part of the number. Sometimes. It parses it fine for one file, and not for another. Bewildering.

This is always a good excuse to mess with the design and do code clean-up. Sometimes the problem just disappears. Yes, I'm an optimist.

My way of tackling a problem like this is a bit like building a bridge. You're translating a bunch of data A to a bunch of data B. You start by working out what you want the data (A) to look like, and then work out what you want the output to look like (B) once the code is done with it. So it's kind of alternating between designing top-down (A) and designing bottom-up (B). Then you just write the code to turn A into B. And like a real bridge designed by me, when the two finally reach each other, they don't actually join up.

But I can normally hack at it until they do work with each other, while still keeping it an elegant design.

Yes, I'm an optimist.

Edit: I'll be editing that list as I add and complete issues.

11:44am: Braindump for Today.
Still haven't done any coding. But I had a lovely night last night. It's nice to be with someone who just plain makes you happy; I don't think I realised quite how important that is. So I'm happy :)

I have been doing a lot of game thinking and stuff. I've been coming up with lots of ideas, and while it's not picture-perfect in my mind, it looks like it could be very cool and a lot of fun. The question, though, is whether other people will think the same!

I do admit to a major childish glee and "this-job-rocks" feeling when I'm prototyping script code like this:

instance CWeapon WeaponAK47 =
{
szName = "AK47"

nMuzzleVelocity = 710; // m/s
nDamage = 20;

array FiringModes[] = { FIRE_SINGLE, FIRE_BURST, FIRE_AUTOMATIC };
bGuided = false;
nFireStability = 100; // Accuracy
nStability = 80; // Flight stability
nRangeForStanding = 300; // Metres (Max range to hit stationary target)
nRangeForMovement = 200; // Metres (Max range to hit moving target)
RateOfFire = 600; // Rounds per minute (maximum)
};

It's like playing army men in the backyard, basically.

So, back on Earth... I'm going to flowchart exactly how the Script Engine VM fits into the scripting system. Then I'm going to analyse that and see how what changes the different components make, and also write a skeleton for the virtual machine. I'll set up a few test scripts with actual program code.... just stuff like:

// Global definition/assignment
a = 12;
b = 15;

// function
function TestStuff (a, b)
{
if (a > b) // Conditional
{
object.variable = a; // Object assignment: object is a script or internal type
}
bEnd = false; // Assignment
while (!bEnd) // Iteration
{
a++
if (a > b) bEnd = false;
}
return "Silly function"
};

So, C++ish, basically. God I wish I knew how to indent lines on this! Is there a HTML tag I've forgotten?

If we want to go a step further we can make the mods neccessary to the scripting system to at least read in the lines without freaking out. Getting the parse-tree working will be harder: we need to use it to build expression trees. Anyway, I've designed everything with all this in mind but that doesn't mean it will be exactly simple.

We need to work out what components that the script's virtual machine will have. The VM basically means writing a compiler as well as a 'pretend computer' - a software CPU for your own language. Maybe I should have factored in more time for this.

Okay. We need a stack. We need a stack pointer, and an instruction pointer. Do we need a symbol table?

The first thing the VM needs to do, at initialise time, is seperate the code from the data, and translate the code into opcodes.

You know, performance might be a real issue on the VM - we're going to have dozens of scripts running (up to) every frame. Let's go with an optimised design.

Okay, brain dump done for now. Gonna think more about the script VM and more fun game-design stuff. And do more tidying up. And maybe playing some games :)

4:54am: Alternative Plans
Okay, I haven't done any coding in the last couple of days (and won't tomorow either - cleaning up, 'cause Sam's coming round! :)). But I have been doing a lot of things.

At the moment we're considering leave the spripting system alone once it can support the bare essentials for config files and GUI definitions. What if instead we press on with that sub-system, and try to get proper functions happening in the script. This would allow things (like the GUI) to have associated logic with it (in that case, to control states and support future functionality. Doing so will delay the GUI development, but it might be possible

Oh, and yeah, yeah, I know. We need to do a full code review of the current specified scripting system whether we're going to work on it next or not. We also need to get that dreaded memory handling code working so we can track down all the memory leaks in the script system.

I've also been thinking about tech demos. Not really whizz-bang demo scene stuff, just small applications built with the game engine to show off particular graphical techniques and effects, etc. Of course, the best tech demos have a nice user interface - you can spin and zoom the model, move the camera, and change all sorts of things using GUI elements. So here's the best incentive yet to to work on the GUI asap.

The time frames scare me, it's too hard. I'm comfortable with 3 days for bedding down the current functionality. If I'm still in the mood, I'll do a more detailed sketch of how the system for running scripts will work.

The memory handler... just fucking hurts my brain. I think I almost understand half of it, but it's the most byzantine system. When dealing with very dark corners of the Windows code things get a little strange. Say a week.

The GUI system (not dependent on the error handler), involves a huger number of things. A game creates a CGUI object and sends it the name of a file to read.

CGUI *pMainMenuGUI = new CGUI;
pMainMenuGUI->Load ("test.script");

The CGUI calls the ScriptManager:

g_pScriptManager->LoadScript (pszFileName);

The Script Manager calls the script:

pScript->Load (pszFileName);

The heart of the CGUI class is a vector of type CGUIElement. This holds our list of child objects of the GUI, each represeting a particular GUI object.

A GUIElement can be many things, for example:

GUIELEMENT_BACKGROUND
GUIELEMENT_VIDEO
GUIELEMENT_IMAGE
GUIELEMENT_TEXT
GUIELEMENT_BUTTON
GUIELEMENT_CHECKBOX
GUIELEMENT_RADIOCONTROL
GUIELEMENT_SLIDER
GUIELEMENT_SCROLLBAR
GUIELEMENT_DROPDOWNBOX
GUIELEMENT_SCROLLLIST
GUIELEMENT_DIALOG
GUIELEMENT_EDITBOX

I'm sure I've missed a few.

Anyway, the upshot of it is that I'll have a GUI engine that reads in a script and uses it to set up a screen with a big array of widgety things. This will make things significantly easier in the long run. And this leads us back to the editor, and how we should prioritise the development with that. On the one hand, if there's no editor, there won't be any way to make levels, but if there is an editor, we can generate content much faster - and coupled with the tech demo idea we could have a lot of fun.

5:30am thoughts. Gah.

4:34pm: Microsoft
The bad:

This is really scary... I don't think I'll be getting Vista for a while. This is an analysis by Peter Gutmann at the University of Auckland.

A Cost Analysis of Windows Vista Content Protection

Like most people I've only really been concerned with the legal issues with DRM, never really looked into how Windows handles it. If this article is accurate then from a programmer's point of view it's also... just ridiculous. Vista will be wrapping up every little thing regarding the transmission and display/playback of 'protected?' movies and music. Using 128-bit encryption. And scanning every piece of hardware to make sure it's 'legitimate'.

That's ridiculous - it being 'legitimate' is based on Microsoft letting the device drivers for a particular bit of hardware work for Vista. This means that the device software and Vista need to meet in secret somewhere and make sure nothing funny is going on. This raises a lot of serious issues, in terms of ethics and technology. Among those is just how much a bitch it will be programming stuff with it.

I need to do more research, but this OPM ("Output Protected Manager") has its claws dug all the way into the Vista display and audio architecture.

No way am I porting to Vista any time soon, though I should learn the new systems and design so I know what to expect. But speaking of porting...

The good (and ugly):

Wouldn't it be nice to get some of this XBLA (XBox Live Arcade) action. A first game with relatively simple gameplay and short production-cycle (ha!) is perfect for selling on the XBox 360 at $5 a pop.

So we need to make our engine cross-platform with the XBox 360. Ouch. I should look into Microsoft's XNA (which doesn't seem to stand for anything) to see how much of that we want to use to make porting easier.

Even with Microsoft being friendly about it, XNA and a 360 dev kit does cost money, and XNA currently really only seems to be being used on the PC as an audio engine. But XNA does have XNA Build, which sounds like it could be a competent asset management system. For when all these great artists and sound designers start flocking to help we'll need a way to deal with all that stuff they're producing.

I had another thought, I'm sure of it..

Umm.

Oh, I had an idea for a screenplay. That was nice. I'm working on the project I'm doing for Sam... I feel awful. This is a lot more fun to make than it is to actually see the finished product! So, I'm doing it for me. But I'm doing it for me to do for Sam. So.

Yah :)

2:48pm: Depression
Nobody goes to a psychiatrist or therapist and asks them to make them happy. What they ask is, "Can you make me able to feel happy again?", "Can you make me feel like I deserve happiness?", "Can you make me want to be happy?". These people are generally genuinely depressed, and pills and/or therapy can help them. And I think there's a good case to be said for the real therapy only being able to begin once the depression has passed.

I think a lot of mental illness is influenced by the existing thinking patterns and decision making machines built into your head. A lot of these can be tuned badly - negative coping mechanisms, self-destructive behaviour (listening to Christina Aguilera, for example), anxiety etc.

These can be fixed through therapy by learning techniques to identify and challenge those problems. Examining what you're doing is the first step to changing it. Learning relaxation and meditation exercises is good mental health training. Can you imagine a time when schools would have mental health education alongside physical education? Hehehe.. hmm, that amuses me.

But this is perhaps the more pressing problem: after an episode of depression, 'stuff' lingers in your mind. If you think you're complete shit during 6 months of being horribly depressed, it seems reasonable that you'll have after-effects. Those thoughts, the memories of them, and most importantly, the ways of thinking which led to the negative beliefs, will kinda get stuck in your head in some latent form. Only to really jump in and play when the next episode hits.

The best time to attack these beliefs, and to build better defences against the chance and severity of another episode is really pretty quickly after the current episode has ended. While it's fresh in your mind, so to speak.

It would also be nice to have some therapy after a really big episode of depression that's cost you your friends, partner, job, money and, nearly, your life.

Errr.. this is 'original work', I don't know what other people have to say on the subject. Maybe I should look.

(no, I'm not feeling depressed... hmmm, will lj still let me post this?) :)

11:59am: Physics and AI
This game will make or break based on physics and AI. Yes, we need a 'competent' graphics system and renderer (and designed so it can be glorified in the future, of course). We need a lot of other systems to work, too.

But physics will make the game - it's the gameplay that counts, and physics goes a long way towards fun gameplay. We need realistic physics to handle the game objects. I've played a few helicopter flight-sims over the years, and they're remarkably difficult to pilot. We've come a long way since...

if (key = KEY_MOVE_RIGHT) then PlayerX = PlayerX + 1

... but too much is too much. The most important thing about a physics engine is whether it's fun to drive.

We're going to have a lot of stats for each game player's helicopter. A rough idea of the physics data needed for a helicopter is:

struct HelicopterModelData ApacheData;

Apache.Name = "Apache AH-64A"
Apache.nHP = 1000; // 'hitpoints' - it's a game, after all
Apache.nLength = 17.73; // Metres
Apache.nWidth = 14.63; // Metres
Apache.nHeight = 3.87; // Metres
Apache.nCrashSpeed = 365; // Kph (never operate above)
Apache.nMaxSpeed = 293; // Kph
Apache.nCruiseSpeed = 265; // Kph (what does this mean?)
Apache.nClimbRate = 12.7; // Metres per second
Apache.nMaxAltitude = 6400; // Metres
Apache.nPowerMass = 310; // Power/mass ratio (Watts per Kg)
Apache.Weapons = GUN_M230 | // 30 mm cannon, 1200 rounds
ROCKETS_FFAR | // Hydra70 FFARockets
MISSILES_HELLFIRE | // AGM-114 Hellfire (anti-tank)
MISSILES_STINGER | // AIM-92 Stinger (air-to-air)
MISSILES_SIDEWINDER; // AIM-9 Sidewinder (air-to-air)
Apache.Features = NIGHT_VISION;


And that's not nearly as many variables as we need - they're just the ones I could find out and don't need to make up. But this is the thing, it's all about interpretation. This is our physics engine so it doesn't need to use normal physics. Essentially, we tweak these values and the way that they're calculated until flying helicopters is really, really fun.

One combination I've considered for the graphics and physics engines is destructible buildings (or even deformable terrain meshes). Even thinking about how to make it work (both fitting it into everything, and the maths required) gives me the fear. But firing a rocket into a building which gets chunks blown out of it and then collpases will look very cool. Dropping a bomb on the terrain and leaving an actual crater and trashed buildings - also cool.

These are just examples of what we could do with that graphics functionality. We can just as easily have Puff the Magic Dragon dropping seeds which morph into mushrooms as they land and explode in a shower of daisies.

Here's an idea that could stall the coding demand and let asset production catch up. Is there a way to not need any assets? Can we write a cell-shader based renderer, so we can initially work on the game in cartoon style? God, what if we end up liking the cartoon one more than the actual production work? No, won't happen, will just let us keep on coding. Note: At some point 'aquire' people who make these mythical assets.

And the AI will also make the game - how clever the baddies are at attacking and running away and basically, being as alive as possible. We want bad guys who are challenging because they're clever and unpredictable, not because they've got 10,000 hit-points. It's just unsporting to shoot at something that's so stupid it's repeatedly banging its head against a wall when the exit is 2 metres to their left. Likewise, if you've got a wave of 8 helicopters attacking you at once, it's kinda fun when the last one or two turn tail and try to limp home (they'll never make it, haha!)

Again, this technology may also be used for non-violent ends.

The first game I wrote was "Puff the Magic Dragon", on a Toshiba MSX in Microsoft Basic. It had a 4Mhz Z80 processor, 256x192 in 16 colours. It also had 32 sprites - though only 4 per raster line. It sounds like they did something in hardware like coders later did with the C64's 8 hardware sprites. The MSX hardware maybe could only support 4 sprites but was able to display 32 by repositioning them as the raster beam moved down the screen.

Anyway. It was a platform game - you were Puff, a dragon, who jumped and spat fire (it didn't fly) from level to level and avoided bad guys (who just stood there) until you got to the top and walked through a door to the next level. Neither Puff nor the bad guys or anything had any animation. Puff would just slide across the platforms as you moved him. There were 7 levels all up. It wasn't really a very good game, though oddly enough my sister still remembers enjoying playing it. I think I was 12 when I wrote it, she'd have been 10.

Yay, 20+ years of experience. Fuck. I'm old.

11:43am: I just watched Buffy trip over her own truly impressive trail of drool.

It was hilarious. Kinda sad. But lots of hilarious.

She really didn't like the tablet we tried to give her. Even after mum crushed it up (trying to pop one down her throat... failed). Man, that is one cat who completely refuses to lose her dignity, even if it means spreading powdered-pill drool from one end of the house (and herself) to the other.

You go Buffy cat girl! Don't let those humans disrespect you.

11:04am: "Helicopter Game"
I've been thinking more about the game design.

Firstly, I need a real title: "Helicopter Game" is pretty silly.

But I've done a brain-dump of all the gameplay ideas I've had so far, and some of them look really fun. These are excerpts from the game design doc:

Game Synopsis

Helicopter Game is a 3D game played via a top-down view. The player pilots one of several types of helicopter. The camera is high above the helicopter, and movement is a combination of model rotation and screen scroll/rotation/scaling, so the helicopter 'tilts' in the direction it's going in. The model moves within a narrow part of the lower centre of the screen for effect - most movement will show as the ground below changing. The player flies over a map consisting of a home base (eg. a helicopter carrier off-shore) and a port city with industry and strategic targets amongst the civilian structures.

At the start of a mission you see your character run out of the crew quarters and into the helicopter (with others, for some missions). There are a number of mission types. Some missions are simply rocket-attack runs on enemy installations, or enemy helicopter interception (though jets are generally used by both sides, attack helicopters can play a role alongside them). There are also combat search and rescue missions where your transport helicopter lands to rescue hostages. There's also squad-based missions (both following and leading), escort missions for armour columns, recon missions for ground troops, etc.

Ideas

• Three types of helicopter: attack (eg. Apache), transport (eg. Blackhawk), recon (eg. Kiowa)
  
• Mission types: attack surface targets (personnel and armour, etc.), attack aerial targets, search and rescue, search and retrieve, recon/surveillance. We want missions where you're part of a squadron of helicopters as well as where you lead a squadron.
  
• Look at the performance and weapons capabilitity stats for various helicopters on Wikipedia and elsewhere. A 'universal weapons pylon' is mounted on both sides of most attack helicopters. These are capable of carrying combinations of air-to-air and air-to-ground missiles, rockets, and machine guns.
  
• Friendly commando's jump in and out of your helicopter to rescue aid workers. As you land, commandos rush out of the helicopter to the target building, weapons fire is heard, and they then rush back out to the helicopter with the prisoner(s). Alternatively, they use zip lines from a set height - this also allows them roof access to buildings. They will shoot at enemies in the street and cover the hostages. A Blackhawk has two side-mounted machine guns which are fired automatically by crew. With commandos on board, flying low over hostiles allows them to fire with their assault rifles.
  
• Bad guys will be running around the streets, and on the rooftops. They'll also be in vehicles, including pick-up trucks with machine guns and guys with rocket launchers. Guys on foot will have less powerful assault rifles and rocket launchers. Some will have stinger missiles. Jets (not often encountered) will have very accurate seeker missiles and be looking for the player. There will also be APCs and tanks. Both have machine gunners. APCs can have a guy with an RPG in the hatch. There are also boats, some of which are platforms for enemy fire, and some trying to ram your HQ ship while loaded with explosives (remote piloted, of course).
  
• Include day/night cycle. Allow weather.
  
• Everything else is still in the thinking stage.
  

That could be a really fun game. I really like the idea of day/night cycles and weather - this means you can play the same map (or different maps with the same basic textures) several times without getting too familiar with it. I'd say it ups the 'novelty' factor of each level by about 1.5. I'm also thinking of adding a night-vision mode (some sort of shader/filter) for helicopters with that capability.

I'd like the map to be between 10km and 20km square. This is a huge amount of data, so we need a way to stream maps into the system rather than loading/rendering in their entirety. This could be very tricky to do.

I see the look of the game as being pretty gritty and realistic, but that's basically just what I like to play, and the sort of game we eventually want to make with this.

However, there's nothing to stop us completely changing the look and feel to something colourful and cartoony, with a children's dragon to fly around rescuing stranded knights in peril. We have to decide whether to make a game that we want to play, or make a game that sells more. Programming-wise, this is very simple, but it would be a good idea to decide before we start creating production art and sound, etc!

Hmmm.

There's two incredibly large pieces of work there: one is getting the engine to the stage where it's capable of powering the game we want (still a long way away), and second is writing the actual game (haven't even started, but will also take a while). It's complicated even more by wanting to write a flexible engine that can extend what's needed for this game into later ones. This is a ridiculously big project for one person.

Hmmm.

12:56am: I'm doing a back-up of my main _Game folder.

It has over 98,500 files in it, occupying 10.5 GB. The vast majority of this is my library of third-party source code, documentation, and assets (images, audio, etc.) Probably 4% of the files are my own game.

I really hate using third-party code, because the costs of learning and understanding how their system works often takes longer than it would to write your own version. Sometimes I've miscalculated that 'longer' bit quite badly.

Anyway, since I am writing my own, it makes sense to look around and see how everyone else is doing it - am I on the right track? Is there a better way? - to see if there's a cheap and nasty version of their code you can implement quickly, or if there's an opportunity for a really cool object that encapsulates things nicely and gives you more flexibility and functionality than other people's versions.

I do hope to be using third-party libraries for things like audio (OpenAL), and I still want the option of a plug-and-play scripting language layer so we can swap in whole new third-party parsers. I don't know how feasible that will be.

In other news, it's 1:25am. I should go to bed soon, this is taking a bloody age to back up.

11:39am: I'm not a very good analytical programmer. But I'm very visual.

When I think of code - when I'm designing it or debugging it in my head, I see the data and functions as objects with beautiful shimmering colours. I'm the data, or I'm the program flow. I'm an integer or a CScript or the instruction pointer flying down curved tunnels with psychedelic walls, going from logic junction (rooms with different colours) to logic junction, knowing that I have to end up in a certain room. And if I hit a dead end or find myself in the wrong room I keep running it through in my head until I work out why the path is broken. The call stack is a bulging ball that grows bigger the deeper I step through execution.

I think I've read too much cyberpunk. It's fun, though.

10:37am: The final scripting engine...
Well, making slight progress.. still got a few logic bugs to fix, but I can feel it getting 'feature complete'.

Just so I don't forget, here's the list of things we need to do to make this a -real- scripting engine. As in, our next pass on the system, which we'll try to put off for as long as possible:

1. We're using BYTE based strings at the moment for all processing. We're also using tokens and info which is stored as byte values. This works for English if we arrange the tokens carefully around the character map, but other languages need either different character maps (2 bytes for UNICODE), or at least (for some European languages) the high-numbered accent characters... which are currently being used to represent tokens. We've also imposed ridiculous, primitive limits on ourselves: maximum of 255 items in an array, and max 255 line long script (particularly ridiculous, but we store the line number of each string as a byte in the output to the next pass for debugging help). So we need a better token system that properly seperates out tokens and data, and handles UNICODE strings. Gah.

2. Maybe we should re-write the whole thing using regular expressions? Will the new functionality significantly break the code? If so, might be worth looking at regexs again.

2. It doesn't have any execution ability! It's not able to -run- scripts right now, only to handle variable definitions. I've been thinking about the design, but it's not very clear. We'll need a new module with a VM (virtual machine). We'll need to covert all expressions etc. into opcodes for evaluation. We'll need a call-stack, and script functions, and 'seamless' access to other script functions and variables as well as engine internal ones. Call the main class CScriptVM? Then it sits next to the CParseTree and uses the input of that to create and run the program.

3. Integration: We need to register variables, functions, and so on with the engine. NOTE: Even to get this working well enough for GUI scripts could be trickier than we thought.

4. Parallel and persistent execution: we need to allow many scripts to run at once. This will involve timers (do we need priorities?) to work out how often to step the code. Each script will need it's own CScriptVM

// Implementation ideas...

szScriptName = "GameClient_Win32.cfg"

HRESULT hScript = pScriptManager->LoadScript (szScriptName);

pScriptManager->RegisterVar (hScript, "Display.nWidth", TOK_VAR_GENERIC, Type, pData);
pScriptManager->RegisterFunction (hScript, "OnMainMenuNew", OnMainMenuNew);
pScriptManager->RegisterClass (hScript, "CGUIElement", TYPE_GUIELEMENT, &pGUIElement);
pScriptManager->RegisterPointer (hScript, "MainMenuBackground", TYPE_GUIELEMENT, &pGUIElement);

(RegisterVar will handle generic variables, array, instance, and structure elements.)

pScriptManager->ExecuteFunction (hScript, "DoLoop", FLAGS);

(flags would be something like priorities, whether it's an internal or external function, etc.)

How do we handle pointers to different types? Types like CGUIElement are registered to the program at run-time.

Anyway, with any luck the over-engineering and design on the current version will make that annoying and tedious rather than completely impossible.

I've got chocolate.

11:31pm: Things to do tomorrow:

1. Work on PowerPoint project for Sam!
2. Work on code
3. Do some engine and game research (always more fun)
4. Read about Lex and Yacc

Things to do this week:

1. Get a tidying up schedule worked out and start that
2. Go to Erina (on Tuesday?)
3. Doctor's on Thursday

Blah blah :) I got Smiley a punching bag yesterday and told her about it today. She seems very happy :) I knew she wanted one, so that's her late Christmas present :)

As for programming, I'm either completely lost or very close to make it all click into place. At the moment the ParseTree is working out the structure of the files, but it's stopped actually storing variables - stores the variable name, but not what it's set to. But if I can fix that weirdness (it's to do with the new scoping system and conflict between pCurrentNode and the NodeScopeStack) without breaking anything else I may well have made a lot of progress. We still need to: free up the parsetree memory cleanly, implement aliases and the post-processing code, do a backup, then get rid of all the memory leaks, and do a final tidy up of the reader, tokeniser, and parser, but otherwise that's everything on the scripting system for now...

Maybe I should have gone with a 3rd party scripting system. Or at least learnt Lex and Yacc.