More Intro Work

Here is a screen of some work I’m doing on an EDI intro, this is only showing the 2D part, as the 3D portion is still a work in progress. But the intro consists of a nice cloud flythrough of some stormy weather.

Stock Photo Intro Work Update 1

So I just finished the initial stages of doing some stock photography for the intro, and below, you can see what I have worked on so far.

The first image, is made up of two images, both custom made. The first part is custom parchment made only using some techniques I’ve learned for making fairly realistic damaged paper. The second is also the second image and it actually just a type of rolling pin, with part of the parchment edited onto it. The rest is all color correction and proper shading, and it came out fairly well, although the final product may just become a 3D aspect, so this may be only used mainly as a reference, but the textures within will still be vital.

Hard At Work, Learning The Tools We Use

Punch in the face

Punch in the face

Punch in the face

Punch in the face

Punch in the face

sorry had to wake myself up out of the coma I put myself in by trying to install my own DAZ 3D directories…

and it still hasn’t worked, I’m going to go cry now….

Long Night

Well, me, Raymond, and another very talented artist, Andrea, were up to around midnight planning out a cinematic intro.

And I don’t care what anyone says, Harry Potter has me hooked on deceased wizards.

But anyhow, we have the basis of an intro planned, like how it will flow, the script is still yet to be done but, we made progress and that’s what counts.

I may post up process that personally will use for this intro, because I have some very unique tecniques planned for this intro, and I’d love to share them with the world.

I’m also very excited for the approaching Alpha stage, we’re working very hard on our PR material, trying to get it perfect. Because first impressions last forever.

Und have a nice day

Oh, and shout out to Xiled Gaming, if you actually took the time to check my link and read this, you’re the cool ones.

Well Hello Yellow

Hi there, you may or may not know who I am…

*hint go with the latter one….*

Well, I’m Mike, your friendly neighborhood artist, I’m here to help out with all the work that needs to be done at EDI! I’m also the only one capable of dealing with Raymond’s graphic needs and pickyness.

Just kidding…

of course

*not really*

But anyhow, I’ll be helping around the house make spectacular things come to life (within budget of course)

I’ll be posting around a lot because I’m a blog fanatic so, get used to me.

Mike the artist

out

Back on track

So the wedding was great, as well as the honeymoon, but now it’s back to business with home improvement projects and of course game development.

So where are we at?  I knew when we returned that Jacki would be starting in again on Static: Investigator Training and she would need the engine sooner rather than later.  Also art was still flowing in for Morning’s Wrath 2, and if I hoped to get it released this fall the engine needed to be done yesterday.

So I jumped into working on the engine straight away.

As previous entries outline, I discovered the major issue that called for a major change in the engine, and with this change would come added flexibility through the use of classes.  But on top of this major change I also felt it was time to slightly modify the workflow that would be used in the editor.

The previous ‘tab based’ system relied on multiple ‘editors’ which were responsible for editing ‘collections’ of objects and resources that belonged to the more major objects (Game, Room and Actor).  For instance, when you clicked on an actor, you could use the sound tab to add sound objects to that actor.  This all seems well and good but it meant that the process of adding sounds (and deleting sounds and copying and pasting sounds) was all performed through the sound editor.  This was a lot of functionality to have duplicated all around, considering in addition to sounds we have, scripts, items, videos, shapes, topics, animations, languages, effects, particle systems and who knows what else.

The old editor interface

My solution was to simply use a more detailed object tree; where as before the tree view only held major objects Game->Room->Actor; now, each of those objects would hold their sub-collections Videos, Items, Sounds, etc.  and each element (a single sound for instance) would be it’s own node in the tree view.

Using right-click context menus for adding, deleting, copying, pasting items became much more intuitive, and it also made it so that each editor only needed to edit a single object at a time.

In addition, the property grid, that was used for setting simple properties on the major objects, now performed the same functionality on the lesser sub-objects; anchor points on animations, category, loop, name on sounds.

So the end result was a more cohesive and efficient set-up.

The new editor interface

The editor is almost complete, I am in process of converting the existing editors to single-object editors; which is thankfully an easy process (I love removing functionality over adding it )

Once the editor is complete a small change will be needed to make the Win32 engine run the new build products, but after that both Static:IT and MW2 will be able to continue.

Not a lot of progress

Highly out of character for me, I haven’t been making much progress with fixing the engine/editor.  I did however resolve some of my issues with the split-state type arrangement in such a way that I feel it’s a good design now.

Currently I’m focused on the editor interface and how best to integrate the concept of classes, and the process of taking a class and declaring an instance from it.  I immediately though of two tree-views, one for classes and the other for instances, and using a simple drag drop system for the bulk of changes; this might work, but drag-drop in general tends to be a hidden feature, so it’s not always intuitive.  So, much like the first iteration of the editor I’m sure there will be a period of a lot of testing and prototyping to expose any pitfalls in a particular interface design.

Easier said than done

So implementation of the new ’symbol system’ is proving to be difficult.

The implementation reeks of bad design, for instance:

a Game symbol needs a map of named sound objects, which define each resource, loop flag and type (effect or music) for a sound.

Then a game instance, needs to have a map with the name names, with the playing flags, to denote of if sounds are playing or not.

Since there are two maps, there is a completely possible nature that there are missing keys, misspelled keys, or additional keys on the instance side.

This can only be managed by lots of code validating these scenarios, and it feels very artifical.

So… the problem still plagues me

Symbols

So it’s time to re-think the way our game data is authored and managed, to build a better system and increase flexibility and functionality.

Symbols. “What the heck is a symbol?”

Symbol: an arbitrary sign (written or printed) that has acquired a conventional significance

I stated before that as a game developer we don’t care about the thousands of tiny resources that go into our games (or at least we shouldn’t have to) what we do care about are high level game objects… you know like the main character.

Currently in the game editor you author instances, instances of rooms instances of actors, each instance is completely self contained, even if parts of it are identical to other instances.  The only parts that are shared are the resources, say the image frames used; this is a problem.

because we don’t uniquely name object instances in any predictable way, instances can also be created via script, and if you want to spawn 100 particles  you surely don’t want to have  a way to uniquely name them all.

However, instances all do have a unique ID, the have to, otherwise referencing them would be impossible, but this id is generated sequentially and has no lasting significance about an object.

Instead, in our new way of thinking we will define ‘Symbols’…

A symbol in our case is a named template, and each symbol has a basic type, as either a Game object, a Room object or an Actor object.  Each symbol holds constant data (the data depends on the symbol type) and the symbol acts as the template from which instances are created.

The big deal here is that each symbol is uniquely named by the developer, such as ‘Morning’, any number of instances can then be based on the Morning symbol, the Symbol data for Morning would have references to hash-named resources for animations and sounds and other such stuff.

Our new state data will be a collection of instance definitions, each of which will reference a symbol by name.  An actor instance perhaps with id 25 may reference symbol ‘Morning’ and so when the instance is realized, it will look for a symbol named ‘Morning’ to find it’s appropriate resource data, and that is the key.

Since if later a fix is made to the game, the editor will generate a new symbol file, all of the symbols with resource changes will have new references to differently named resource files, however the symbol name ‘Morning’ will remain constant, as such, previously saved states from an earlier version of the game, will be able to re-create themselves and this time they will take advantage of new changes.

Theoretically, authoring in the editor will be easier too; the process will now consist of authoring symbols, and then using a special section to create and arrange instances to form the initial state.

If you’ve been following along you will see that my original ideas stripped developer involved naming from files, only to have to add the same concept again, but this time to symbols; this seems a bit defeating but it is much better than simply relenting to naming files. Why? because of the quantities involved.  A common game may have 50 to 100 symbols, where the resources for such a game are likely in the thousands, I’d much rather figure out 100 names than 3,000 as would any sane person

State Redesign… Crap.

There is a reason why I have chosen to redesign my state (and by definition editor), rather than simply saying that patches invalidate saved games, and that is because I discovered a more elegant design for my state.

A core issue to my problem is that saved states are simply saving too much data, notably they are saving data which isn’t actually state.  This came from a want to make new game, save game and load game very similar, for simplicity.  As such for a game to be able to load a saved state and know all of what is in the game from that state file, the state file needs to be big.

Needlessly big, there is simply more data being saved for each save game than is necessary.  I did the right thing of course in separating resources from state, but that was because they were too big data-wise (not many people store the character images in each state) but, I’m committing the same sins, only with smaller sized elements.

“Example?” Here is a great example! I save the data for each actors’ animations (basically a big named grid of image file references), and because of this I can’t change this data in one place and have all previous saves make use of it, it is baked into each save.

So, it’s time to divide state a bit more.

When a set of state data is loaded it should request things, and the things it requests should be human-designed objects, with human designated names. Part of this mess is that state is currently requesting files whose names are based on the data in the files; the data in the file shouldn’t change the reference path.

However there are very good reasons for not making the developer name their resources by hand.

“Most game developers name their resources by hand. What’s the big deal?” Well it certainly is done and can be done, but it’s cumbersome work that shouldn’t exist.  Resource files are simply bundles of data, some of which are usually shared between more than one game object.  To avoid ambiguity each resource file must have a unique file path which the developer must choose; to insure sharing the developer must remember that such a file is already in the resources folder and use the exact name to reference that file.  Games have thousands of resource files, keeping track of these is the job for a computer not a human.

In selenite, resources are loaded into the editor from file, or clipboard, etc.  Once the data is imported an MD5 hash is computed for the file data, and this hash becomes the unique ID for the resource file.  If the exact file was loaded days or weeks ago it will show it already exists and a reference to the file is used.  Usage of the resource is determined by how it was added into the editor, perhaps the developer chose to load an image into an actor, this association is known, and the actor object knows it is using file 1a23b9c287d39e19c2fb98a3c.bin the developer can see it in the editor so the association is made.

Anyhow, back to state.  The problem is that the associations to these resource files were being saved as state information, and that is just bad.

Why? because within the course of a game an object never changes its resource references.  So those animation frames for an object will always be the same within the course of normal gameplay, thus this information should be sourced from a non-stated source.

There are 3 types of game objects in the Selenite system:

1. Game – contains information about the game world
2. Room – contains information for a particular room (or map) in the game
3. Actor – acts as an in-game element that lives in a room

For a given designed game there are many of these objects (with the exception of there only being one Game object) and they all contain elements of State and Non-State.

The resources they were designed to use are referenced by hash name, because it was irresponsible to save them in the actual state file due to size (and ideology).

Examples of some elements that change from one game to another, but shouldn’t be members of saved state.

Company Name
Game Name
Version Number
Images Used for UI
Sound Files for objects
Image Files of objects
Physics Shapes

Examples of data that are part of state.

Script Variables
Currently playing sounds
Currently Selected Actor
Current Room
Set of Rooms
Set of Actors
Position of each actor
Room each actor is in

We see here that we now have two separate groupings of data, data which doesn’t change, and data which is possible to change.

In this each game object is composed of two parts, it’s unchanging data and it’s changeable state.

When a game object instance is saved, only it’s changeable state is saved, because of this there must be a mechanism to reference the unchangeable state, so that when loaded later it will know the additional data.  Furthermore, the reference method used to know this data must not be subject to change unless by design, e.g. using a hash of the data as was done with resources isn’t possible, since the reference would surely change if the data was changed.

In my next post, I’ll talk about how we’re going to restructure our data to result in a model that was even more elegant than before, and give us lots of update flexibility and even smaller save states.