GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design.
The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game.
The free ebook is available through CRC Press by clicking here.
The Curated Books
The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell
Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here.
A Practical Guide to Indie Game Marketing, by Joel Dreskin
Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here.
An Architectural Approach to Level Design
This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here.
Learn more and download the ebook by clicking here.
Did you know?
GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Well I haven't posted on here in a while, but I am posting again, primarily to say that after a few months hiatus, the guys at Demergo are back together again and are working on a new project. Our aim for this project is small, simple, and completely cross-platform.
Also, on a side note, I just noticed that flipcode is no longer dead...but alive again. I never really visited the site when it was alive, but I have visited it many times since it's death, so I am excited to see another valuable game development resource resurrected again! (Gamedev.net is awesome too, but thankfully it never died!)
Have fun everyone and enjoy making games!
(Update/Note/Hint to flipcode owner): After further investigation, while flipcode has some good articles and features...I am patiently awaiting the hopefully future existence of some form of reasonable search (or unreasonable search for that matter!) for flipcode and its archives.... (while a google custom search does work, it works rather painfully).
Function.repair is a fresh new 2D platform shooter with a unique, no-gravity movement style.
You assume the role of Fixbot, one of the many fixbots, who awakens to find himself in the middle of a massive, broken down space ship. You don't know where you are; all you know is that you are programmed to repair the ship. However, repairing the ship will prove to be more difficult as you will run into various environmental hazards, hostile aliens, and mysterious saboteurs.
Function.repair brings immersive gameplay to iOS. The unique gameplay elements allow each player to enjoy the game in his or her own way and at a desired rate. Function.repair was built by gamers, for gamers.
Hey everyone! I hope you're as excited as we are, because tomorrow - June 20th - function.repair will be available for download! We'll also be putting up a new trailer showing some of the multiplayer! The game should be available by mid-day, but if you check the app store and can't find it, don't worry - just check back in an hour or two (or keep checking every two minutes, if you're really dedicated!). We'll also post the video on YouTube and Facebook when the game becomes available.
Thanks for your patience and support. We hope you enjoy the game!
I just wanted to give a quick updated on the status of function.repair. If you haven't been following us on our facebook page, go do that now, because that is, and probably always will be the most up-to-date source for fucntion.repair and anything Demergo related. While we submitted the app to Apple, they took their sweet old time with testing our app, and they just got back to us tonight and it was rejected due to some technical issues. As I posted on facebook, it has been so long that when we resubmit to fix those issues, we will also be submitting our 1.1 patch too. So that means a much more stable and polished version for everyone, but at what cost... the cost was a missed deadline and a missed promise to our awesome fans. And we all, at Demergo, deeply apologize for that.
We are still learning and we hope that you all bear with us as we go through these learning experiences. Having said that, we do have good news, we have begun pre-production on our next game! The artists are busy concepting away at all the cool new environments and characters and awesomeness that they do.
I will keep you all posted on when function.repair hits the app store, and we plan on doing a post-mortem and posting it on here and game career guide as well. We are hoping for a video post-mortem so that you can all meet the awesome team behind function.repair, but we will have to see how much time we have.
the Demergo Team sincerely thanks all of you for your patience and awesomeness!
Hey everybody! This is Omni, artist at Demergo Studios, here to present our gameplay trailer! We've been hard at work over the past week putting things together in order to present you with footage that is truly representative of what you can expect when you play the game. Do keep in mind that the footage is of a game that is still currently in development, and the represented content is subject to improvements. So without further ado, enjoy the trailer!
That was a mouthful. Dan here, just wanting to let you know that we are working on a trailer for function.repair and we hope to have it up for everyone to watch on our youtube channel early next week! We decided to go ahead and show you just a little bit of the video now, along with some behind the scenes footage of the crew as we were recording it.
[color=#000000][font=Georgia,]Today Demergo Studios is happy to announce our new game: function.repair[/font][/color]
On a spaceship at the far edge of the galaxy, a small robot awakes...[/font]
You assume the role of one of the many fixbots whose primary function is to repair the ship. After boot up you find the ship in great disrepair and set out to fix the damaged sections. However, repairing the ship will prove to be more difficult as you will run into various environmental hazards, hostile aliens, and mysterious saboteurs.[/font]
[font=georgia,serif]Function.repair is a 2D platform shooter boasting a truly unique movement style, a fun (and perhaps edible) art style, [/font][font=georgia,serif]cooperative play using up to 4 iOS devices
, and an original full-length soundtrack that truly brings the environment to life. All of these elements come together to create an engaging single or multiplayer experience.[/font]
[color=#000000][font=Georgia,]Formerly known as "Project Fixbot," Function.repair is something that we have been working hard on over the last few months. We are really excited about its impending release and we hope you will be too.[/font][/color]
[color=#000000][font=Georgia,]Function.repair will surface on May 19, 2012. Check the website and the image gallery for new screenshots, promotional art, and downloadable wallpapers! More will be added as the days go by.[/font][/color]
[color=#000000][font=Georgia,]Post by Dan, Programming Director at Demergo,[/font][/color]
[color=#000000][font=Georgia,]Hello family, friends, fans, and enemies! Due to the exaggerated rumors spreading like wildfire that we are dead, we felt that we needed to speak out. Okay, so that was exaggeration on my part, but I did want to write and apologize for our recent lack of communication! We've been busy working hard on Project Fixbox, but that is no excuse for not keeping all of you up-to-date.[/font][/color]
[color=#000000][font=Georgia,]Don't worry - we are not dead (okay, enemies - you can worry) and we will not be silent![/font][/color]
[color=#000000][font=Georgia,]We have all been working hard, I am proud to announce that we are proud to announce that Project Fixbot has reached the next stage! We'll be officially announcing the game title and release date tomorrow, so check back here (well... not "here" as in this post... but "here" as in the website)![/font][/color]
[color=#000000][font=Georgia,]Reposted from Fixbot blog here[/font][/color]
[color=#000000][font=Georgia,]Blog post by Dan, Programming Director at Demergo, (Sorry, I forgot to repost this here after it went live a week ago on the blog)[/font][/color]
[color=#000000][font=Georgia,]Setting the right mood in the environment surrounding the player is very important. A very difficult and many times incorrectly-done part of this is the lighting. Depending on whether the game is 2D or 3D, and if you want dynamic lighting all play into how difficult it is. As with most every other decision, your target device (computer, console, mobile devices, etc) and your target market will heavily influence the entire process; Devices have limitations, and different styles of games need different moods and environments.[/font][/color]
[color=#000000][font=Georgia,]With Fixbot, we wanted to have some lighting in one of the levels. We weren't really worried about having realistic shadows or dynamic lighting - we just wanted the idea of navigating the player in the dark with something like a flashlight to be another fun gameplay element.[/font][/color]
[color=#000000][font=Georgia,]With this being my first major game project using Cocos2D for iPhone, I hadn't done any form of lighting with it yet. I had done lighting (both dynamic and non-dynamic) in other PC and Xbox360 projects, using different 2D engines including Microsoft's XNA and the more cross-platform SDL. Even though I had done similar lighting styles with these systems, I was having trouble figuring out how to best do the lighting in Cocos2D. I think my biggest problem was that I was still learning the underlying core of Cocos2D: while Cocos2D is very advanced, and is a wonderful engine for indie developers because it is open-source, it was doing things a little differently than I was used to. Now that I have had more time to learn it, as well as time spent on digging through forums, blogs, and finally the engine's source code itself, I have a much better understanding of it.[/font][/color]
[color=#000000][font=Georgia,]At first, we tried doing the lighting in OpenGL. I had my best programmer, Ian, digging through OpenGL books and rewriting shaders to work with OpenGL ES (which is what Cocos2D uses). While Ian spent a week on that with minimal success (it just wasn't performing like we needed it to), I started researching again. I was digging through blogs and forums (and again the source code) looking for methods to do simple lighting in Cocos2D. I was looking for an old-school 2D approach to the lighting - have a light sprite on the screen, and color all of the other pixels on the screen based on their distance from the light. Another method I was looking for was where you have a black (darkness) overlay covering the entire screen, and then "cut holes" in it using the light's sprite (usually based off of the sprite's alpha values).[/font][/color]
[color=#000000][font=Georgia,]Eventually I found the start for what I needed in order to do the second method - cutting holes in an overlay. My biggest worry going in was performance - for the lighting we wanted, we didn't just want to have the player have the only "flashlight" - we wanted objects in the environment to have lights as well. This is when I found the CCRenderTexture class in Cocos2D. It's a very powerful tool that can be used to do multiple things, including blending and masking.[/font][/color]
[color=#000000][font=Georgia,]So, in order to create our lighting effect, I have a CCRenderTexture that covers the screen and is black. Then, every tick, it gets updated according to whether there are lights currently visible on the screen. It's always good to narrow down how much you are doing in a tick method to help keep performance high.[/font][/color]
[color=#000000][font=Georgia,]My update tick works something like this:[/font][/color]
Begin drawing on the CCRenderTexture
Clear the CCRenderTexture with black to make it look dark
Set the color mask to ignore everything but the alpha channel
Find all of the lights that are actually visible on the screen. This narrows down how much drawing is being done.
Draw the visible lights (CCSprites have a 'visit' method)
Reset the color mask back to normal
End drawing on the CCRenderTexture
[color=#000000][font=Georgia,]Overall this achieves our desired lighting effect, and with a decent amount of testing it's proven to be performance effective as well. Now, our players have flashlights so that they can see the things that go bump in the night.[/font][/color]
[color=#000000][font=Georgia,]Reposted from Fixbot Blog[/font][/color]
[color=#000000][font=Georgia,]This has been one epic week! In traditional game development fashion, this week was crunch week. This week was the week that we had off for spring break, but it wasn't a break for us at Demergo, instead it was 400+ hours of pure game development fun![/font][/color]
[color=#000000][font=Georgia,] [/font][/color] [color=#000000][font=Georgia,]Our Major Features Task Board as of Wednesday Night[/font][/color]
[color=#000000][font=Georgia,]As of this writing, pretty much every major fixbot feature is implemented. There is still plent of tweaking and design perfection needed, but adding major new features is over, and we have finally hit the beta stage!!! Our next goal is a gameplay video by the end of next Saturday, so stay tuned and be ready to see what we have been working hard on for the last 2 months![/font][/color]
[color=#000000][font=Georgia,]This week, the artists finished up 3 of the enemy movement animations, the cutscene animations and art, the character art, the fonts, some of the major story art, and some of the lighting needed for Fixbot. They also finished up the environmental animations and save point animations. They also did a lot of other cool stuff that they didn't tell me about and that I don't know about, but is probably really cool and I should try to find out what it is so that I can I can tell you how cool it is...or you could just buy our game when it comes out in a few weeks and see it for yourself![/font][/color]
[color=#000000][font=Georgia,]The programmers essentially made all of the stuff above work! I must admit, Saturdays seem like engine overhaul day. Today we decided that after fighting with angle code forever that we needed to just go through all the code and use one unified angle system. Some may say, well thats a duh, and we would agree, but cocos2d does angles one way, math does angles another way, and our human minds do angles a completely different way. Essentially we had 3 different angle systems in our engine that we were converting between. It would take us 20-30mins to write the logic and then 1-2hr just to get the angles write. This is a major overhaul that needed to happen sooner, but hey, better late than never (and by never I mean continuously having it break because we didn't convert something and thus having lots of complicated code and lots of bugs with that complicated code). I am sure that Dan will write a post on this sooner or later.[/font][/color]
[color=#000000][font=Georgia,]On the design side, all the levels are designed, and 3 or 4 of the 10 levels are built and in the game, but still need final touches and cutscenes added to them. Zak has been tweaking and redesigning the levels all week to get the perfect user experience and most fun out of each level and each area in the levels.[/font][/color] [color=#000000][font=Georgia,]Thats it for this dev update, look for more blog posts to come this week as those regular posts should be starting up again now that crunch week is over![/font][/color]
[color=#000000][font=Georgia,]Devbot Todd crashing for the night....[/font][/color]
[color=#000000][font=Georgia,]Repost from Fixbot Blog[/font][/color]
[color=#000000][font=Georgia,]Well, Saturday has come and gone... like 3 days ago, but things have been so busy around the office that finding time to even sit down and write up a simple status update can be hard to fit into the schedule.[/font][/color]
[color=#000000][font=Georgia,]Saturday was very busy. The artists were hard at work, working on more environmental tiling, environmental hazards and animations, enemies and enemy animations, and much, much more. Hopefully Omni will have a blog post coming soon showing off all of the cool art that he and the rest of the amazing art team have been working so hard on.[/font][/color]
[color=#000000][font=Georgia,]The programmers were equally busy. We ran into an interesting issue with our level file... it was too big. At one point our level file reached around 1.5mil lines for just one level... yeah, there was a bug involved in that too. We decided to cut the level file into multiple smaller files, and doing that would also help with the early memory spike we were having when first loading the level. I am sure a blog post will come from that incident sometime. Joel has been very busy fine tuning and tweaking the amazing player movement code. One of the greatest challenges of this game has simply been player movement. Joel has spent a majority of his programming time on just player movement. It is essentially a custom physics engine just for our game. Dan has been busy implementing environmental hazards and getting all the animations with those things working. Ian has come over to help me out with the editor as I have been struggling to keep up with the increasing tools demand (and school demand too).[/font][/color]
[color=#000000][font=Georgia,]Zak over on the design side has been busy finishing up the final levels of the game and also using the editor to start making the levels he has already designed. He has also been working closely with Joel to fine tune the player movement code.[/font][/color]
[color=#000000][font=Georgia,]That's it for Tuesday's Saturday Dev update.[/font][/color]
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.[/font]
[font=helvetica, arial, sans-serif]
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).[/font]
[font=helvetica, arial, sans-serif]
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.[/font] [font=helvetica, arial, sans-serif]
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.[/font]
[font=helvetica, arial, sans-serif]
There are other things I use to 'move' like Fixbot, but if I told you those you wouldn't play my game.[/font]
[color=#000000][font=Georgia,] Post by Joel, Programmer at Demergo,[/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] Reposted from Fixbot Blog[/font][/color]
[color=#000000][font=Georgia,] Post by Dan, Programming Director at Demergo,[/font][/color] [color=#000000][font=Georgia,] It's been a crazy week here at Demergo, and we've gotten a lot done![/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] 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![/font][/color] [color=#000000][font=Georgia,] Keep an eye on the gallery, because we'll be posting some screenshots from the tiled levels soon![/font][/color] [color=#000000][font=Georgia,] Reposted from Fixbot Blog[/font][/color]
[color=#000000][font=Georgia,] Post by Dan, Programming Director at Demergo,[/font][/color] [color=#000000][font=Georgia,] 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?[/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] Reposted from Fixbot Blog[/font][/color]
[color=#000000][font=Georgia,] Blog Post by Omni, Art Director at Demergo:[/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] 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)[/font][/color] [color=#000000][font=Georgia,] Reposted from Fixbot Blog[/font][/color]
[color=#000000][font=Georgia,]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.[/font][/color]
[color=#000000][font=Georgia,]Over the course of this week there's a lot we accomplished.[/font][/color]
[color=#000000][font=Georgia,]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![/font][/color]
[color=#000000][font=Georgia,]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![/font][/color]
[color=#000000][font=Georgia,]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).[/font][/color]
[color=#000000][font=Georgia,]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.[/font][/color]
[color=#000000][font=Georgia,]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.[/font][/color]
[color=#000000]Post by Zak, Design Director at Demergo,[/color]
[color=#000000]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.[/color]
[color=#000000]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).[/color]
[color=#000000]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.[/color]
[color=#000000]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.[/color] [color=#000000]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.[/color]
[color=#000000]I'm Zak, and I'm the janitor. ;)[/color]
[color=#000000][font=Georgia,] Posted by Ian Wagner, Programmer at Demergo,[/font][/color] [color=#000000][font=Georgia,] "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.[/font][/color] [color=#000000][font=Georgia,] 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.[/font][/color] [color=#000000][font=Georgia,] 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 [/font][/color] [color=#000000][font=Georgia,] Reposted from Fixbot Blog: http://demergostudios.com/fixbot[/font][/color]
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.
[color=#000000][font=Georgia,]Fixbot Blog Post by Omni, Art Director at Demergo Studios:[/font][/color][color=#000000][font=Georgia,] [/font][/color][color=#000000][font=Georgia,] 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.[/font][/color][color=#000000][font=Georgia,] 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.[/font][/color][color=#000000][font=Georgia,] [/font][/color][color=#000000][font=Georgia,] 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.[/font][/color][color=#000000][font=Georgia,] [/font][/color][color=#000000][font=Georgia,] 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.[/font][/color][color=#000000][font=Georgia,] [/font][/color][color=#000000][font=Georgia,] 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.[/font][/color][color=#000000][font=Georgia,] This has been Omni, (otherwise possibly known as hextupleyoodot), and I am an artist.[/font][/color] [color=#000000][font=Georgia,] [color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]
Someone told me that a designer's job is about making decisions. He wasn't talking about game design specifically, but it seems to fit. In my little bit of experience I would like to add one other thing: designer's fix problems before they happen.
One of the problems we faced with the design of Project Fixbot was limiting player movement. There are times in a level when you need to narrow where a player can go. We do this to help the player find the right path. In a normal platformer this is easy because you just throw a wall at the player and he can't go through. But in our game the player can move on the walls. He can attach to any surface. He moves by launching himself around the map. How can you limit a player that has free rein to any surface?
One of the ways we solved the issue was to limit the angle that the player can launch from. This allows us to steer the player in the right direction. We can now guide the player towards objectives without worrying that he is going to get lost.
So that's my job. I'm Zak, and I'm the game designer. I solve problems.
Reposted from Fixbot Blog: http://demergostudios.com/fixbot/
Aside from the obvious answers: we are humans and we come from the planet earth... well... some of us at least. Who exactly is Demergo Studios? Where did we come from? And why are we here?
It started a long time ago in a galaxy far, far away... on a little known planet called earth, in a little known city called Greenville, SC, where a number of ambitious young college students collided and formed Demergo.
Before Demergo, many of us had worked on smaller personal game projects. We all loved games, and we all loved making games, but individually we were limited on the size and scope of the games we could make. We realized that together we could make a game much bigger than any of us individually. Demergo originally started off with Dan, Zak, and I sitting down, and discussing what we wanted our futures to look like. After a while we all kind of came to the realization that we wanted to make games. One of the best ways to get into the game industry is to actually make a game and sell it. The game industry as a whole is much more experience and knowledge focused rather than degree focused, so starting a company and make games is a great way to break into the industry.
But looking at the three of us there is clearly no art talent among us... none whatsoever! Yeah we are definitely artistically challenged. So we set out to find some artists for Demergo. We found a number of artists that we added on, we also added on some good friends of ours from our programming classes, and we also picked up a few cinema production majors. By the end of our first project, Norwall, our team totaled around 14 people. Thats a lot for a start up.
Well, most of you are probably wondering, "why haven't I heard of Norwall yet?"; well thats because it never really saw the light of day. It was an ambitious project, and very fun to work on, but we made too many mistakes on that project to really recover it. One of the primary mistakes was not requiring work hours. We are all college students and as college students we have no time, so very little progress was every really made on the game. But we learned a lot. We made a bunch of mistakes that we were able to learn from and take those lessons and bring them over to Fixbot.
For Fixbot we required set work hours which immediately eliminated a bunch of people. After that we sat down and re-evaluated our situation. We were down to 8 people (much more manageable of a size), but we were running out of time. Many of us will be graduating in May so we had only a few months to really get something out. We decided to set a deadline, and limit the scope of the game to something we could produce in 3 months.
One month later, here we are, starting to get the word out about Demergo Studios and our current project, Fixbot.
That takes care of the where, but how about the who and the why?
Well, simply put, we are a bunch of college students who want to make video games. We are passionate about making high quality, co-op games with great stories. We are hugh fans of Naughty Dog and how they tell amazing stories through video games. We are also huge fans of Gears of War and Halo with their co-operative play. So, we desire to mesh the two and create games with awesome stories, together with fun co-operative play. Unfortunately, we are not as big as Naughty Dog, but they were not that big early on either. We look forward to the journey that lies ahead of us and we hope that you will join us on this journey as we post about how we do things and various problems that we run into and overcome as we continue this journey of starting an indie game company.
Devbot Todd Shutting Down...
Reposted from Fixbot Blog: http://demergostudios.com/fixbot
Today we are very excited to announce our latest project, FixBot. [/font] [font=Arial]
Project FixBot has been under heavy development for the last month and we are really excited about showing off some of the cool stuff we have been working on. [/font]
The game is a 2D platform-shooter emphasizing multiplayer and puzzles, with a unique movement style. The game will be playable across all iOS devices running iOS 4.0 and later.[/font]
Project FixBot started off as the idea - or as we like to call it, a "spark" - of a gravity platfomer. Something where the player can change his gravity source. As we continued to design we changed the gravity idea to magnetism, and the player became a robot fixing a space station. This got further expanded to the idea of "what if the player could only move by connecting to magnetic surfaces". From there the spark was fleshed out and the game was solidified. [/font]
The release date for project will be April 21, 2012 (pending Apple approval). We will be posting regular updates on the project every Saturday so that you can follow its development. The artists will be posting additional concept art and production art, and the programmers will be posting about the various challenges they faced in developing an engine that solves the unique problems that are involved in making a game of this style. We look forward to getting to know our growing community fanbase while we make this awesome co-op 2D platformer. [/font]