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.

Friday, November 28, 2008

Menu concept

The menu will transition in size to fit the number of menu items set by the script. Each menu item acts as a button or check box glyph. When the mouse rolls over an item; which looks like text; a mechanical thing surrounds the text. The animations will not be so slow that it becomes annoying after using the menus 100s of times. The top part is one of the early small frames; before it reaches the correct width. The bottom is a demo of the menu at size 4; the text shown is not quite how it will look in the engine.

Improved Explosions

Although only I have seen the explosions in full quality playback, I felt that there was room for improvement and started these new ones. These hardly look as good as when animated in full quality. A particle engine would handle the major particles within the sequence.

Friday, November 14, 2008

Widening our vision

Since some people complained that reading long posts in the narrow blog page was annoying. I decided to widen it up a bit. Let me know if you like it better now.

Monday, November 10, 2008

How much science should we pour in?

OK, I basically like the idea of adding a layer of realism to our game. In fact I was reading an article in GD Magazine a while ago and it was a call for developers not to underestimate their player's intelligence, basically when we are doing something unrealistic it should not seem that we "forgot about it" or "did not know" but rather that we decided to do it that way.

I also like the idea in freelancer where you get all those sort of strange items and technologies that you use right away (e.g. nanobots) without needing to know how or why they function, but you have a glossary that lists and explains everything in more detail for those interested.

Blake's idea of moving wormholes around sounds like it could add real gameplay value, if used correctly. Imagine placing wormholes in strategic areas to prevent enemies from coming through in the opposite direction. However, I do not think the player should be able to drop them on the fly. I like the fuel suggestions as well and using energy as backup for currency. But these do not make much difference in gameplay.

As far as details of attacks go, I do not think we should go so deep as to explain why a specific laser frequency is invalid at play time. But we can do it in the glossary to exapline why laser type X can not be stopped by shield Y. Some RPGs display a lot of details after each attack including rolls and chances, etc... which we could make optional if many people think that such info should be visible to the player. I for one do not care much about reading numbers while I'm playing... but then again, maybe that's because I'm a mathematician.

I feel that many of Blake's ideas can be implemented without requiring much complications of the gameplay (or development), if we focus on getting things done that do not conflict with the laws of physics and perhaps refer to the most striking of them in conversations between chrarcters:
"You know, my grandfather told me that diamonds were once regarded as a valuable gem."
"No way!"
"Seriously, he lived back on Earth."
"Ah, I see. So they were goverened by the restricted local supply and demand laws of their little planet. I wish I could see Earth one day."

I do not see anything technically different yet and unless we get a concrete design of how things would work if things are changed we won't have reasons to believe it would be any more difficult.

So if you, content guys, can work this out into one coherent updated design that you feel is better and will attract more players (without much work load), then go ahead and give it a shot.

Saturday, November 8, 2008

Response, tweaking of concepts, and core game play modes- XP and optional micro-management

First to Jason:

Copy, Open word (or whatever), Paste, Read. ;) Much easier on one's eyes. This one is long too.

To all:

Thanks for your comments, both of you- very useful feedback.

*fix* I figured out how to change the wormhole thing.

For one, it's just as viable to have the second worm hole collapse than to have both of them do so, which would prevent grieving- grievers would just lose their own wormholes.

Worm holes, as instantaneous transit, imply a time difference, and I've figured out a very simple way to achieve that and account for relativity in simultaneous space.

Basically, one part of space is the future, and one part of space is the past. You travel back in time through a worm hole to the part of space that is in the past.

Lets say a worm hole spans 500 light years. You travel through it instantly, reaching the other side in the past- 500 years in the past (due to the length of the worm hole). Then, to return, you have to travel using a warp drive, at a paltry light speed, and take 500 years to do it, arriving back in the present.

By explaining it in that way, it becomes more obvious why a worm hole cannot go back the way it just came (time paradox- you could travel back in time and affect your own past).

Anyway, as far as the game play is concerned, it provides an instant link between two places- there are advantages and disadvantages to each kind of transit- with a worm hole, it's fast, but you're limited to worm hole paths- where people put them, or where they were naturally- which cannot travel in any direction (only from the future into the past). With a warp drive, you have to stop and make detours around star systems and the like, but you can travel from wherever you like- no need to have a worm hole present.

"With the currency, why not go with the good ol' USAs approach of just saying money is worth what it is without any real backing"

That's governmental backing, which is quite unstable in a free market.

We could make wormholes natural and immovable things, but there should be some things that have particular value based on pragmatism. *control* of existing worm holes could even work- if it were the case that they just existed there, those who controlled the areas could charge a fare for people to pass through them.

"But it doesn't actually say that the four human-player factions fight “each other”, not quite sure where that came from. "

From the online PVP mode of game play. If the factions are not fighting, and all players are official members of the factions, then that kind of PVP mode in online play would not make sense.

"I think the ‘more intelligent’ players will agree that diamonds will not be worth much for the reasons you imply; but as for the rest, what will they say about diamonds not being worth much? Will they believe you?"


They will when they mine and ruin their drill bits on chunks of rough diamond. For their sake, we won't even need to call it diamond- we can just call it "dense carbon grit" to discourage them from picking it up and trying to sell it in ignorance. They may later discover that it is diamond, but only after long knowing it is comparatively worthless (and one of the worst hardships a miner can suffer).

We can create some other very cool and beautiful looking things of great value.

"I used the concept of records and guitars from being valuable in another of my futuristic game ideas,"

I like that. I think a bustling antique aspect to artifacts would be pretty cool.

"I wanted to pick a time for when people on earth, are likely start to inhabit space, do we think that it will take more than 70 years from now?"

It's not so much about inhabiting space as the massive social and political changes that would need to take place, and the migration of that kind of population.
Just as the railroad had to be built before "settlers" could conquer the Western interior of North America, there's a certain level of infrastructure one needs to have a level of true space civilization- The U.S.A. with her current boundaries wasn't settled as soon as we developed the steam engine.

"Is a simple attack and defense attribute really over-simplified to cause “Most scifi fans” to “drool”? "

I think maybe you misunderstood me; in my context, drooling was good. I mean that the details would make scifi fans drool (like people do when presented with good food).

"Either you aim for the hard core sci-fi fans or the casual; or try to cater to both with different modes, incentives and levels of detail."

I would tend towards the latter- catering to each by providing optional micromanagement, wherein the player can choose to micro-manage an area, or spend XP on good crew who will offer advice that can be taken by default.

That is, say you, as a player, really enjoy twinking out a ship with specific combinations of weapons and armor- and many people really enjoy power gaming these gritty details. You'd appreciate the details about different kinds of lasers, plasma weapons, armor, ballistics, and missiles. Because you enjoy doing that, you can spend your XP to recruit or level up an NPC crew member who specializes in navigation- that way you don't have to do it.

On the other hand, a player who loved navigating could spend XP on getting or leveling an NPC crew member as an arms and armor specialist, who would provide purchasing recommendations and outfit your ship(s) for you so you don't have to worry about it.

Say a player only likes flying around and shooting things- doesn't care about interstellar navigation, and doesn't want to bother about what kind of weapon or armor the ship has- well, that player spends XP on both kinds of NPCs, and focuses exclusively on flying around, shooting things, and gaining XP.

All of these players end up being equal.

The weapons fan divided his time between weapons and missions, gaining 500 XP, and spending it all on the navigator.

The navigation fan divided time between navigating and missions, gaining 500 XP, and spending it all on the weapons master.

The grinder who just likes to shoot things spent all of his time on missions, gaining 1,000XP, spending half on a navigator and half on a weapons master to have a ship equal in potency to the others'.

You could even be an all around person, spending 350 XP on two NPCs, and doing a bit of tweaking on each to get your ship up to snuff. More missions than either of the first two, but a bit less than the third person.

Optional micromanagement like that, where a player can focus on his or her favourite aspect of game play, I believe is the key to balance between detail and shallowness.

Regarding Really Long Posts >=| and the Current Debate

My eyes!! I don't quite think the narrowness of this blog was meant for posts this long.

Now, to the debate mostly between Chris and Blake. As a CS/Aero major, I'm definitely leaning towards the more scientific view of game making, in fact my first game of breakout ended up as a full on physics simulation, and not so much a game of breakout. I know how easy it is to get lost in the battle of fun and realism, and I've come to understand compromises must always be struck. This isn't to say fun and science are mutual, the first time I played Deus Ex, I spent hours tossing objects around in all its simulated physics glory, same with Half Life 2. The original Outpost sought to incorporate as much real and theoretical science as they could fit, it made the game an amazing and unique gem that was fun to play.

I share many of the same ideas Blake has mentioned, but also realize many cannot be implemented, and many should not be implemented, for the simple fact they would make the game less fun, and more frustrating. Various damages and armor types should be a given, c'mon even the old Warcraft had this with heavy, medium, and light armors that were effective and weak against various types of damage. This wouldn't be hard to add, just have classes of damage, ex. Explosive, Impact, Plasma, Laser, and Electrical. The armor types could be split into categories of active and passive, with emp, projectile, cooling, an energy dissipating system (Though, wouldn't the ship act as a Faraday cage, even with a taser type setup?), and an energy type force field as the active. Plating and reflective could be passive. Different weapons and shielding could combine various aspect of the different attributes, game testing and balancing could figure out the exact values that each of these stats will mean.

With the currency, why not go with the good ol' USAs approach of just saying money is worth what it is without any real backing, aka Credits, as most scifi games do. Since it is the future, and self contained systems and nanotech should around, make these upgrades for your ship. Make food production, water recycling, power generation, and even matter creation all components you can buy and upgrade. If you don't mind constantly stopping to buy food and water, no need for water filtering and agriculture. If you don't mind your power generation being vulnerable to attack but also being cheap, get big solar panels hanging off your ship. If you have spare energy and space on your ship, start producing or refining minerals and goods, though the equipment would be better suited to a space station, or a planet colony as the energy and space requirements will be very expensive, though perhaps something you can do while logged off.

There is plenty more to be said on this topic, but to avoid writing a really long post... nm, I'm already there, sorry for the long post. How do you make the blog display wider, because right now it's just vertical text. Also, the wormhole concept of moving and trading them seems like it'd be more work than it's worth, plus players would get angry when griefers start sacrificing their own wormholes to destroy other players' wormholes.

Regarding Blakes proposal; let's all post our opinions; and read each others fully. Here is mine

Nice ideas. The laser frequency information and the other details are handy, quite timely. I've learned something new this week. :) I’d like to see what everyone says about it as well, not just me. So members; please post your opinions of Blake’s ideas below; a lot of it pretty much questions the current direction for the game.

Nice symbols as well, but you seem more suited to science advisor & possibly the game designer really.
I agree with your most of comments, but we can only make them come alive if you document how things would work based on the questions I will ask latter. Of course you might not want to answer those questions, I understand that; but I can’t answer them for you either; since your ideas are not from me with my limited scientific knowledge and I am not yet sure how interpret such knowledge for our inexperienced co-workers and common players to understand.

Your ideas seem promising. I'm sure your ideas will prove realistic and appreciated by certain ones; I'm not certain about common youngsters understanding the details yet; but clarifications would be developed later I guess; granted, it will excite those matured and interested in science, I'd say you are very intelligent and intelligent players will like your games. I hope you stay around to see the development through in order to enjoy the results. Your judgment will be the guide for your suggestions.

Only minor error; I’m not sure if you read the game document fully; I would understand, as it is not finished, I don’t get a single chance to focus on it. But it doesn't actually say that the four human-player factions fight “each other”, not quite sure where that came from. But apart from that your points are interesting; here are my opinions of yours;

I will try my best to back my statements here with successful game examples; as it is a game we are creating. If that is not possible, then I will illustrate through similar mediums.

I like your concept of having different attack types; this is the case in World of Warcraft and Command and Conquer; I originally left this detail out because those games don't have crew specialists under complex management. Attack types would certainly be more realistic.

All your statements about the ore I acknowledge; things like diamonds will not be worth much in such a scenario with expanded access, technology and resources. I saw that a Star Wars film used a spacecraft made of gold to depict the wealth of certain characters (I think it was in episode 3, before Vader is KO’d by Obi-Wan Kenobi); because ordinary people of today understand gold to be valuable. You agreed dense metals would be somewhat valuable.

I think the ‘more intelligent’ players will agree that diamonds will not be worth much for the reasons you imply; but as for the rest, what will they say about diamonds not being worth much? Will they believe you? I believe you, and know that you are right, but not all the players will; and they will post up some strong comments about what they do believe, on our future website.

Example: I imagine a poor character begging with the aim of exchanging a pile of diamonds for a bite to eat, and a rich guy replies ‘No, sorry, not worth much; not enough for even a bite’ Anyway, you said certain “things can be converted into human food”; so that story scenario probably wouldn’t exist in your concept; and should not.

Diamonds are beautiful stones, guys love them, women love them, and the amount years they took to crystallize from unimpressive materials, amazing. Thinking about an example; I don’ t think the cars in iRobot are worth much in that story as crate full of diamonds with your point; but the audience loves seeing them how they look, they look ‘cool’.

It is down to the audience, and what they see as ‘valuable’. And they will see diamonds as in-valuable in the future if they know about them. We must be sure that there are many who will play and will understand what we present to them.
I’d understand if diamonds are left out. And I agree with the point about things you can’t synthesize being valuable (I used the concept of records and guitars from being valuable in another of my futuristic game ideas). I acknowledge the point about water being recycled.

I’m not a fan of detailed realism in games of any genre; my top 10 games of all time are not much realistic with game-play details. (None of my top 10 sci-fi movies, cartoons or comics features much realism with weapons and objects either)
I think realism has a negative impact on game-play if not implemented well. Particularly for casual gamers who are a large group. We are dealing with long periods of time and focus in development and testing; but I can only say that, I can’t show you that; you have to experience such development and results for yourself. I feel the articles below highlight what to expect from realism, and what kind of audience to expect. (This comment is not about realistic graphics). Baring in mind we are making a 2D engine based game now (with 3D rendered images), are a small team (at present) and are limited with time and I acknowledge that many of my ideas are not realistic, and needed brushing up and much more focus.

Also; I agree that a game that is in no-way realistic is just immature.
These articles pretty much discuss further issues of going for the realistic & logical game. The second one concludes with a comment such details as being unnecessary.
gamasutra . gamedev

About Clifford Macintosh; Apple, they probably would get upset, which is pretty sad and pathetic considering the size of their company and our small group; anything for money.

The Clones, yes this is definitely cliché and definitely a placeholder name.
Regarding the comment; “Another problem with this is that is makes the player very small in comparison to the faction. If you've ever read Dune, the great houses are a good example of conflicting factions in which a player would seem to matter more. I think gameplay as a privateer with the option to join some sort of house or company would be most appealing. With missions one can take from various places”
I think the area of player role is simply not developed yet, pretty much because different ideas for the role keep getting proposed by different people into the game document. It does not yet go into details regarding the player’s specific role in the factions or their missions. The players certainly do start of small in comparison to the faction; and were going to develop into generals or leaders. Valid point.

I always disagreed with time setting which was earlier than 2104 before you came. You say we should add another 100; say maybe 2200 (2204).
I think to myself, what was life like 100 years ago? No spaceships, computers; no electric toothbrushes, not even an electric calculator invented 40 years or more ago. What will life be like around in 2104? I wanted to pick a time for when people on earth, are likely start to inhabit space, do we think that it will take more than 70 years from now? (at the approximate start of the back-history)
I heard of personal private space flight trips FOUR YEARS AGO lol; will we still be thinking about whether to go out into space over 70 years from now? http://news.bbc.co.uk/2/hi/science/nature/3811881.stm .

Technology does advance quickly, 15 years ago I was amazed at playing a 32bit game; now they don’t even bother to talk about bits. Other technology has advanced pretty rapidly.
As the one who is studying science, your judgment would be more accurate than mine on judging when living in space will be possible. 2200 it is then.

There are some game play and story related parts I'm not sure about; but my opinion doesn't matter if the majority disagree with me; It is interesting that there is so much that seems wrong about the game-play aspect of the current plan (for which me and two previous members are responsible for); but it is also a benefit for me to understand someone else’s point of view:

Is a simple attack and defense attribute really over-simplified to cause “Most scifi fans” to “drool”? I ask because those attributes are a sum of the effect the crew members have on a playing unit (Spacecraft / foot army); Similar to ‘level’ being the sum of experience points. An example: Strength skill in Civilization 4; a summary of more detailed skill attributes which includes unit circumstance (that's right, the best, one of the largest, one of the most successful commercial budget turn based strategy game over the past few years has ONE combat skill, which is a sum of further attributes and circumstance) and let me tell you; that's the one of the most challenging games I have ever played; check out the numerous comments on www.civfanatics.com.

On that basis, I severely doubt; if anyone who feels that simplified attack and defense attributes that summarize numerous underlining attributes for clarity is not good considering the list of other attributes (within the crew’s personal attributes in our case), will never enjoy the games I enjoy, or like any game idea I come up with.

A good illustration is RPG character level; imagine the case of forming a strategy; ‘Level 14’ is easier to read, express and estimate in the mind than Experience Points 1,203,211; which Level 14 represents. (Only the game developers would know the logarithm formular between levels, the players are interested in the single or two digit figure). Imagine performing a math sum in your head whilst manually shooting AI and saying to your RPG game team mate; ‘Oh, I have 1,203,211 experience points, only 296,789 experience points to go’, no way; a smaller sum is far easier to express; and use for expressions. Attack and defense is there for a similar purpose, and the game document talks about the crew member’s affect on those two sums. Some details are yet to be added for obvious reasons.
We had in mind that many GREAT games are not so realistic with the action and interaction; like:

WoW: Magic?, smelt ore with your hands?

Civillization: One scientist can research anything, bullets can destroy a tank, a warrior with a sword can destroy a tank, the game has one class of laser; no frequency differences

Counter Strike: Players can shoot straight at long distances even though their arm was partially exploded by a grenade. A character can climb a ladder, shoot straight and reload in less than a few seconds, with their heart busted open with a bullet

Command and Conqueror: One class of laser again; the weapons are just prefixed with the word ‘Laser’, with no frequency ranges even considered. They have a laser that beems down from a satellite dish and zaps tanks and buildings via remote control. One faction can dig a tunnel from one island to another in matter of seconds.

Star Wars: Need I say more; who cares how the light sabers work

So if our game is to be geared towards being like them, successful? It would not contain much realism would it? (Is it to be a fantasy? Science; fiction?). As for emotion and other areas affected by realism and the time spent on it; will the result under these working conditions be good? We (the previous writers, game designer and myself) just assumed most players will not care how the lasers work; it won’t affect their purchasing decision, they would predominantly only care that it takes damage, and how much damage the weapon takes; we just felt that many players are just interested in the fun and enchanting story in our case, not realism in the Sci-Fi Role Playing game's game-play. A judgment based on the top rated games listed, how far do we take realism in game-play based on following the examples of industry trained game developers? Or do we ignore this?:



But that is not to say, that realism in game-play is entirely wrong, or possible! Flight Sim is realistic; but that is no Science Fiction RPG. I’m just trying to imagine how realism in a space flight crew management role playing system will be received by the majority. Regarding majority of the gaming community we expect to play, based on their influence on the top games mentioned; do they care how the 40 pixel squared laser cannons work? I’m not too sure about that. That might make a nice poll.

We are not competing against the likes of those games considering we are a small group; but do we expect people to enjoy our game for long if it has more emphasis on logic and reason than any of those aforementioned games, and the chart games in those lists? I’m not too sure about that either.

Probably, I’m getting the wrong impression from the emphasis on laser frequencies; granted it will be cool to have laser frequencies, just not sure if the complexity of making an online RPG is being considered before focusing on such details.
Either you aim for the hard core sci-fi fans or the casual; or try to cater to both with different modes, incentives and levels of detail. I don’t get the impression your advice considers common gamers, the majority of games players and youngsters who buy indie games. Only the smart, which is fine; just not what I and the previous guys where aiming for.

But people will disagree with what I say here; we all have different perspectives, it is just the way it is; some people care for logical explanations for science-fiction weapons, some just care for the action. Some people buy a game because it looks nice, or because it has many weapons in it, perhaps because it has different laser frequencies featured in it; I’m certain I wouldn’t buy a Sci-Fi RPG because it has logical weapons; and shouldn’t try to make something I wouldn’t play.
Thinking about games like Worms, Star Wars, City of Heroes, Starcraft, Command And Conquer, WoW, Quake, Guild Wars, Dune, Unreal and Doom; However different, they share similar instances of unrealistic weapons and items.

Funny experience; I’ve played a game based in the near future with Rail Guns that shoot through a brick walls, without scratching a single brick or the wall paper on it, no smoke or nothing and yet the human target gets the beam shot through them, burns them I think and then bleeds them as they die. Imagine working on a project like that for months and months, ‘hmmm; shooting through walls, not very realistic; we need to find a more logical solution’; that Red Faction game was a decent hit, it got released on PS2 because of its reasonable PC success, eventually. I can’t stand the game, but not because it is un-realistic.

That’s all I will say from now. It will be great seeing it all work out.

If the majority agrees with your direction and if you are up for the challenge of helping us make your advice take place; please explains how it works in the game, what the player sees (taking your time). The answers to these questions will sum up how the ideas will work and will be a good start towards making them happen.
Explain the attack types and how it all works within a 2d engine between players playing online and with the AI, what kind graphical content is needed to illustrate the ideas presented, how the different attacks and maneuvers work & what buttons are used. How modelers can get an understanding of how realistic planets, substances, effects, weapons, robots look like and animate so things match up with the scientific guidelines. Or does it matter there? Try to provide details on who the player represents and what factions exist if the current seem undesirable, who the main characters are, the minor character types, antagonists and protagonists; when we should include the main characters, how linear the missions are, and how many should exist, and how they challenge the player etc, how devices affect targets with different attacks and defenses as you outlined, how many different devices and weapons would exist (eventually). Let us know how damage is calculated based on different attacks, how damage is calculated based on items and crew members (if they would make an affect), how buffs and de-buffs work (if they exist); this determines how the XML specifications will be set up. Let us how the GUI controls the different attack types; and if manual and automatic fire input is still going to fit in, how missions are played, what missions consist of, how players interact, how information is presented to the players regarding things like laser frequencies, governmental stocks, energy sources, waste-to-food conversion and other issues you present Also; how logical details affect how all the special effects look as currently, imagination is being used.

All this will be of great assistance when producing the content and designing the XML entities and classes; we on the creative team would then know how to make it happen. I’d help if necessary, but relate with the proposed level of detail. What ever else the programmers would need to know would be proposed by them.
Meanwhile hopefully others will comment and not just leave me to give an opinion; then will make our minds up on what to include and what not; then commence with the development of the content for the demo. Unwanted elements and ideas can remain in that to simply attract attention to the website and the real game being developed.

Have a nice evening, thanks for the input.

Wednesday, November 5, 2008

Lasers and optical shielding

This diagram demonstrates the spectrum of a possible laser (all lasers differ in spectrum) and an example of optical hull plating.

The properties as related to light- laser weapons, scanners, and visibility- are expressed by this diagram.

REFLECTION property quality:
PQ "Diffusion", floating point, % percentile

0 = no diffusion, 0%. A laser beam of Z wavelength that hits a hull with 100% reflection of Z wavelength and 0% diffusion is reflected off the hull at full strength at the angle of incident (this beam can hit other ships that are located in the path of this angle)

1 = full diffusion, 100%. A laser beam of Z wavelength that hits a hull with 100% reflection of Z wavelength and 100% diffusion is diffused as a flash of light on the hull, and does not remain coherent, and can not hit another ship.

RETROREFLECTION property quality:
PQ "Angle", floating point, radians

0 = direct retroreflection, 0 r. A laser beam of Z wavelength that hits a hull with 100% retroreflection of Z wavelength and 0 r angle is retroreflected off the hull at full strength at the source of the beam (this beam will hit the laser it came out of, amplifying the beam and eventually overheating the laser)

0.5 = indirect retroflection, 0.5 pi r. A laser beam of Z wavelength that hits a hull with 100% retroreflection of Z wavelength and 0.5 pi r angle is retroreflected off the hull at full strength at a random angle within a con of 0.5 pi radians (this beam may hit the ship it came from, or may miss, possibly hitting another ship)

1 = very indirect retroflection, pi r. Same as above, but at a larger angle.

DIFFRACTION property quality:
PQ "attenuation", floating point, % percentile

0 = perfect propagation, 0% loss. A laser beam of Z wavelength that hits a hull with 100% diffraction of Z wavelength and 0% attenuation is bent around the ship, continuing out the other side of the ship (effectively passing through without doing any damage to the ship). The beam may continiue to hit another ship. With 0% attenuation of a visible colour, the ship's colour chanel is removed (for example, if there is 0% attentuation of red on an otherwise yellow ship, the ship would appear green and transparent to red light- a red star behind the ship would shine through). With 50% attenuation of all visible colours, the ship would be 50% transparent.

1 = complete attenuation, 100% loss. A laser beam of Z wavelength that hits a hull with 100% diffraction of Z wavelength and 100% attenuation is refracted in the hull, and scattered away. The beam can not continue on to do damage, but when it hits it makes the entire ship seem to light up slightly in the colour of the beam. A ship with complete diffraction of visible light and 100% attentuation merely looks like a fuzzy blob of whatever colour light is hitting it (in space, probably rather dark, but not invisible).

Most mirror shielding, in order to be effective, must also be equipped with cooling to prevent it from melting under intense laser assault (no mirror is perfect).

Hull cooling properties, which can be added under a reflection, retroreflection, or diffraction property, will be discussed later.

Commentary on design doc and preliminary science writing

2104 is far too early for anything approaching a galactic

stretch. At least a hundred years should be pinned on; probably a bit more.

A clone army is a bit cliche, and, functionally, extremely

weak. Clones, having identical DNA and immune systems, are

highly vulnerable to specialized biological weapons- it would

be simple to wipe out a large population given identical

genetics and very similar conditions of living.

Clones- not all they're cracked up to be.

Dr. Clifford Macintosh? I think a different last name would be a good call, given the prominent company.

The four factions are all basically high end governmental

bodies- why are they fighting each other? It's a little confusing.

Another problem with this is that is makes the player very

small in comparison to the faction.

If you've ever read Dune, the great houses are a good example

of conflicting factions in which a player would seem to matter


I think gameplay as a privateer with the option to join some sort of house or company would be most appealing. With missions one can take from various places

The currency system also doesn't really make sense; currency

needs a backing of some kind; even if it's an exchange based on

planet ownership or government stocks.

I would advise a backing that humans don't have direct control

over, but that relates to a concrete resource.

I would suggest wormholes as a backing- I can explain this in more depth at a later point.

"Resources like water, fuel & chemical energy are important for

the player’s survival."

Water? No, not unless a ship is damaged. Water can be

recycled with 100% efficiency in a sealed ship.

"Energy" can be turned into fuel, and fuel can be turned into

"energy". Any of these things can be converted into human food

with variable efficiency through on board hydroponic farming or

bioreactor foods.

"Special resources like gold, platinum, diamonds and

extraterrestrial ores sell for many merits"

Diamonds? No. On a cosmic scale, diamonds are worth only what

carbon is worth, and as a very abundant element, that's almost

nothing. Diamonds can be easily produced, and even more easily


There are some dead dwarf stars, the warm cores of which are

massive diamonds far larger than the earth.

Heavy metallic elements are still worth something, but only

really the amount of energy it takes to produce them (we can

make gold, it's just expensive bombarding elements like that to

make them heavier).

Archaeological relics would be worth more- that's something you

can't just synthesize (although you can fake it).

The table regarding value of various ores needs serious


The table regarding value of gems is irrelevant- we can make

any of those gems for pennies.

The biologically sourced items, though, may be of some value-

pearls, for example- especially if they are antique.

History is the only thing with such a high value density.
In a space faring context, a world war II bullet is worth more
than a diamond the size of your head.

I postulated an alien race interested in historical artifacts- I can expand on this later.

Energy sources need to be done properly... oil isn't an energy

source in space, neither is petroleum. Doesn't make any sense

at all. There's no air to burn. Oxygen, in fact, is an energy

source in space, because it can be reacted with readily

available hydrogen and methane (found frozen or as oceans on

plant planets and moons).

Regardless, though, chemical energy isn't worth its weight.

Starting with Uranium makes sense, but that's only nuclear


There are many other means of storing and transporting energy.

Next to fission would be fusion (although the EM signature might be like a neon light to potential enemies), and following that would probably be kinetic energy storage via gyroscopic discs of tungsten carbide and carbon nano-structures. After that, maybe boron-oxygen fuel cells.

Regarding food- another thing worth real value to crew is food.

It's easy to sustain life- big vat of algae pumped through

tubes growing with an array of LEDs, absorbing nutrients from

processed waste and being processed into food cubes.

It's seriously not a concern- if you have energy, you have life

sustaining food.

But who wouldn't give their left nut for a crisp apple in deep


Food needs to be completely reworked. And again, water is

irrelevant, unless there is a leak in the ship, in which case

it's your least concern.

Regarding extraterrestrial Ore:

It's theorized that there are some plateaus of stability for

extremely heavy elements. It is possible that there are

sources of these elements somewhere in our universe where stars

are very dense, and may have accumulated extremely heavy

elements before going super nova and fusing them.

Something like this would probably just be useful as a more

efficient source of energy, though (not to say that's not


Otherwise, the elements that are available here are pretty much

available everywhere.

The weapons and HP should be based on particular attack types.

For example, a laser can be reflected by a mirror shield, doing

damage to the target shield based on the % reflection of the

wavelength of laser light.

A laser beam can also be bent around the ship using a

metamaterial skin, which would do damage to the ship based on

the frequency that penetrates the skin (skins are specific to

certain frequencies of light, although could be adaptable given


A laser could also be stopped partially by a physical shield

that absorbs the energy from it by being very thick and heavy.

A physical shield with a super conductive cooling system- or

possibly one based on the Thomson effect- would also be

effective against lasers. (lasers work by heating a material

and melting it- one that is being cooled at the same rate as it

is being heated will not melt and this prove impenetrable)

Gauss or rail gun accelerated projectiles, however, are

completely different.

A mirror would be very vulnerable to such a bullet, and a

metamaterial shield would not only less the bullet through, but

would be flawed by one, thus making it almost useless against


A cold shield would be meaningless against such a projectile as

well, although a massive piece of metal and a physical shield

would do a pretty good job.

The best shield against an electromagnetically accelerated

bullet is an electromagnetic shield- one that deflects the

bullet rather than trying to stop it.

Another defense, because the bullets do not move at light speed

(unlike lasers) is interception- probably by a laser. A ship

could detect an incoming round, and, because they are small,

vaporize them with a laser before they hit.

There are several other forms of attack, and counter measures

to every one.

Sometimes reality is stranger (and much more interesting) than

fiction, and physics is very much an example of this.

I can provide a complete list, or a table with variables for all of these and how they should work against each other.

That all shouldn't necessarily be in the demo- just damage and HP is fine for a demo.

For the final game though, it would be shortchanged that interesting interplay between attack and defense types by over-simplification. Most scifi fans would drool over that kind of depth.

The Wormholes are also not done correctly (as they are being

done, they seem to completely violate relativity, and create

impossible time paradoxes), and there are other very interesting

forms of extremely fast transit that are also worth using- warp drive, for example, can be very interesting if done properly (unlike star-trek).

Worm holes, for one, can only be one-way. When a worm hole becomes too close to another that loops back in the same direction, the worm holes collapse.

The distance can be calculated such that the distance:

(OutA -> InB) + (OutB -> InA) > (InA -> OutA)

If the distance violates that, both worm-holes collapse. If a ship is passing into one at the time of collapse, it gets cut in half.

Worm holes are invisible except for the difference in light on the other side (misplaced star, or a circle of star space in front of a planet). Worm holes can be detected by the gravitational anomaly, but only if the gravity is different on the other side of the worm hole (a worm hole X distance from a planet on the In side and X distance from an identical planet on the Out side is essentially undetectable).

Going through a worm hole, an object gains or loses energy based on the potential energy of the space it enters.

If the potential energy is lower, the object becomes hot.
If the potential energy is higher, the object becomes cold.

If the object reaches absolute zero, the object vanishes.

I can provide the equation to calculate how much the object heats or cools (it is based on the mass and the potential energy variable)

Worm holes can only be moved by warp drives (which actually don't move the worm holes at all, they move the space that the worm holes occupy).

A ship cannot travel through a worm hole using a warp drive (logistically impossible).

Regarding worm acquisition of worm holes:

Worm holes can be found, purchased, or stolen, and moved using warp drives.

A worm hole can also be destroyed by creating a partial loop using another worm hole.

Worm holes should be the basis of the economy- the value of a credit being determined relative to how many credits it costs to purchase a worm hole.

Humans should not be able to create wormholes- this technology would be far too advanced.

I have postulated an alien race capable of doing so, however. Normal materials would be useless to this race, however, these beings are particularly interested in the novelty of ancient artifacts and objects from history- they are a sort of collector people. Otherwise, they have no interest in human affairs- they will trade only in wormholes for artifacts (thus giving artifacts more objective value).

Warp drives are very different from wormholes, which are instantaneous transit.

Warp engines produce light speed transportation, and only light speed transportation.

They require energy to travel "up hill" in potential energy, and actually produce energy traveling "down hill".

A warp engine does not actually move a ship- it moves the space that a ship occupies. It causes the space "behind" the ship to grow and the space "in front" of the ship to compress.

As a consequence, a ship does not need to be moving relative to any reference frame in order to jump into warp, jumping into warp is instantaneous, and coming out of it does not leave the ship moving and is also instant.

During warp, the time on the ship is completely frozen.

If warp is performed through dense space (space filled with particles), the particles are condensed in front of the ship when it comes out of warp.

Traveling through dense space, thus, exhausts more energy. This results in warp roads, where particles have been cleared away by constant warp use.

Careful scheduling must be maintained, though, as a warp crash can be lethal for both parties involved.

I can provide more information on warp drives in future explanations.

Sub-light-speed (true propulsion):

Ion drives- work only in dense space (at higher speeds, it works in less dense space, but not in a perfect vacuum), use the present particles to propel the ship by accelerating them in the opposite direction using an EM field.

Solar sails- work only away from stars (not towards), although will work at lower efficiency at an angle away from a star.

Nuclear rocket- uses nuclear explosion to propel the ship by expelling particles at high velocity in the opposite direction.

Conventional rocket- uses a chemical explosion to propel the ship by expelling large amounts of moderate velocity particles in the opposite direction.

Laser propulsion- uses light pressure to propel a ship; only works well against a good mirror (without, it is very nearly useless).

Sling shotting- uses gravity to steal potential energy from planets and other large bodies to accelerate.

Gauss gun/rail gun- Usually only used when you're stranded and have nothing but metal and energy. Shooting in the opposite direction provides slight propulsion (mining asteroids for uranium and additional metals can perpetuate this form of propulsion almost indefinitely).

Tuesday, November 4, 2008


Outlines for icons.

In no particular order:

Mining, laser science, engineering, atomic science, gunner, robotics, medic, captain, pilot, chemistry (because it makes more sense to separate them out than to have a generic "scientist"), and profession field icon.

Can everybody tell which ones are which?

Monday, October 27, 2008

New scene

wasteland city
Bit rushed, I only had today to work on concepts. I like it pretty much anyway.

Monday, October 20, 2008

Some scenes

command bridge
This was my first scene (like, ever). I imagine this to be a little more dirty, "primitive," used-looking-bridge. I think I'll do a cleaner looking, more futuristic one later.

Something little different, I sketched this swamp scene. Could be a backdrop for some Tifusi charcters. I think the trees on the front need some more texture, maybe I'll add in the future.

Ok, the door seems to be way too small. This hangar shall be for small crafts only...

After all, I must say I really have enjoyed painting these. I still have some ideas floating around my head, I'll try to sketch (at least some of) them this week.

Hooking working

After long refactoring sessions and loads of proofs of concepts, we finally got basic dynamic action registration working via an action for the first time in a way that is generic and consistent with the overall design.

Filtering was not used by the action so far, but there is a plan to integrate it in the action that will be discussed with the programmers and implemented shortly.

The remaining bit is exposing this action via the console and this is currently dependent on accepting arrays in the command console.

Sunday, October 19, 2008

Laser Cannon A

Monday, October 13, 2008

More... guns...

Ok, so the 3/4 view is very bad looking. I'm not too good at those even with a pencil...

Sunday, October 12, 2008

Saturday, October 11, 2008

Basic Weapon Trails

Multi-direction assets are being created for these later.

Tuesday, October 7, 2008

scene item sketches

A few possible scenery item sketches. Street lamp, retro park bench, and vending machine.

Monday, October 6, 2008

2 More Prototype Weapons

New turrets added to the repository. Prototypes pending.

New artillery

Some new hardware. Nothing too much...

Tuesday, September 30, 2008

Texture work in progress

I have started preparing textures for the game which are available in the Archive/TextureArchive folder. I am also putting up textures done by blake and Vang there. There isn't alot of textures there yet; but content will be added there regularly for artists to use in I2B. For future 3d shader use, I have a plugin for generating normal maps. Mostly metal and stone textures are aimed for the demo.

Monday, September 22, 2008

Model Renders

These are just a couple of models i did from a few of the sketches i was able to find on the page, forgive me if they are not what the artist had in mind due to the fact that i only had one view to work from.

Model Renders

These are just a couple of models i did from a few of the sketches i was able to find on the page, forgive me if they are not what the artist had in mind due to the fact that i only had one view to work from.

Model renders

These are just a couple of models i did from a few of the sketches i was able to find on the page, forgive me if they are not what the artist had in mind due to the fact that i only had one view to work from.

New Model Renders

These are just a couple of models i did from a few of the sketches i was able to find on the page, forgive me if they are not what the artist had in mind due to the fact that i only had one view to work from.

Sunday, September 21, 2008

They are separated

I just finished separating the scenes from their loading. This decoupling will help in switching scenes at runtime without the need to reload assets each time. There are still minor related tasks to be done, but they do not affect current functionality.


This compass will be created as an entity with multiple directions. It will need to rotate towards the player's current beacon location. To stop the arrow clashing with spacecraft underneath, a circle is used as its background; along with a dark border to prevent clashes with bright water backgrounds. It is default I2B aqua and grey as there are no other glyphs apart from the mission text glyphs in that area. The popup menu would be hidden most of the time.

Saturday, September 20, 2008

GUI WIP Part one

Ok, currently the interface elements are scattered and unorganized. Vangelous has created the theme for the interface along with many nice elements, now I am in the process of putting these elements into the engine whilst adding some of my own. Whilst certain animation issues are being covered, I have focused on designing the layout of the game interface. Rather than make a simple composition for the demo, I am aiming for the real thing so that I shouldn't need to come back to make big changes to the interface unless it is for life or death. In the demo we can just use what ever glyphs are needed and hide the rest for the real game. Most likely, nothing you see in the screenshots will be hidden apart from certain tabs which are going to be group glyphs that control major aspects of the game; and perhaps the popup menu. So, most features will not be in full use in the 0.3 demo.

The play area view is kept square so as not to interfere with the players judgement of their shooting target. The time it takes for a projectile to reach the top of the view should be similar to how long it takes for the projectile to reach the right hand side of the view. This means the camera and ship are positioned in center of the view, slightly to the right and above the screen center. The GUI will be on a high layer to cover over the game entities. A feature to allow the GUI to be toggled visible and invisible way later on will be good; since the GUI is not always needed.

Everything major to do with the player is located at the bottom. Everything to do with other players or AI are on the right, including the target player or AI at which the player is shooting at or helping. Game status pretty much holds team condition and power progress bars along with their states and other information vital for winning a game. Management actions, Statistics, Chat, Missions, Event Logs and other features are on the left. Event logs will show what weapons the player used and how much damage they caused to the targets; anything that helps the player to understand what is happing that is not fully understood by what is seen on the playfield. Critical event logs are rear events such as 'Our scientist has died'; this would also be in the regular event log. The Mini radar is on the top right, which will also be a link to a full screen radar (in the real game), which is there to allow the player to visualize what is happening in a larger scale than in the regular view. The compass and game status elements are yet to be done. The compass points to a beacon entity; usually a mission beacon or sometimes a player positioned beacon. Miniture compasses will optionally point towards detected ships, so that the player is aware of there position even though the player cannot see them from only 500 pixels away. Whether these compasses are to be stacked in the game status area or along the play view perimeter is yet to be decided, any ideas would be great. The mission state is going to be provided with text glyphs.

Anything in the final GUI that is not grey or blue is related to key information. Colors that represent different information should not clash. For example when looking at a ship you are aiming to shoot, you don't need to move you eyes to know how much power you have, because from the lower half of your vision, the only major glyph that is orange on the screen is your power bar.

The action bar currenty contains only 3 buttons because the imaginery player only has two rockets and a force field. The first weapon has a blue ring that is full; meaning the weapon is recharged and ready for use. It is selected because of the orange glow around the button. It is a manual fire weapon because it has a blue ring. The next weapon is automatic and requires that the player selects a target on play view or in the radar for the rocket to home in on them. This weapon is not selected because it has no orange glow. The weapon cannot be used because it is recharging, shown by the incomplete ring (which is a progress bar). The force field on button three is available because anything that does not work on a spacecraft model is removed from the action bar; hence the other empty slots. The force field is on, because the button has a blue border (Normal), if the button is off it would be completely grey. Toggle devices/weapons don't recharge, so there is no ring. There can be many weapons or devices in the inventory, but the spacecraft have limits. Although there are 10 action slots; relating to keyboard keys 1,2,3....9 and 0; spacecraft can hold more than 10 devices/weapons. Button 11 to 20 are just hidden, pressing a scroll button will hide buttons 1-10 and show buttons 11-20, and so on. The inventory does not only represent what is inside of a spacecraft, but also what spacecraft is owned by the player. The spacecraft, bases and containers will act as inventory folders in the real game; so it would be common practice to use a quick spacecraft to travel to far places to pick up small items, a large spacecraft to transfer people and smaller spacecraft around, and a powerful model for battles.

Next I will implement any suggested good ideas and work on the compass, radar and team progress bars.

Wednesday, September 17, 2008

Power and containment devices

A few concept sketches for power and containment devices.

Staying in Sync

I have been going through our planed versions vision and noticed that things were a bit out of sync. We are working on version 0.2 and yet we have finished almost as many 0.3 features as 0.2 ones and even some from 0.4 (like filtering and collision). So I have decided to resynchronize the vision and move items around so that what is being worked on at this time would belong to 0.2 and moved other 0.2 items over to 0.3.

It seems that we are almost done with 0.2. Basically once dynamic trigger registration is complete (and some events defined) we are done.

Monday, September 15, 2008

More Gun(s)

Monday, September 8, 2008

Some guns..

They are grouped

We now have a "Group" container glyph. This glyph allows us to group different glyphs together to achieve various effects ranging from putting text on buttons to having movable windows and frames of glyphs.

Sunday, September 7, 2008

chief commander katsuto asuka

how about this.
is he japanese?

Saturday, September 6, 2008

Pure events

After some productive discussions with Thales about the best ways to filter events, we finally decided on an interesting filtering mechanism. We will be using a separate filter object for each condition. This allows us greater flexibility in composing our filtering conditions. An event must pass a chain of filters, if any of them rejects the event then it doesn't get processed. ORing of conditions would be possible via a higher level OR filter that takes as its parameters the filters to OR, this feature is not yet need though.

Our first concrete filter was implemented and tested, it will filter entities based on their Instance IDs.

Friday, September 5, 2008

I2B 0.3 Demo preperations

Features in the engine are expanding to the point of having much to show. As we move forward, content for the first demo has been started; with a space shooter, glyph showcases, comic strip and script demos planned for this release. Although the plan is not written in concrete, I have started work on the missing visuals and the UI layout of the menu system, which is where all aspects of the demo are to be accessed and controlled.

New leader sketches

I sketched new leader characters for the UN, the Nebeucus Space Police and the Galactic Task Force; all on the repository. These now need to be passed on to an artist for refinement and rendering. (See their descriptions in the game document faction section) These and other characters are likely to be used in the comic strip in the 0.3 demo release.

Thursday, September 4, 2008

Sigh of "release"

It has been many months since I last saw a successful "release" build. Somehow we could only build in "debug" mode. Finally, I decided it was time this went out of the way and after struggling with solution files and project settings I fixed it for good.

To prevent this from breaking again, the build server now builds in both configurations.

Monday, September 1, 2008

Concerning I2B Audio

This is dustprog and I just sent Mokhtar the audio code and we now have audio functionality working as designed.

Wednesday, August 27, 2008

New Gallery

I have just refined our website's main gallery. It now includes five different album slideshows and has the work of our new artists added.

We should also put some audio on our site and not just graphics.

Tuesday, August 26, 2008

artifical planet balloonfish, BF003

it is complete. click it, you can see big size

have a good day

Monday, August 25, 2008

New concepts, in order a transport ship and a battleship

a atifical planet on motive balloonfish WIP

hi, everybody, i'm kevin ryu. maybe a new member.

i made a atifical planet. i was make it on motive balloonfish. maybe width is 1.5km, it have one big size gate and three small sub gates

it's not complete yet. i make more details.
sorry, my english is bad. understand me please :)