Process & Initiative

I’ve got to post this. Not enough yet for an article, maybe later.

I’ve been learning a valuable lessons lately. The art of interfaces and processes. Where to put process, when to push it into the interface, how to create said interface?

When I put a button on an update window, let’s say it’s called ‘Send Email’, that is a Process. The process is held within an update window. To reach it, the User has to enter through a browse, or some kind of searching functionality, which really is a browse anyway.

Why should the User have to enter the update window to send the email? Well, the biggest reason is because that particular record doesnt’ have an email address field filled in. True. Okay.

But that’s like ONCE. What about the infinite next-times when the User wants to send an email?

These thoughts are new, and not nearly fully-formed .. but they are on the right track i believe. Of course, kudos to the brain that pushed me down this road.

Anyway. So we need to think of a intuitive interface. Functionality that cuts out any uneccessary steps. The most immediate thought is to implement a right-click popup menu on the browse, if it’s not already there. You know the one .. windows uses them extensively. They’re pretty good value.

Right-click, choose ‘Send Email’, and Bling, up pops an email window.

Now, I’ve missed a reason in here. I think there’s more to the Process/Interface argument than just "let’s move it out of this child screen onto the parent screen", although that’s a pretty big nice reason. Having process on the parent screen would probably eliminate errors that occur in update screens. Would relieve the update screen from a lot of logic, having to worry about things.

The more I go down this rabbit hole, the more questions arise. This brain doesn’t have the power at the moment. Gotta sleep. So more later. Posting this should be enough to keep it alive. Will think some more.

States :: Journal #004

Not sure about these titles. They’re getting a little too generic for me. Changed the format a little.

Anyway.

Realised over the weekend that before I travel any further, I need to implement States within the foundational code. Nothing fancy, just your basic state machine understanding.

That is, in the context of this project. Each of the objects in the game will have a state. Actually, they’ll probably have more than one state type. An object can be moving AND dying.

So. The first thing was .. where to implement them? In the Object class, or in the children classes? It stands pretty clearly that it should be in the Object. And now that I’m typing it out, things become clearer.

My biggest concern was that certain objects don’t have the same states as others. The player can attack the enemy. But the enemy can’t attack the player, they can only attack the player’s base. The base can’t attack anyone. It is stationary throughout the entire game (at the moment).

But now, writing this out, it’s pretty obvious. I was restricting the design, which is a NO NO. I can restrict the code to cover all these eventualities .. that’s simple validation. But the objects themselves are where the state functionality needs to lie.

Of course, I might discover that the child classes do need their own state functionality. Time will tell.

I haven’t had a chance to implement this yet. Have been cleaning up a few blogs, doing other stuff. Hopefully soon.

First Game Project :: Journal #003

And now for the case of the missing Journal Entry. It’s the post below, I just forgot about the naming convention .. this is the post.

Anyway, on with the show.

So the project is progressing well. Ups and downs. My brain really has trouble with the simplest of physics stuff, but handles the database side pretty well. Have been having a ball going back to simple vector stuff, coordinate geometry, circle and pi equations .. it’s all learning, or re-learning as the case may be.

I’ve just realised I need to implement States. I know, should’ve been prelim stuff, but i guess we’re still in the prelim mode, so that’s okay. States for each Object. It will be a simple bunch of states to choose from, depending on the type of Object. Not sure about them yet, have to think it through more. It’s basically to say, "This object is moving", or "This object has hit something", or "This object is now rebirthing". That sort of thing.

I have simplified the design for the moment. I was getting too complicated, trying to have lots of different functionality, but just thinking that through was bogging down the project. So I cut it down to bare bones.

One current problem i’m waging war against, is that of the AI movements of the objects. There are a bunch of spheres in the gameworld that are homing in on one particular set of coordinates. There are some random numbers being thrown into the vectoring/movement coding .. but it’s pretty lame. And they home in particularly wierdly. Straight line to one of the axis, then straight to the focal object.

Anyway. Am rambling a little. Brain fried. Need some relax time.

Cheers,

Down The River

Have done away with the post naming for journaling the gaming project. Can’t have my imagination going to waste :).

I had some cool ideas today, in regards to making the gameplay simpler, more intuitive. What sparked these ideas was the discovery of a little gem called POV-Ray. This is an awesome little rendering machine that lets you get something out the door lickety-splick. Especially in my case where the project is mainly for learning purposes, and the graphics just need to be simple and pumped out quick, without having the learn the nuances of a big piece of software.

POV-Ray runs from files that are similar to c/c++. Which is cool. And my memory of the computer graphics course done at uni came back with a bang. The Left-Hand Coordinate System, setting the camera, making objects. This thing does it really quickly. You set the camera position, the point it’s looking at, add the objects, a little light, press G .. and BAM. It renders.

Very exciting.

In other news, I read this article today talking about how Microsoft is planning to release six versions of Windows Vista. Six! I guess the more products they package and push out the door the more dominance they will have. Heh. I can’t wait to see how this is done. The marketing especially. How they try and make it an easy choice for the buyer. Which one of these six fine ladies .. ha ha. Can’t Hardly Wait flashback.

Haven’t managed any further coding on the game project. States is still the next step.

Over and out.

You Have Been ID’d

I know why, long long ago, people created 4GL languages. Well, maybe not every reason. But this one MUST have been at the forefront.

To take care of File Structures. At least, that’s what I imagine the guys did with Clarion.

Tonight I implemented Unique ID fields across all my classes. It was an enlightening experience. I enjoyed it somewhat, but then … I only have a handful of classes, and this is my first time. I can imagine if you had a couple of hundred classes, many of the child classes, but needing their own Unique ID’s as well, it would quickly become a rather onorous task to write the functions to take care of the UID’s.

To achieve my goals, I wrote it out straight. That is, looped through the objects, assigned the local var xID, and then incremented said xID var. Easy. Simple. As said, there’s only a handful of classes .. well, really, it’s only a handful of objects to go through. There aren’t many objects within the game world.

That reminds me.

Last night I realised one important facet I’d forgotten about the basic design. The World class. A class that tracks every object that is within it. At the moment, my Game Object is that, but this, for any real project, is very impracticle.

But for the sake of my initial goals, I’m pressing on.

Demonstration Man

I’m no Wesley Snipes to Sly’s lame future man .. but today I learnt an amazing truth.

Okay, the start of that sentence made almost no sense :).

Anyway. Onto the meat.

Today the system i’ve been working on for the past 6ish months had it’s first demonstration. It was only three other people, and I didn’t even demonstrate it.

We got through perhaps 1/20th of the functionality, mostly just administration stuff.

Something incredible happened. I was taking notes, trying to absorb all that was being said, and the extra thoughts that were popping into my head. And as we debriefed afterwards, I realised .. these elements that before were cloudy and even misty, were now coalescing in my mind. The clarity of the greater and smaller visions was far clearer than ever before.

Part of this is because someone else was driving the program. Admittedly, 99% of the logic behind the program originated from this person, but he hasn’t seen it for a long time. Seeing his excitement when working out/remembering the power that lay in his creation was really cool. And that infection helped me to see what he was aiming for.

Moreover, just the simple fact that there were other bodies watching the program gave a little more to the experience. It’s why we’re hard-pressed to go without human contact. Because like steel on steel, we need to be sharpening each other’s minds. That’s what a demonstration gives. It’s like a whetstone to the battle axe.

For the rest of the day my brain was a-buzz. I slammed through the little (but important) bits of coding (functionality, UI, …) at an amazing rate. I had the zone baby. The Zone was mine, owned and fully realised.

I’m sure there will be days of slowness, definitely. And there will be days of greater headiness too (when I finish this next project, that’s gonna rock) .. but for now, this is now.

Cheers,

The First Game Project :: Journal #001

What follows is the journaling of my experiences developing the latest Dev Dawn Project.

Spent most of the last few days restructuring the classes. There was almost zero structure anyway, just hotch-potch code. Now there is a definate heirarchy within the classes, although still a long way to go.

However, what I take heart in is that I don’t have to design the greatest piece of software. There are specific goals for this project, and what I have to do is attain those, and then see what happens.

  • Initial Structure

    To begin with, on paper for me, I worked through the basis of the game.

    Firstly, I had to break out of imagining writing a game as if I were playing it. Very important. I have to break down to the foundation of the game mechanics, the design.

    What makes up a game? Well, there are menus, loading screens, introductions, credits, other modules … and the game itself.

    So the game, as a player thinks of it, cannot be the basis of the game code, so to speak.

    What then, was the structure. I’d already passed it.

    Like a house, you lay the foundation. So, my first class, from which everything else comes from, is the Foundation class.

    From here I control whether the user/player is in the menu, the game, watching credits … etc etc. The loading of games is here to, I think. Haven’t got there yet.

    • That’s another thing. My initial desire with this project was to show how Clarion can be used as a database for a game. Moreso, I wanted to amalgamate my experiences with Clarion with my love for gaming. Because as a project, there’s nothing more I have wanted to do than make a game.
    • And more every day, it becomes clear. Games are just more numbers being pushed around. You know what I’m saying. And their usually not hard numbers either (on the face). Look at Tetris, Pong, and the others from your early memories.

    So anyway. I have now a Foundation.

  • Moving On

    Each time I grasp some mechanic/truth about the code/c++/gameplay, I then tend to pull the wool over my eyes once more, stumbling around in the darkness. So in this project, I’m trying very hard to listen to that little voice that says, "Maybe that should be a child-class, an object of it’s own", or, "Maybe you should make that private, and then call a function to manipulate it".

    It’s hard not taking the lazy root. But that’s what this project is all about. Investigatory Journalism. Ha ha. I mean, it’s about learning and getting better.

    So I move on to what lies within the Foundation.

    This is what I’ve got so far.

    • The Game
    • Various Game Objects, the Player Character, the NPCs, …
    • The Menus
    • Functions to load the engine, start the game, end the game, …

    There are probably more, but I’m running low and need sleep.

There is a lot more I want to journal about this project. It’s pretty exciting. I added a right-click piece of functionality the other day, and it was awesome. I almost, almost, got sucked into pursuing that, and other little pieces of functionality, but my sensei’s words of wisdom beaten into my head (well, not beaten so much) ring true. Get the base right before the other fluff.

It’s a rule that stays true no matter how much you do. Because the little things, the fluff, is most of the time so much more attractive. Adding a right-click functionality doubles the user’s input (from the mouse). But for the purposes of getting the structure and intial goals realised, it was nothing. Especially because the functionality didn’t actually do anything important.

Anyway, babbling. Bedtime.