Archive for the ‘Topdown’ tag

Application Design vs Game Design Round 1

Hi everyone, Vlad here.

Let me start by saying that the title is a bit misleading. For starters it is not an actual bout but more a decision making process. It also gives the impression I’ll write more about this or that I have some kind of plan about this subject. I don’t, it just happens that I think I’ll travel this road again.

Game Design

The game design for this game states that:

1. The player’s objective is to reach the top of the “structure” (named just to make sense) where the action rolls;
2. The “structure” has several “floors” (again just for easier comprehension);
3. The player can fall to the previous “floor”;
4. It is guaranteed that the player will see at least three “floors”;

Application Design

One thing that I know for sure is that we will be blitting all graphics and that the player token has three different blit objects and two of those rotate thus negating copyPixels and putting the dreadful draw method to work.

Another thing I know is that each “floor” is a tilemap, also blitted and that each tile is 64×64.

And now the assumptions begin. How big is each “floor”? I have no idea but let’s say that a rather large “floor” has 50×50 tiles. If the player will see at least three floors and on later stages all “floors” are rather large we are talking about 7,500 tiles to be rendered with a astonishing number of 30,720,000 pixels to be copied… each frame.

The “floor” where the player is will only render the tiles on screen (88 max) but the other two lower “floors” can potentially be fully rendered given the camera specs. Even if all three “floors” only rendered tiles on screen (which won’t happen by design) there would still be 7,500 objects to manage and that’s tiles only since we need to add to this all the remaining entities: player, enemies, decorations, effects, etc, but to make it worse the bottom two levels will be zoomed and probably in full view which means not only that all their blit objects will be visible but also that at least 5,000 of those objects will use draw instead of copyPixels… Did the headache kicked in already or is it just pure performance insanity?

Implementation

One of the great things about copyPixels is that it only renders the intersection between the target bitmapData rectangle and the source rectangle positioned at the destination point. What this means is that if we have 1,000 objects to render but only one actually has an intersecting rectangle, most of the processing time is running the array, vector or list and – more important and processor heavy – calling the functions that will in the end render.

The draw method also does this with a matrix… more on this later.

The solution was to write a BlitTileMap class that builds the tilemap in one big texture before it is used. While it uses much more RAM this class allows to address pretty much every problem stated earlier.

First and foremost the number of objects managed and therefor the performance lost with running their container (in our case, a linked list) and calling functions. From a potential 7,500+ we now have 3. The other issue that this addresses is the number of pixels it will render or try to render, from potentially 30,000,000+ to the worst case scenario of 1,050,000. And last but not least, considering the lower “floors” will be zoomed out, instead of using draw to render 5,000+ objects it will render… 2!

But the draw method also has a funny and helpful consequence. The smaller the scale, the faster draw executes which in terms of performance is relevant considering the zoom out will be achieved through scale. Less objects taking less time to render will be (I hope) quite a performance boost.

Did I just write all this? Wow!… Later!

Posted: January 25th, 2012
at 12:15am by Vlad

Tagged with , , ,


Categories: Dev Journal: Danger Zone,The code of VGS,The design of VGS

Comments: 2 comments


Pulling it appart

Some of the art of M:A:D has to be done following rules from the coder’s side. Even though this may sound limiting, in some cases it helps the artist reduce the image number and keep his assets organized. For the case of the units in M:A:D, we created a hierarchy based movie clip. The mechs have legs, the drones don’t, because they… OOPS, best not say everything.

The unit is made up of a body, a set of legs and the weapon. Reason for this is that the weapon should rotate independently from the body and the legs are just a 10 frames animation. The body was created in 3D and animated to rotate in order to have a realistic depiction of the lighting on the unit, to make it the same as the structures. as the unit rotates the rotating body moves along the frames to match the frame to the rotation, while the legs are a movieclip being rotated.

The other element on display there is the the structure being slightly damaged and we used smoke to illustrate that. Dents will be added later. The smoke is done with on 16×16 particle being scaled rotated and having the color and transparency changed.

Hope you like the little sneak peek inside the backstages of some of the art in M:A:D.

Posted: July 21st, 2009
at 12:00am by Marco

Tagged with , , , , ,


Categories: The art of VGS

Comments: 7 comments


A level mockup of M:A:D

Another shot we took somedays ago. Here you can see a full level mockup with both player and AI positioned and some terrain detail.

The destroyed cities are part of the game by the way… we just won’t tell you what for, that’s how evil we are, muwahahahahah!

Images courtesy of Marco, general bla bla bla courtesy of Vlad!

See you all soon…

Posted: July 17th, 2009
at 12:00am by Vlad

Tagged with , , , ,


Categories: The art of VGS

Comments: 3 comments


M:A:D Screenshot #1

Hi,

Sharing a simple screenshot we took some days ago showing buildings, units and the first version of the GUI.

All feedback is welcome and see you soon!

Marco

Posted: July 15th, 2009
at 9:30am by Vlad

Tagged with , , , , ,


Categories: The art of VGS

Comments: 8 comments


Conceptual design is a logical thing

Though some artists and designers may disagree, I prefer to believe that conceptual designing is a form of logical thinking that uses methods from the artistic realm to express it self. I don’t trust inspiration to guide me as often as logic does. My clients aren’t paying me to wait for inspiration. They pay and expect me to act as a professional that sits down and gets the job done without drama or frustration because inspiration doesn’t come.

For a new in-house project we are working on at VGS, I had to design a series of buildings that represent different features of the game. Without revealing much of the game itself, I’m going to try and explain the reasons behind the final images that came out of this arduous yet very satisfying and motivational conceptual design process.

Originally I made some quick sprites for Vlad to work on his first tests. just placeholders. He was rather quick to let out a big fat “MEH” when he saw the two little structures.

original_crappy-ones

After some discussion the structures we have are:

A central, a couple of factories, a lab, a workshop, a metalworks building, a radar and a repair building.

The only one that resides on “inspiration” is the central, which was the first to be designed and drawn out on paper, modeled and detailed.

The concept was “something that is set on its own center and has supports to keep it there”. That pushed me to a tripod concept.  And while you can certainly allow inspiration to let you come up with this, a logical approach will likely yield similar results. Write down stuff that has a center and supports. “Tripod” will quickly come up.

first_structures

These were originally sketched in flash, because I can use a movieclip with its mirrored instance next to it. I draw and it updates.

All the other buildings that followed were in a way… doodled on the “paper”. I really was hoping for inspiration to help me out. But no!
The only thing I kept was the fact that I wanted them to have very distinct silhouettes for readability. I want the player to be able to look at them and automatically see what structures they are.

In some specific cases, like the radar, I gave it a bit of a satellite dish look. For the lab I had different sections and both the workshop and metal works were just mere doodles, trying to find a shape that I liked. And that’s where I failed, because I already had a shape I liked. The Central’s shape.

So I trusted my judgment and modeled it and rendered it. I also liked the original repair building so I went with it as well. They came out as good as I hoped and I stuck with them. The problem was the other buildings

first_renders

So, not satisfied and at a dead end, I showed them to a couple of friends and they said “Cool! looks very alienish and very distinct from each other”. So, one of the parts was done – differentiation. Now for the second part – making them look not alien, but robotic.

And one thing I think that robots would believe is “if something works, stick to it”. And that’s what I did. I chose a couple of shapes I liked from the Central building, and used them to replicate the original layouts.

second_take

The lab was now 3 “departments” instead of 4. The workshop was no longer a smoothed building but more of a office building structure to it, with a big outer area for whatever tests that need to be done (and also to convey a square area for the  whole building). The factories have long warehouse areas to create the sense of big work areas. The metal works has a central area that creates a connection between two big furnaces.

While modeling them, I still messed around with the designs, to make them more interesting and have more readability as iconic shapes. Here they are, compared to the previous designs so you can see how much artistic liberty I took while modeling them.

design_relations

So as you can see the central’s got a two color scheme to match the rest of the buildings, as I felt they needed a base color and a “team” color. The metal works was rotated 45º to create a diamond area instead of a square one and now has a big chimney for the furnace and a dome area for the metal to pour in. The workshop is very close to the previous design and has a court yard, much like the repair. The laboratory’s departments where scaled differently just for extra visual interest and the radar was put a bit more in par with the overall designs. Both factories have a big dome like area to suggest the “brain” of the building and then a smaller warehouse or storage area. They were also rotated the same amount of degrees but in opposite directions, to suggest that even though they are both factories, they generate different things.

Here are the very final desings :

final_designs1

The central building lost one of the elements that looked like a wrench that was put on the repair building. Looking like a wrench actually works better on the repair building.
there was also added some detail to the workshop building to suggest a garage entrance, exhausts on the roof and some pipes, for air circulation.

This is the process that was involved in creating the original central, from concept to finished.

process

I hope this was an interesting read. The final result pleases me and Vlad, or at least he says so, and I chose to trust him.
Stay tuned on the blog for more interesting stuff that comes out of the VGS’s incubator!

Posted: March 31st, 2009
at 10:23pm by Marco

Tagged with , ,


Categories: The art of VGS

Comments: 5 comments