Jump to content

  • Log In with Google      Sign In   
  • Create Account

Life at Demergo Studios

Moving Like Fixbot

Posted by , in Demergo Studios, Fixbot 08 March 2012 - - - - - - · 595 views
fixbot, game, lateral movement and 5 more...
Post by Zak, Design Director at Demergo,

So, if you’ve been keeping up with our past entries you’ve gathered that our game messes with the normal thought of gravity in a platformer. Fixbot is a repair bot on a spaceship. The spaceship has no gravity. To move around, Fixbot has a large magnet on his butt. He uses it to repel himself with from one surface then attract himself to his destination surface. So basically he can only move away from a surface. He has no lateral movement. If he wants to slide over, he has to repel from the floor, attach to the ceiling, then repel from the ceiling, and attach back to the floor.

This makes designing the levels a bit of a challenge because if I’m having the player rethink conventional movement I need to have totally mastered our new style myself. I have to think like Fixbot. Here are two things that helped… (Yes, I am giving you hints on how to beat our game).

Step one on mastering Fixbot’s movement: stop thinking laterally. Ever since you started walking you’ve been moving laterally. You move forward, backwards, left and right. To move up you go forwards on stairs and that takes you up. It only makes sense that you naturally think that way. Fixbot can’t move that way, because he can only move ‘up’. So when bullets are flying at him and he has to dodge, his only course of action is to move up. When I make levels I need to make sure that he always has somewhere above him to go to.
Step two on mastering Fixbot movement: there is no down. Fixbot is in space, which I think I’ve mentioned. There is no down in space. Whatever Fixbot is attached to is down. It’s the floor. He has no qualms about sitting on the ‘ceiling’, and he’ll sit there happily because to him, it’s the floor. When I design levels I need to make sure that I think of all the surfaces, the floor, the walls, and the ceiling as just one thing: the floor.

There are other things I use to ‘move’ like Fixbot, but if I told you those you wouldn’t play my game.

Reposted from Fixbot Blog

To Move or not to Move

Posted by , in Demergo Studios, Fixbot 06 March 2012 - - - - - - · 585 views
lines, movement, the force and 4 more...

Post by Joel, Programmer at Demergo,

A critical element of any game that must be considered carefully when designing and developing is the movement and controls. The decision will affect every aspect of the game and the very feel of play. There are as many movement styles as there are game types. Ranging from the simple run-and-jump of a platformer to the head-scratchingly complicated schemes that allow precise control in flight simulators. In our case we chose a relatively simple setup that works off of lines. When the player drags from fixbot to a point on the screen a line is projected out in front of his finger that collides with walls and objects in that direction. When he releases his finger fixbot is rotated to a correct landing angle and moved through space to the new wall.

To handle the movement from the code side we use a modified version of the Cocos 2D engine's built-in movement and rotation actions. By starting from a pre-built engine we avoided a lot of the risk of redesigning the proverbial wheel. Of course even with the assistance Cocos was, it still didn't solve all the issues we had but luckily we were able to reuse a lot of the math work that we did for the surfaces in the level. In fact, the most difficult math came into play with adjusting player rotation after launching to a new surface. By dragging a line from the player to one of the level surfaces we calculate distance to the point of collision and once the player releases we launch them down that line until they land safely (or so they hope) on another surface. Getting the correct rotation required a healthy smattering of linear algebra and geometry but the less said about those dark times the better.

Because controls dictate how the player interacts with the game they color his entire experience and directly affect his enjoyment. It is therefore important to make sure that the control scheme chosen matches the goals for the game.

Reposted from Fixbot Blog

Saturday Dev Update 3

Posted by , in Demergo Studios, Fixbot 03 March 2012 - - - - - - · 539 views
deadline, demergo studios, fixbot and 8 more...

Post by Dan, Programming Director at Demergo,

It's been a crazy week here at Demergo, and we've gotten a lot done!

This week we've implemented a new tile engine, as well as reworking the level editor to handle it. While the programmers were getting the tile part of the engine working and optimized, Zak was designing the levels with tiles in mind and the artists were creating the tiles that we'll be using. We've also managed to get the game working across all of our target devices, as well as clean up a lot of the bugs with the movement code.

We're looking forward to next week, when we'll be starting to build the final versions of the levels! There is a lot more to do, and our deadline is getting closer - but we're making tons of progress and having even more fun!

Keep an eye on the gallery, because we'll be posting some screenshots from the tiled levels soon!

Reposted from Fixbot Blog

Building Ground to Stand On

Posted by , in Demergo Studios, Fixbot 02 March 2012 - - - - - - · 607 views
collision, fixbot, level design and 8 more...

Post by Dan, Programming Director at Demergo,

Early on in the design of Project Fixbot, we knew that we wanted large and somewhat complex levels, designed primarily around our movement style. We needed to be able to handle different kinds environments, and we wanted a lot of flexibility when it came to the design of the actual levels - this included the ability to have the ground at weird slanted angles. But this created some new challenges for us: how would we handle collision, with all of the different kinds of things the player could collide with?

One common way of doing collision is to handle it by using the object's bounding box and sprite to decide if collision has happened. Sometimes this includes using per-pixel collision to handle odd-shaped objects. The problem with using the bounding-box method in this case is the flexibility we wanted with our environments (weird slants and the like). Per-pixel collision checks can be expensive on performance, and in our case it wouldn't handle all our movement style easily.

That was when I decided to use "surfaces" (as we call them) instead of using bounding-boxes or the art assets themselves for the collision.

I figured out that all we really needed to handle all of our movement and collision was an invisible line. These lines (surfaces) would tell our engine how the player and enemies should interact with it - whether that's by colliding or bouncing or something else. Using these surfaces lets our team jump from level design to level implementation much faster. While Joel and I were creating the surfaces and how they would work in the engine, Todd was creating a level editor that would let us create them. In the level editor the surfaces get created on top the level art assets, allowing Zak and everyone else building the levels to match things up quickly.

Getting the surfaces working correctly involved a lot of line-based math programming. In code, our surface class has a lot of helper methods we had to create to do things like computing the slope of the line, checking the distance between a point and the line, and checking to see if two lines actually intersect at all. Another tricky part was deciding what side of the line the player was on so that we could rotate him accordingly - it would be really annoying for the player if he launched Fixbot at a wall only to end up inside of it; getting that part working was one of the first major hurdle for us to get over.

Overall, the surface method has been difficult to implement properly, but has been very rewarding. With a lot of hard work and a lot of staring at the whiteboard, we've managed to build ground to stand on.

Reposted from Fixbot Blog

Beautiful Worlds, Part 1: Research

Posted by , in Demergo Studios, Fixbot 01 March 2012 - - - - - - · 626 views
art, design, environment, worlds and 6 more...

Blog Post by Omni, Art Director at Demergo:

Oy, world! It's me, Omni the artist, and I'm here to talk to you about environmental design! As far as games are concerned, environments are an aspect that is often overlooked or taken for granted. However, there is usually a lot of thought and deliberation that goes into creating an immersive environment. While our designer, Zak, is formally tasked with the creation of the world in which our games exist, in reality, it is the collective efforts of the designer and the artists that leads to environments that exist in an immersive world.

For the artists here at Demergo, environmental design is one of the few elements that continues to evolve beyond the pre-production process. But as that implies, environmental design begins during pre-production, where the artists, including myself, sit down and evaluated the level worlds that our humble protagonist will encounter. As Zak and Dan—who serve as our de facto story writers for Project Fixbot—outline the story for us, the artists' creative juices begin to flow. But before the Photoshop brushes start moving, two far more important steps must be completed: Research and Thumbnailing. Our discussion today will cover the former topic, Research. With our ideas fresh in our minds, the artists take to the magical world of Google, gathering reference photos, art, and information.

For our game, Fixbot finds himself in a space vessel that is very much unlike any spacecraft created by modern humans. As such, I felt it was important that the aesthetics of the vessel be different from those of modern-day or futuristic designs, which are typically very sleek and clean. So I decided to look to the opposite side of history at the ancient past. I began studying ancient civilizations from East Asia and Egypt, but I felt that those cultures were too familiar. So I looked to a culture that is often overlooked: Ancient America. No, not the United States; I'm talking about Aztecs, Mayans, etc. I began collecting photos of various ancient structures and art, and a recurring theme was that of tiling geometric patterns. Given that our game is tile-based, I felt it was a perfect fit. While our research primarily lays the groundwork for the artists, I found that ideas for the story began blossoming as well. These story ideas became the fertilizer for more art concepts, and the cycle continued.

To make a long story short, story feeds art, and art feeds story. This cycle is what makes a simple concept become immersive. Immersion can coexist with simplicity, and some of the most beloved worlds are those where the complexity is completely unspoken. That complexity is born in the process of research.

I'll be talking about that second topic, Thumbnailing, in a later blogpost. Thanks for reading thus far, and stay tuned for more! (especially if you like pictures XD)

Reposted from Fixbot Blog

Saturday Dev Update 2

Posted by , in Demergo Studios, Fixbot 26 February 2012 - - - - - - · 646 views
art, chunks, demergo and 9 more...
After a long hard day of work on Saturday, I know many of us at Demergo are ready to take a break, but with the looming deadline just about 9 weeks away, we don't have the luxury.

Over the course of this week there's a lot we accomplished.

For Art, a lot of the enemies in the game entered the illustration phase, and one of the enemies was nearly completed as far as animation goes. The base environmental tileset was completed so now our currently very ugly levels will start to look a little less ugly. I was reading a blog a while back about one way to motive artist to get art done, and that was simply to use really ugly programmer art (actually, programmer art is always really ugly) throughout the game and then give the game to the artist to play. After about a few seconds of play, the artists can't stand it anymore because of the ugliness and soon afterwards really nice art starts appearing in the game!

On the Design side of things, Zak is tired of remaking the same levels over and over in the editor again! The editor and how it works is changing somewhat frequently due to new features being added, so those new features on occasion break the old export format so the level has to be rebuilt. We just enjoy torturing Zak!

On the programming side of things, this has been quite a week! We did not add to many new features, in fact almost none, but this week was a polish the features we currently have and continue to optimize the performance of the engine. On Saturday we began to notice that when we would "jump" across really large levels, our player character would move so fast that the ipad1 could not keep up with the constant asynchronous loading and unloading of textures. While on small to medium size "jumps," the texture loading speed was fine, on really large jumps, the texture loading and unloading could not keep up and there was really no good way of increasing the texture loading speed, so we moved over to a 64x64 tile-based rending for the playerground. This weekend was really performance testing/fixing weekend! (I am sure there will be a big blog post about this by one of the programmers later on).

As far as QA testing, well, that was primarily all wrapped up in performance testing the various methods of rendering the playerground to get the best performance with the least amount of memory and visual artifacts.

And that concludes another crazy busy week here at Demergo and don't forget to check out some new pics we posted on our Facebook page.

Devbot Todd entering sleep mode...

Reposted from Fixbot Blog

Basic Level Design: The Unseen Job

Posted by , in Demergo Studios, Fixbot 23 February 2012 - - - - - - · 958 views
basic level design, game design and 12 more...
Post by Zak, Design Director at Demergo,

People forget about the level designer: most people can imagine someone programing the controls, an artist drawing a character, or a writer weaving a story, but his job mostly gets ignored. The level designer is kind of like a janitor: he only gets noticed if he does a bad job. If a level designer makes a bad level you'll be screaming at your iPod about how you can't find the exit, or how that one area keeps killing you. Now if he does it right, you'll see the awesome art, you'll experience amazing mechanics, or you'll be immersed in the gripping narrative. Basically I get to create the frame and make sure I don't cover up the painting. In this article I'll be telling you about that job or essentially my process in creating a level.

First, I need to know what my limitations are - basically, where in the story I am. I also need to slowly introduce gameplay elements so as not to overwhelm the player. So, I start off by getting the list of story elements Dan made me for the level (person A meets the player, person B dies, and event C happens), and my own list of which gameplay elements are present (new gameplay element D, reiterate gameplay element E).

Next I decide how much of this level is going to be tunnels or open exploring. I use tunnels to guide the player towards an objective and I use open exploring when I want them to find it themselves. Most of our levels fall somewhere in between.

Then I sketch a quick outline to get me started. This isn't a blind sketch - I know where I left the player at the end of the last level - and I know where I want to take him. I take this sketch and take each room and ask questions like "what would make this hard", "what would make this not confusing", "how does this tell the story", but most importantly "what would make this fun". I flush out each room and move onto the next one.
Then I hand it to Todd for QA. He does some playtesting with my level and lets me know what he thinks then I go back and make alterations, asking the same questions as before. We do the QA loop a couple more times and then we have a level. That level, if I did my job right, should be fun, tell the story, showcase the art, and introduce the mechanics - all with out anybody knowing I've been there.

I'm Zak, and I'm the janitor. ;)

Reposted from Fixbot Blog: http://demergostudios.com/fixbot

Of Large Levels and Small Devices

Posted by , in Demergo Studios, Fixbot 21 February 2012 - - - - - - · 605 views
chunking, level editor and 6 more...

Posted by Ian Wagner, Programmer at Demergo,

"I suffer from short-term memory loss. It runs in my family. At least I think it does..." Speaking of which, one of the fun things we get to deal with while developing the Fixbot game engine is management of the device's short-term memory. iDevices have a very small amount of short-term memory compared to desktop computers or consoles. While it is not uncommon for a PC/Mac game to require upwards of 1GB of RAM these days, iOS apps are hard pressed to get 20MB without running the device out of memory. This presents a slight problem for games like Fixbot, whose levels can exceed 10,000 x 10,000px. As you can imagine, an image this size would consume quite a bit of memory.

In addition to the sheer memory usage of this image, there is another problem that needs addressing. Fixbot, like most other iOS games, used OpenGL to handle rendering. This imposes a texture size limitation of 1024x1024 or 2048x2048 (this limitation is device-specific). In order to handle levels up to 10 times this size, we specially designed our level editor to split the levels up into multiple images. The location of each "chunk" is then written to the level file so that the game engine knows where to draw each piece.

As previously noted, we don't have enough memory to keep the entire level loaded in memory, even if it is chunked up into manageable textures, so the engine has to be smart about which textures it keeps around and which get unloaded. We're still deciding on the proper balance for each device, but the game engine basically checks where the player is periodically and then makes sure that all chunks within about a 3x3 screen block (with the player in the middle) stays loaded. Everything else is "forgotten" as quickly as those random facts after the history test :)

Reposted from Fixbot Blog: http://demergostudios.com/fixbot

Saturday Dev Update

Posted by , in Demergo Studios, Fixbot 18 February 2012 - - - - - - · 614 views
fixbot, demergo studios, saturday and 8 more...
As Saturday comes, here is a recap of what happened at Demergo and what got done.

On the art side of things, the main character Fixbot was rendered, and one of the enemies was rendered as well. A lot more concepting of environments occurred as well as some rendering of the environments.
On the design side of things, design finalization was taking place on level 7, level 6 got an alpha build in the level editor and level 8 design was started. A lot of fine-tuning and playtesting of player movement also occurred today.

On the programming side of things, multiplayer/co-op is now working using Apple's game center for matchmaking. We have bullets, player positions and rotation, as well as some level info being transmitted across the network with minimal latency issues, but the really major test will be when we have 10-15 enemies, plus bullets, plus multiple players all on the screen at once. Magnetic surfaces were finished, bounce surfaces are almost done, and conveyor belt surfaces were started. Bullets colliding with level surfaces was also completed. On the level editor side, creating object movement paths was started and will hopefully be finished by the end of the day.

For QA, this was a big day, because this was the first Saturday of major QA testing. Our production pipeline is setup so that a QA build is built on Friday night so that when Saturday morning comes, we can sit down and test out and polish the game, before moving on and adding new features throughout the rest of the week. Saturdays are QA and polish days. We did a lot of QA testing on player movement and bullets and we also did some QA on the different types of surfaces. A lot of polishing was done on those features as well.

Well thats it for our first Saturday update. As we continue to progress in production we might start including screenshots and early gameplay video in these Saturday updates.

Devbot Todd shutting down...

The Design of Fixbot

Posted by , in Demergo Studios, Fixbot 17 February 2012 - - - - - - · 616 views
design, character, main character and 7 more...
The Design of Fixbot Fixbot Blog Post by Omni, Art Director at Demergo Studios:
Posted Image

Here's our humble protagonist. He is Fixbot model no.: 23-972-c. Like most video game protagonists, Fixbot had to be designed by somebody. In our case, he was designed by a group of artists led by a dynamic vision.

As mentioned by Todd, the project began with a "spark." The spark begins with the team of designers, artists, and programmers all collaborating to craft a gaming experience that is founded upon a compelling story. Right away, the other artists and I began to draw whatever came to mind throughout the meeting. At the beginning, we knew some things were more or less certain: the game would boast a multiplayer co-op and would have something to do with gravity or space. With this vague concept in mind, each of the artists' initial sketches were wildly diverse.

Posted Image

As the "spark meeting" progressed, it was determined that our game would be a side-scrolling shooter. As the story and gameplay began to take a more solid form, so did the designs for our character. The story eventually culminated into a tale about little robot whose sole purpose, according to his programming, is to repair a gigantic abandoned space vessel in which he finds himself upon startup. You're likely familiar with the old saying "form follows function." Well, as our character's function became more defined, each artist's sketches began to converge into similar forms.

Posted Image

In the second day of our spark meetings, we finally hammered out a final design for our robot, which we decided to call "Fixbot." The final design, which was produced by yours truly, is a culmination of many of the design elements of the various sketches by the different artists. As each artist draws a bit differently, the process of combining these different elements required the creation of a set of stylistic conventions which would guide all subsequent character and object designs moving forward. Using these conventions, I came up with this final design sketch.

Posted Image

You may be able to recognize various elements that were borrowed from the preliminary sketches. Fixbot is equipped here with a hard hat, a modular hand that serves as a repair device and low-power weapon (pew pew!), and a magnetic base which fixbot uses to affix himself to any metal surface in his gravity-less environment. So as you can see, character designs are constantly evolving as the game concept evolves. As such, it is important for an artist to let his mind flow freely. In doing so, a design can evolve naturally and rather effortlessly.

This has been Omni, (otherwise possibly known as hextupleyoodot), and I am an artist.

Reposted from Fixbot Blog: