It’s been a long time.
Since a lot of things. Like blogging. Like knowing what is going on with my web presence. Like caring about it all.
What galvanised me was that my sites, all of them hosted in one place, started getting Google offside.
“Huh? What buffoonery is this?” I would ask myself as the emails flooded in.
Continue reading “Rebirth, Starting My Websites Over”
A Computer Game is Business Software.
A Computer Game is a system provided for the solving of a problem and the filling of a need.
Okay. It’s pretty obvious, so I’m not trying to be clever with those statements. Simple and clear.
However, most Computer Games are as far from Business Software as you can get staring into this rectangular magic looking glass view .. thingy.
Business Software has an interface which is very close to the database. Sure, we move from exact data representation on a form to transforming the data into a better User experience .. Browses and Tabs and Drop Down Lists are just the beginning. You’ve got Task Panels and Drag’N’Drop. You’ve got twenty billion Google Engineers slaving away on ease of Business Interface.
But it’s still close to the Database. And that’s fine.
The Game Interface is about as far away from the database as we can manage today.
Let’s backtrack a bit. The year is .. whatever year it was Bard’s Tale came out (1985). You had a couple of Window Frames, one being the main interface into the world. It was decidedly square. Of course, you had bit-pictures of monsters and blacksmiths which enabled our brains to imagine.
But still, it was a game. You couldn’t mistake it for an application which drove your boss’s Turbine Engine Simulation for Aeronautical Nerds.
Please substitute a bunch of games in here that expanded the Gaming Interface. Wolfenstein. Doom. Quake. Half-Life.
I’m going RPG here. It’s not a technical history article. It’s a opinion article based on the point I’m trying to get across.
Then along came Diablo (1997), and the interface jumped away. No longer was it NetHack and Angband with ascii characters. This was pure awesome. It transported things far beyond the business computer screen. Into a fantastical place where swords and scrolls dropped from scaly creatures whom you had just slain with spells of lightning and fire, with weapons of chaos and mayhem.
More games come every year which give us further .. Abstraction Reality, and less Actual Reality. Morrowind and then Oblivion for the RPG people. Let’s not forget the Bioware epics. Also a little game called Half-Life 2. And have you played WoW with some of the powerful and amazing UI Mods? Etc etc, blah blah blah. You’ve already thought of ten or twenty or a hundred other games.
Abstraction Reality is Developers giving us what we see, which is not what is. As we know, behind the evolving of the Game Interface are ones and zeros. Data. Tables and Structures and .. well, the stuff of true magic :). This is the Actual Reality.
From a Database-Modelling-Developer-Application-Person point of view, what separates the Computer Game from the Business Sofware is ..
.. Interaction with the Database. In a Game, the User has much less interaction with and effect on the Database. It is the Engine which manipulates the data. To varying degrees, obviously. And there are Business programs which wouldn’t be so far removed.
What I’m getting at here is that when you sit down to create a piece of Accounting Software, you think in terms of Data and User Interface. In a Game, it’s about Data, User Interface, and the Engine.
Data. User Interface. The Engine.
So what’s this post doing on a Clarion blog? Good question! I’m so glad you asked.
I’m going to set about creating a Backend Administration System for a simple RPG Database.
The Database is not going to be perfect. In fact, it will purposely leave big chunks of what actually should be in a Game Database out.
Plus, you have to leave room for my stupidity.
In the next post in this series, we’ll take a look at the RPG Database and deconstruct it a little. The third post will then go through in screenshots how we create the Clarion Dictionary (the place where all the Table references are kept). The fourth post will screenshot through the process of making the Application itself. And the last post will probably be a movie of it all. Maybe.
(2012) This post was written long before I had much game development experience. It’s more of a concept design, rather than actual reality. So really I was blowing a little smoke :)
Answer: Pretty much anything.
Like business applications, every RPG Game (Focusing on that particular genre) will have a different Database. Design, Technology, Feedback .. They all affect a Database.
This Database is simple, and quite incomplete.
Remember, the goal of this series is not to create a fully realised RPG Database. It’s to show how Clarion can be used in creating a Backend Administration app for said database.
Design Decisions (Random Intro Points):
Let’s start breaking up this puppy.
Object
| Object | |
| ID | |
| ParentType | “Area”, “Character”, .. |
| ParentID | |
| Position | Context on ParentType |
| Weight |
As mentioned, it’s the center. The sun. Around which the rest of the Game revolves.
The Object contains physical characteristics, models, meshes (in Child tables, not in the db above). Most of these integrate with the technical aspects of the Engine. I decided it was outside the scope of this discussion. Oh, also, I wasn’t smart enough to figure it out.
Of major importance is that an Object represents the physical instance of the Entity.
Of course, not all Objects are going to be in the Database. Some of them, probably a lot depending on game design, will be generated in-game.
The ParentType field links to what “Parent” it is under. Which is either the Character (Bags, Items in Character Slots) or Area.
Let’s take a look at the Area.
Area
| Area | |
| ID | |
| Name | |
| Description |
Imagine your favourite RPG. When you start the game, you start somewhere. This is, in our particular game, the Area. It’s a village; surrounding countryside; cave with evil goblins; cave with misunderstood goblins.
At the moment, it’s just that. A record that is parent to a bunch of Objects. Of course, you’d need size measurements for the Area. You’d need to know boundaries.
This game could have a big persistent world, full of many Areas, or Nodes. That’s up to the Engine.
Profile (Not Used)
| Profile | |
| ID | |
| Name |
The Profile table allows the Engine to know that you are “Stu Andrews” and that you have four “Player” Character records (attached to the Profile record).
A Barbarian Scholar, a Guitar Bard, and two Monkey Ninjas. They are all at different Levels, and they are all at different stages within the Game.
Obviously we don’t have the Profile table in the Backend Database. Unless we were going to have a default Profile record, which we’re not.
Player (Not Used)
| Player | |
| ID | |
| ProfileID | |
| CharacterID |
Quite an important table. I guess if you don’t have this one, the game is just a simulation.
The ProfileID field is what links the Player records to your Profile record in the Game.
Via the CharacterID field, this table tells the Engine which Character records are not controlled by it’s own Character Logic.
Obviously we don’t have the Player table in the Backend Database. Unless we were going to have a few Pre-Created Player records, which we’re not.
Character
| Character | |
| ID | |
| ObjectID | |
| ClassID | |
| FactionID |
The Character table has the most interaction within the Database after the Object. It’s what you will be dealing with when playing the Game (kind of).
A Character could be the Innkeeper. It could be You, or your mate “KillrAwesome”. It could be the Dragon at the end of the Golden Bricked Road.
All the technical aspects that the Engine needs to know about are found in the Character’s Object record.
What the Character has is Context. Character records can have Item records attached to them, via the Equipped table. They can have Stats, like Strength, Courage, Snoozing Skill, via the Statistic table. And Character records have DialogHistory, which tracks their Conversations. I deliberately didn’t link the DialogHistory to the Object table.
That is, we only record the History of the Character. Sure, any Object can have a Conversation with another Object, but I decided against recording all of these. Only the Character records have DialogHistory records. Actually, only Player Characters have DialogHistory records. Let’s not stress the Engine out too much.
The Character has a Class record and a Faction record.
It would be cool to have multiple Classes for a Character, mix and match them, but I haven’t had the time to work that out. From a Design point of view, and to try and understand how the Engine would do it.
Also, multiple Factions would be very cool (ala WoW), but for the moment, a Character can only have one Faction.
Of course, it’s pretty easy to change that. We have a CharacterFaction table to link them, and remove the FactionID in the Character table.
Faction
| Faction | |
| ID | |
| Name |
Faction records are what helps the Engine to figure out Action Context. Is the Character that the mouse is hovering above a Friend or Foe?
Class
| Class | |
| ID | |
| Name |
Well, we pretty much know what this is. This is where you set up the Barbarian Class, with Statistic records like STRENGTH = 25, AGILITY = 20, INTELLGENCE = 40. Right? Who says BarBar’s have to be dumb.
Item
| Item | |
| ID | |
| ObjectID | |
| Type | “Weapon”, “Armor”, “Container” |
| SubType | “Sword”, “Shield”, “Wand”, “Chest” |
The Item table is an obvious inclusion. Phat Loot. Plus, so much more.
It’s worth noting that an Item record can have a bunch of Statistic records attached. This allows you to give a Wand “+5 Fire Damage” in addition to “10 Damage”. It means a Shield could have “+10 Normal Armor”.
Statistic
| Statistic | |
| ID | |
| ParentType | “Item”, “Character”, “Class” |
| ParentID | |
| Type | “Skill”, “Attribute” |
| SubType | “Base”, “Add”, “Subtract” |
| Value |
This one wasn’t so straight-forward for me.
It was easy to figure out the parent attachments. Character. Item. Class.
Where things get difficult is visualising how the Engine is going to parse the Type/SubType/Value information.
Originally I just had Type and Value. But how do you tell the Engine that this Sword gives a +10 to the “Strength Of A Bear” Skill? And how do you give a Character, or a Class, the “Strength Of A Bear” Skill itself?
So the SubType field was introduced. I think it works. But you can probably make it better.
Animal, Building, Vehicle
| <Name> | |
| ID | |
| ObjectID |
Decided to lump the three of them together. Each of them are linked to the Object table. It’s just up the Engine to know what to do with them.
That is, what Pathing AI does this Sheep (Animal) have? What about this Cart, what will happen when it hits the Sheep (the Sheep will win, because Sheep have Wool, and Wool in this world is made of Adamantium, thus Sheep are Wolverine clones and conquer all). Ahem.
The Animal table is linked to the Equipped table. I suppose that, if the Engine allows you to destruct (or kill) Vehicles and Buildings that you could attach it to them also.
But specifically I was thinking about when a Player might shoot a Deer and want to skin it.
Equipped
| Equipped | |
| ID | |
| ParentType | “Character”, “Animal”, .. |
| ParentID | |
| Type | “Finger”, “Head”, “Eye”, “Belt”, .. |
This is where we put Item records on Characters (and other tables).
I imagine the Equipped table would be mostly filled in-game. So the Engine would create stuff for those Orcs over there at some stage, based on some game rules. Or you could hand-plant it all. Shudder.
However, especially for Player Character records, you would need to store these records. Also, for Characters with unique items.
DialogRoot
| Equipped | |
| ID | |
| ParentType | “Object”, “Area” |
| ParentID | |
| Type | “Quest”, “Conversation”, .. |
Okay, heading down the straight.
Dialog is a big deal. It’s far harder than I imagined, although some folk have obviously got it worked out.
Dialog is what an Object will Communicate. A Conversation is what two Objects have between each other, exchanging Dialog.
With that in mind, we have these structures. DialogRoot, DialogItem, DialogItemReq and DialogHistory.
The Type field of the DialogRoot table basically says to the Engine “This is a Quest Dialog”. The Engine then knows what to do in that context. At the moment I’ve only come up with the two Types (“Quest” and “Conversation), but there are no doubt more.
Instead of giving an ObjectID in the DialogRoot table, we have the Parent fields.
You want to be able to assign specific Dialog to a Quest-Giver, for example, but you also want the BarKeep to pull out some Dialog from a general Pool. So we have “Object” or “Area” as the parent, Area obviously being for the general pool.
DialogItem
| DialogItem | |
| ID | |
| DialogRootID | |
| ParentItemID | For the chaining together of Dialog Items. |
| Primary | So that you can have one Item in the Chain as a Primary. |
| ObjectID | |
| Action | “Shop”, “Request One”, “Request All”, “Give One”, “Give All” |
This is what the Player will interact with a fair bit.
“Hi there Xena! Would you like to see the hundreds of Weapons I somehow store about my person?”
That’s a DialogItem. It’s DialogRoot parent would be of Type=”Conversation”.
The ParentItemID field is so that a single Object can have more than a single Dialog Conversation with you.
This is especially important in Quest Dialogs. Most Quests will have at least two DialogItems records. After all, the Quest has be given and then completed.
An instance where this isn’t the case is where one Object gives the Quest and a different Object accepts the completion of the Quest.
The Primary field is a nifty little BYTE that tells the Engine to return to this DialogItem when, for example, the Player returns to the Innkeeper. It might not neccessarily be the first DialogItem record in order. You might want to have the initial Conversation start with “My you are one ugly warrior”, but then whenever the Player initiates Conversation with them, the Innkeeper would use a different DialogItem record. Something like “We serve Beer and Roast Beef. Also, we have Beer.” would be more appropriate.
The ObjectID field allows the Engine to put together Quests that span a bunch of Objects. Like a Scroll which initiates a Quest that has to talk to Mrs. MyHusbandIsMissing, then head out and find the Husband, talk to him, bring him back and then talk to Mrs. MyHusbandIsMissing to complete the Quest.
Finally, the “Action” field allows the Engine to know this is a Question, and if the Object having the Conversation gives Success (a “Yes” usually), then the Action is started.
For example, Xena walks up the Weapon Merchant, who asks the question above. It is of Action=”Shop”, so the Engine knows a) This is a question, so stick up “Yes” and “No”, and b) if “Yes” then open up the Shop interface.
DialogItemReq
| DialogItemReq | |
| ID | |
| DialogRootID | |
| DialogItemID | |
| ObjectID |
This table is how the Quests fit together.
If you have a Quest where the Player must find “The Staff Of Roast Chicken Cooking” and return it, the following would need to be entered:
We link to an Object, because sometimes a Quest might want more than an Item. It might want an Animal. It could want another Character.
And more, the Quest reward might be the choice between two Characters, or it might be to give you a Black, Red and Golden Dragon.
DialogHistory
| DialogHistory | |
| ID | |
| DialogRootID | |
| DialogItemID | |
| CharacterID |
This table tracks all the Conversations that a Character has. As mentioned above, for our purpose in this Series, we only care about the Player.
The DialogHistory table is a record of where the Player is in the Game. How far along the Main Quest are they? Did they solve that riddle about the Ten Sphinxes and a Muskrat? How many Trees of Ironwood have they chopped down?
CONCLUSION:
Phew!
If you managed to get through it all, you’ll see I barely scratched the surface of an RPG Database. Really, we only skimmed.
What is important is that we now have a simple framework with which to progress to the most important part of this Series. Clarion!
Until the next post (number three if my internal incrementor is working), Fare Thee Well, and May Your Mead Be Always Frothy!
A few weeks ago I put three or four nights worth into making a Snake game (in Clarion no less).
Along with the snake game, I stumbled over some larger concepts. Profiles, Games, Stats .. I’m gradually building a very simple statistics application that holds games within it.
Here’s the plan:
Of course, these are really simple elements. Trivial.
The point is to get complex pieces of functionality done within a simple system. In a simple and clean manner. Without hundreds of variables.
At least, that’s the plan at the moment. Might be different tomorrow.
From my last post, where i was devoid of any creativity, to stupid amounts of too much stuff.
It began with hanging out on the Gamedev mirc channel, as a lot of stuff does, when my interest was peaked about non-Clarion coding.
I downloaded and installed Visual C# Studio Express, along with XNA. Now, although there’s probably quite a lot of people who naysay XNA, but for me .. it’s gold. I like that it takes away a lot of the lame stuff (creating a window, directx, ..) .. and lets you get into action quickly. Now, this is coming from a guy who hasn’t programmed more than a half-baked hardly-started game or two.
Also, I’m becoming much more appreciative of GIMP, the GNU Manipulation Program. It’s good. Not as good as my trialling of Photoshop, but still .. it’s going to do me until i can afford Photoshop. Or maybe further than that. Depends how easy it becomes to churn out a comic or two. On the subject of comics, the next one is coming .. soon.
And finally, there’s Blender. I’ve raved about this puppy before, but now have spent some time learning the basics. It’s awesome. I’m gonna upload a little pong (really basic) game that was a tutorial for XNA. Blender took not long at all (minutes) to bash up a nice looking paddle and ball. Because it’s a modeller, it’s a lot easy to render something that looks like a ball than draw it (because i’m a newb .. ).
Looking forward to integrating Prototype and Rico into Dev Dawn. Should be able to clear up a lot of my lame ajax code and add some nice imaging. Although, am conscious of keeping the site lean.
‘Nuff for Now,
Two rather popular games (the franchises being very popular), Oblivion and Heroes 5 just had their first patches released.
I’ve been reading with interest the Ubisoft forums (the publishers of Heroes, Nival being the Developer), in the weeks since it was released.
Heroes 2 was the very first game I bought with my own money. $90 being the amount of money from a relative for my 21st birthday, if I recall correctly.
I’ve invested a lot of time into these games, 2, 3, 4, and now 5.
But that’s not what I’m rambling about today. It’s just building some kind of foundation.
It’s very informative to watch how both the Users and the Developers react to each other. The patch hasn’t been out for 24 hours yet, and already there are some people very annoyed on the forums. There are also people very thankful. And so far, the Developers haven’t said a word in reply. Which is good I think.
There are differences between the products we make and these. For one thing, we don’t make games (ohhhh man, what a dream life .. ha ha ha). But we still create software that will get into the hands of the User. They will still experience our creation, and most probably will have something to say about it.
To the patch.
With both games and business applications (and general applications, everything lumped in there), you would have to work hard at deciding what went into the first patch. If, that is, a patch was needed.
In my simple understanding, a patch has two distinct purposes. It has the ability to Fix Bugs, and Introduce New Bugs, ahem, I mean Add New Functionality.
As in the case of Heroes 5, deadlines being what they were, the wheels of commercial success driving onwards, you are going to release a buggy product. Buggy, and lacking in a full feature-set.
What do you put into your first patch?
I imagine it goes something like this ..
The Patch Discussion, Scene 1, Act 1
Head-Honcho, Non-Developer, Parent Publishing Company
– "Get the patch done."
Developer, Guy Who Started In The Biz With Wonderful Dreams, Currently Crushed In Spirit
– "Okay."
Gets the Development Team together.
Some are missing, presumed to have left the state, seeking actual life outside of the desk/chair scenario they’ve experienced for the last 2 years.
The rest are present, in body. Some have their eyes closed, Sleeping. Some, the lucky few, have their eyes open, Sleeping.
– "Okay team. We planned for this. We know what didn’t go in. We know what is going wrong."
This last statement is partially correct. The rabid user-fan-base of a community ferreted out at untold number of bugs and missing features.
– "We have to decide what goes into the first patch."
There are groans from the crowd/team.
A developer, who had recently lost a great deal of weight, having not eaten in 40 days, falls to the floor. He curls into a foetal position, puts his right thumb into his mouth, and starts cooing.
The Head Developer strives to ignore this, as two large men with White Coats (and Blue Hands, ha ha) appear to take the stricken Developer away.
– "I’ve put out some of the fires. The situation is as follows."
– "We don’t have to worry about Feature #1 (eg, the Map Editor) or Feature #2 (eg, the Random Map Generator) for a while."
There are a few feeble attempts at joy, a girl claps, and one fellow makes some kind of sound that possibly was a joyous shout of rapture. That, or a death-rattle.
– "Apart from that though, we’re in the crapper. Any ideas?"
Silence
Finis
It is never easy. This is the time when the dreams of creating something amazing would be tested. The long haul. The great ideas have already gone into the software, or they’ve been discarded by the roadside. And for those that build their dreams on these ideas, without factoring in reality, this would be a very hard learning curve.
I guess that’s why a lot of development never finishes. You don’t go in prepared. You can’t think on your feet. You don’t listen when people say it’s gonna get really, really, hard.
So I’m determined to understand that, in development, things will most definately get harder, before they get better. Or, that you can make things better, but it takes a lot of hard work.
To be ready.
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.
