Tuesday, December 30, 2008

Commencing work on 0.3

Work on version 0.2 is now officially over, the tag has already been created. We will start on 0.3 right away.

I am estimating that work on 0.3 will have fewer obstacles than 0.2 since we already nailed down the biggest problems. In fact, some of the features planned for this version were already implemented ahead of schedule.

We do not require additional programmers to complete 0.3 since our current skill set covers the whole range of features, in fact only three of us can get it all done in time. But we can, as always, benefit from more talents in speeding up work and having parallel teams working on different aspects and proofs of concepts (like 3D animations).

Saturday, December 20, 2008

Planning the 0.3 demo

As discussed swiftly in our previous meeting, we will be progressively developing a number of game versions, which are to be built with engine features as they come.

With the features available in 0.2 and some of the features yet to come in 0.3, we will create a generic I2B game to get off the ground. Yet to be named, this game will feature aspects of the popular asteroid series, along with our own. This first title will paint a useful picture that illustrates how we can develop the next title for I2B; based on improvement and inspiration.

Further discussions are to be made regarding engine versions 0.4; to make a final conclusion about what we want to present to the public then; something more geared towards our RPG concepts , Blakes modular ship (entity) designs and along with other features.

3D mesh support has been discussed and will be featured in future I2B releases

I am presently writing psuedo code for the I2B Asteroids game, seperated under the headings within the following diagram.

Tuesday, December 16, 2008

I2Black.com is born

Finally, we now have a domain of our own: I2Black.com please give it a warm welcome :)

Monday, December 15, 2008

Jpeg & PNG Showcase

For reference, I've posted examples of how different images appear using JPEG and PNG formats under different settings. For large scale animated sprites, such as rotating planets, it will be useful to have smaller files to reduce download sizes. Although people will always complain about download sizes and many other things; bandwidth costs money; times each download by the size of the game each month; we can at least help reduce the download size by using 256 color PNG or compressed JPEG images for large animations. Although 256 color PNGs obviously don't look good on images featuring many colors. We already know that there are different compression settings for images, just like with mp3 and ogg for music, but the images below reveal the results.

200x200 pixel image: Now obviously in the real case scenario, I am dealing with animations larger than 200 pixels, i've used this size for quick page loading. You can click the images to see the proper result. 50 fps is the target speed as discussed, not all kinds of animations will need 50 frames per second, it depends how entities animate, most have been exported at 20-30 fps; Even 1 fps for things like regular clocks.

1: 24bit PNG - 56kb (Internet Explorer 6 users might not see this correctly)












2: 256 color PNG - 24 kb












3. Jpeg 100% - 37 kb


4. Jpeg 50% - 11kb

Image Aliasing and Animation

I've made some changes to image rendering. Mip mapping is not required for a 2D game. It adds unnecessarily expensive overhead and was distorting images because image sizes were too large for graphics cards. So, I eliminated mip mapping and am now using linear filtering for images. I'm using the principle of divide-and-conquer to break an over sized image down into two or more textures, to which the frames of an animated image are then mapped. This is done in the class CImageData. This was quite a major change, so bugs may crop up yet, but I think it's an improvement over the distorted images and excessive processing required prior.

Small update on the Quicker-canvas. A fundamentalist/cultist and some explanation to accompany him.

Thursday, December 11, 2008

*...steps back Into The Black*

Hey all, Lotus suggested I come post on the blog to let everyone know that I would once again like to lend my time to the project. I don't have an abundance of it, but I do miss you guys and would like to start offering my help to the artistic side of things. :)

Ship Building GUI mockup



A quick mockup of part of the ship building GUI. Select level (levels can be named or renamed by double clicking on the text area), select the aspect (on the wheel) that you want to deal with.

I'm trying to think of a better term than "mobiles" for crew and passengers... actually, "Passengers" probably works. This because it isn't always just crew, but robots, willing passengers, and possibly intruders (parasitic space creatures?) or others.

I used the word "Objects" for items... ideally, we need four words that are about the same length. All of those terms will probably change, although structure may be a keeper.

Below the aspect wheel would be the tools for editing that aspect; I haven't figured out what all of them should be yet.



-There will be a "Selection" tool, for selecting pieces (or groups of fused pieces), or items. Clicking selects. Holding shift and clicking selects multiples, or dragging where there are no items creates a "lasso" selection.

Clicking, holding down, and dragging on a selected item attempts to move it. If the item is structure, this will also move all structure that is fused to it (on all layers), and all items that are installed on all of those pieces of structure. During structure editing, mobiles are also moved as if they are installed items.

If this is an item, it can only be moved if it is not installed onto structure.

-There will be an information button, which pops up a window about the selected item or piece, over the ship.

-There will almost certainly be some kind of "Grab and Place" tool, for removing things from the scene and putting them down elsewhere. This is like a cut and paste, and will be how an entire hull can be removed from one ship editing window and put in another to be fused in.

-There will also be a couple rotate buttons, one for clockwise, and one for counter-clockwise.

If a group of fused items, or an item, cannot exist where it is (due to being moved or rotated into a position) it appears as 50% transparent over top.


-There will be a "Install/Uninstall" tool, for fusing pieces together (in structure), or dismantling them, or installing and uninstalling items. The "Install/Uninstall" tool is more complicated, and has a drop-down selection next to it. This selection contains all possible install and uninstall options available for the selected piece.

Clicking and dragging from one piece to another breaks two fused pieces apart by the selected method. Clicking and dragging from one to another fuses two un-fused parts by the selected method. Clicking and not dragging fuses or un-fuses 'vertically' (down into the structure of the lower deck). A vertical fuse is indicated while editing by a white circle with an X in it.

Wednesday, December 10, 2008

Crew token mockup



This is a mockup of a crew token- the little symbols that show up on the ship decks to represent the NPC crew members.

The one in the top right corner is the largest that this ever appears in-game unless we allow zooming in beyond 100%. This is of course just a mockup, and the final will look better- I also plan to make smaller versions of this to trade out for use in zoomed-out states (because the current one isn't readable if one zooms out).


It contains several factors:

Alpha numeric title- to reference the particular crew member.

ECG, or heart beat monitor below the title- this will be animated- naturally, a flat-line is bad, too high frequency is bad (or indicates excitement/adrenaline)- where it is right now it alright.

Radiation exposure- this is very bad, one wants this bar to stay solid black, but this isn't always possible. This person has had a very nearly lethal dose of radiation, and will probably be very sick. Radiation has a delayed onset, so even a guaranteed lethal dose (beyond the halfway point) does not kill immediately, but several minutes later.

Integrity meter- this is the little gauge at the bottom center- high is good here, which means the body is in one piece. Where it is now indicates that the person is somewhat wounded, straight up would usually be highly wounded and incapacitated, to the left would be severely hurt- massive blood loss, crushed bones, etc. which need medical attention. Further to the left, opposite of where it is now, at the first tick or below, indicates impending death and need for urgent medical attention to prevent it. All of the way down indicates completely obliterated (beyond the help of medical technology).

Lung meter- to either side of the blood pressure- this is slightly animated, and indicates rapidity of breath (by the speed of animation) and the amount of oxygen the person is getting. A bit higher than where it is on the meter right now is good... this person is short of breath. When a person is holding his or her breath, it starts mostly full, and ticks down slowly.

Colour- that's what the outer-ring is for. Actual crew tokens will contain two distinct colours, and will be able to have colour themes applied to them to help identify crew members by colour as well as title.

Tuesday, December 9, 2008

Pushing out 0.2

The last engine/framwork feature reamining for 0.2 was completed successfully, that was the prototype filtering. With this filter we can have events that go like "If any entity of type Bullet hit any entity of type SmallRock, destroy both".

According to our milestones plan, only the scene editor is now remaining. According to Garrett, it is nearing completion.

Usually activity is slow during this month so we will spend the rest of it cleaning up code, fixing bugs, commenting the code better, and improving the documentation. We should tag the version right after Christmas and then we will start looking into version 0.3 which should conclude with around 70% of the single player game code written.

Monday, December 8, 2008

Art assets estimate

I just finished with a fairly comprehensive list of needed art assets for all of the ships and items players will generally interact with.

There are about 600 items on the list (some simple, some more complex).

They represent about 300 hours of artwork, and about 30 megs of in-game art assets (if we utilize channels properly- that's using one byte per pixel to store normal data, another to store colour [using a palette], and another to store alpha [alpha really doesn't *need* 256 levels, but the others can't take more compression than that]), and maybe as few as 15 megs after compression (there will be a fair amount of empty space in the files, averaging about 50%, the redundant data of which should be easily compressed).

This does not account for: GUI, Backdrops (planets and nebulae), particle effects, scenes, or profile images for characters.

The GUI, from what I've seen, can stand a lot of graphical compression for the final release (tiles for the redundant areas), and 50% of it should actually be able to re-use graphics that make up the ships (the background areas made up of plates and lattice from the ships- which will let us easily theme the GUI to match the ship automatically, if we so chose). A meg should be more than sufficient for the buttons, dials, and meters.

We should be able to find ways to systematically generate the background planets and nebulae based on compositing a few simpler images. Luckily, being background images which we probably won't need alpha on (if we use the right forms of colour channel addition when compositing the images) and which we won't need pristine clarity on, lossy compression like jpeg could be an option, bringing us down to, possibly, four megs with the release.

For backdrop scenes, likewise, we can probably compress them; although that all depends on how many we'll have.

With profile images for characters, if we do that, we'll probably want to use something like layering to swap out mustaches, monocles, hair do's, and clothing pieces. Will definitely need alpha there, if we did that, and more full colour depth with people, so any good compression is unlikely. Might be able to do it well with 30 megs.
On the other hand, if we didn't want to bother with customizable profile images (which we very well may not), we could get away with jpeg images at 15k a piece, and make a couple hundred of them for about three megs- which would all have a bit more character as hand drawn pictures (always nice), but would end up being more generically applied. Would be about... 400 hours of artwork.

Throw in a couple hundred hours (and a couple megs) of jpg scenes, and a conservative estimate (with the compression mentioned) would put the game at about 1,000 hours of artwork and 40 megs of graphics in the final release.

Any thoughts?

How big will all of the music and sound effects be?
How big will the needed libs and the code itself be?

I can only estimate on graphics, but it seems to me that a distribution of 100 megs could certainly be possible.

Brief synopsis


Before getting into finishing the demo, I want to write down a short statement about what it will include to encourage more ideas for it prior to producing it in full.

The demo will include 2 major parts.

The first part will include a simple spaceship game with some of the entities and skillsets proposed for the real game. The purpose of the game is based on my initial concept; which is for the player to collect special items located around the map on transport or contained; all done while avoiding enemies set to destroy them.


The second part provides scenes and links to the scenes showcasing individual glyphs and entity features currently completed in order for the viewer to be shown how much work has been done so far and how well it has been done considering this was created from scratch.

Currently I am progressing with the High Level Psuedo Code for the demo

Sunday, December 7, 2008

Progressing Further

Things are now going much faster now. With the major issues out of the way, I was able to finish about 14 more tasks in just two days.

Most notably we now have glyph events working. Here are a pair of examples of how to use the new events for a push button or check box:

Global.RegisterTrigger():EventID("MouseDown"), ActionID("Global.Echo"), ActionProperties({{"Text", "Mouse is Down"}})

Global.RegisterTrigger():EventID("MouseClicked"), ActionID("Global.Echo"), ActionProperties({{"Text", "Mouse is Clicked"}})

These events do not hold any data about who or why they were fired, but whatever information we need to pass we can add almost instantly via dynamic properties.

All that remains to reach the 0.2 milestone is finishing the Scene Editor and implementing the Prototypes filter. I will start work on the latter right away.

Saturday, December 6, 2008

Filtering once more

I finally finished the last bit remaining for registering triggers from the console, which is filtering.

Here is how the previous action would be written with a filter:

Global.RegisterTrigger():EventID("CollisionEvent"), ActionID("Global.Echo"), ActionProperties({{"Text", "Collision occurred"}}), Filters({ {"InstanceFilter", {{"InstanceID", "Radar2"}, {"FilterTarget", "Either"}}} })

This was the last major remaining task for version 0.2 and thanks to Khaled's work on the console and loads of efforts, it's out of the way now.

Wednesday, December 3, 2008

Registering Triggers from console

We finally got the RegisterTrigger action accessible from the console. The syntax is a bit complicated, here is an example of how a trigger that echos some text on collision would look like:

Global.RegisterTrigger():EventID("CollisionEvent"), ActionID("Global.Echo"), ActionProperties({{"Text", "Collision occurred"}})

To simplify the writing of such scripts, we will build a script generation tool that will allow scripts to be created visually.

Tuesday, December 2, 2008

Modular Ship Design Mockup



Based on ship tiles, with square and half-square (triangular) tile types.

Monday, December 1, 2008

Some Quickers


Okay, based on Blake's guild-ideas, I drew some Quickers. A mechaniac and a younger pilot. I'll add a third dude over there, and then move on to another canvas.