Game development is a lot more challenging than you’d expect. When you’re also focused on college, jobs, and what we consider to be social lives, it sometimes seems damn near impossible. Contrary to what  our severe lack of any updates whatsoever lately may lead you to believe, we are still alive and kicking(even if we aren’t kicking as much as we’d like). In the time since our last update, there was a slight lull in productivity while we took care of some things for our classes, but now we are back into full production mode. We have resumed our weekly production meetings and have set a deadline for ourselves. That’s right, in March 11 – 13, 2011, we hope to be at PAX East in Boston with a working demo of our current title, Echo.

A few months back, we promised a teaser trailer to be released for Echo, and that promise has been kept, sort of. We did manage to complete a trailer, but in the end we decided that it simply didn’t meet our expectations. We were happy with some parts, but others did not accurately represent the level of quality we can achieve. Many lessons were learned during production of the video, most important being not to rush. We will be going back and refining the trailer before releasing it so all of our hard work does not go to waste. In the meantime, we have a short clip showing a portion of the environment that is being used for the trailer, and have created a wallpaper out of one of the scenes, which can be seen at the top of this post. The wallpaper can be downloaded from our Mod DB page at  http://www.moddb.com/games/echo. The preview of our environment can be seen below, as well as on our YouTube channel at http://www.youtube.com/user/ElysianGamesStudio.

To make sure we meet our deadline for PAX East in March, we are all currently hard at work at putting together the demo for Echo, which will consist of a short tutorial and a portion of the first stage. As usual, we are each working on our own areas of expertise.We have upgraded to a newer version of the Unreal Development Kit and are doing our best to make use of powerful new features included with it.

Mitch is hard at work learning the in’s and out’s of Scaleform, a program used in combination with Flash and UDK to create dynamic and intricate menus and HUDs. Scaleform was released with one of the more recent UDK builds, and I highly recommend anyone who is interested producing next-gen UIs to give it a try.

Jeremy, with his odd fascination with numbers and statistics, is currently working on balancing out all the various stats we will need to know while programming the game. Everything from hit points to weapon power to attack speeds must be determined for each character and creature within the game. Once those stats are figured out, they then must be integrated into a the leveling system. This phase of design is especially important, as having unbalanced enemies and weapons is one of the easiest ways to have a broken game. He is also in charge of working on the layout and design for the various stages of the game, which again, involves a lot of statistics and number crunching. Every single ledge and obstacle in the game must be at the correct scale that corresponds with the players abilities at that point in time. If you play our game and get stuck because you met a ledge that you simply cannot jump over, blame Jeremy.

I, for some reason, have taken it upon myself to learn how to program. I have spent the last few weeks researching UnrealScript and C++ to get an idea of how it all works. At this point, I have actually made a fair amount of progress. So far I have managed to set up the side scrolling camera, new controls, and new character movement all through code. Now, don’t let that fool you, I still have no idea what the hell I’m doing, but I’m certainly getting more and more competent. Sometime in the future I hope to post a video of our side scrolling code in action, along with a brief explanation of how I went about setting up the code for it.

Now, time for some more pretty pictures. As per usual, Max is cranking out more creature concepts. We plan to add new sets of enemies and creatures to each stage you encounter. At the moment, he is working on creatures that you will first encounter in the first stage. To give you an idea of what to expect, here are some examples of creatures you will find in game, along with a brief description. Keep in mind that the names of the creatures are tentative for now, we promise we are more clever than that.

So I hope that what you’ve seen in this update is enough to show you that we are in fact still moving right along with our project, and we are more serious about it than ever. As always, check us out on facebook, twitter, youtube, and keep checking back here for updates.

The high poly model of Eli’s Tigris Omni-weapon is now finished. Once the low res version is textured and rigged we’ll finally be able to get it in-engine.

Tigris High Poly Model

Here’s a sneak peak on the environment we are working on for the ECHO trailer. This is without props or any other effects, which we will be adding later. Let us know what you think!

Early Environment Test

I apologize for the lack of development updates the past two weeks, but I assure you it is not because we aren’t getting anything done. Quite the opposite in fact. We have been hard at work trying to meet deadlines for the production of our teaser trailer. This will be a rather quick update. I’d like to write out a very lengthy and well explained update on the processes and techniques that we are using, but that will have to wait. I’d like to be able to sit down and have a well thought out explanation instead of rushing through it. So expect a more in depth update coming soon.

As for our progress, first of all, you may have noticed that we now have an official logo for ECHO, courtesy of Max. You can find it on our Projects page. He has also completed the model sheet for Eli and for Eli’s weapon. He is currently working on more concepts for enemies and creatures, as well as helping create assets for the environment that will be shown in the trailer.

Jeremy is in the process of modeling Eli. The ZBrush model is almost finalized for the most part, and he has begun working on the low poly version of the model. Once that is finished, it will be textured, skinned, and rigged. The sooner we can get that done, the more time we will have to work on the animations.

Mitch has been dedicating  his time to learning everything he can about Adobe After Affects, since his task for this project is to handle the video affects. We have a rough version of the intro to the trailer, and I have to say, we’re all very excited about it.

As for me, I have been working on both building the environment and modeling Eli’s weapon. I created a custom shader in UDK for texturing our environment which makes use of vertex colors and mesh painting. It’s very cool stuff and allows us to get a nice feel to the environment quickly and easily. I hope to have time to write an update explaining that whole process. I have also begun the high poly model for Eli’s weapon in 3DS Max.

Like I said, I apologize for the short update, but keep checking back for a more in depth look into what we’re doing.

“Failing to plan is planning to fail.” This could not be more true when it comes to producing a game. So the topic of this update’s helpful little tip is PLANNING. I know it probably seems fairly obvious that you should have some sort of rough plan before you want to do anything remotely productive, I thought that as well. I was surprised though when I began to see just how many people will dive into a project with either a very vague idea of what the process will be, or even no plan at all. At times I would get started on projects myself, only to realize that I had no idea what steps I was going to take. Its bad enough for this to happen when working alone, but its even worse when working with a group. I’m sure I could fill a at least a page or two with all the things that could go wrong when a group doesn’t have some sort of plan for whatever it is they are producing. I’ve experienced some of these problems myself, and it can be extremely hard to go back and fix them.

So how do you go about planning for your project? I realize this is a very broad question, and it really depends on what type of project it is, how many people are involved, and so on, so I will just focus on how we went about planning for our project. The first step you should take is to really get to know everyone you will be working with. Try to learn their strengths and weaknesses, as well as what kind of worker they are. All of us here are pretty close friends, so this step was practically already completed for us, but for other groups, you may be working with people that you have never met before. Once you have a good understanding of who you will be working with, you want to write out some sort of mission statement. The mission statement is just a short overview of what exactly it is that you want to accomplish by the end of the project. Try to support it with reasons for why you are doing it in the first place. Having a mission statement written out will help focus the team and hopefully keep everyone inspired throughout the process.

Learning the strengths and weaknesses of others is one of what I consider the two most important aspects of planning for a project. This allows you to assign roles to whoever is most qualified for the job, and make sure no one gets a task that they are totally unqualified to handle. For instance, I am not a fan of doing character work, but I love working on environments. Jeremy is sort of my opposite in that aspect. He loves doing character work, and while he is competent at creating environments as well, he would just rather be doing characters. As a result of that information, Jeremy was tasked with creating the character while I work on the environment. Everyone is happy. Again, I know this step seems rather simple and obvious. You are most likely thinking “Of course you assign people the jobs they are good at” and again I will say how many times I have seen a group project where that is not the case. Some groups will just divide up the jobs and assign them at random, which is a good way to make sure something goes wrong.

The other most important aspect in my opinion is setting deadlines. Not just setting deadlines for the hell of it, but actually enforcing them. Now, there are a couple sub-rules that go into setting deadlines. First, make sure your deadlines are reasonable. Evaluate skill levels and use that to determine roughly how long individual tasks will take. Also, if possible, try to schedule in some extra time to allow to make up for any problems that may occur. Enforcing deadlines will help make sure everything stays on track. Some tasks may not be able to be completed until others are completed first. For instance, our character cannot be modeled until the model sheet is created first. If the deadline is not enforced on the model sheet, then it could create a domino effect and throw off everything else in the project.

There are several methods for planning out projects, but for most methods, you will end up using a lot of charts and spreadsheets. The main type of chart we use is called a Gantt Chart. It’s an efficient and easy way to visually plan out tasks and how long they will take. Basically the tasks are listed along one axis, and time on the other. Each task is assigned a predicted start and finished time. I won’t go into any more detail then that, I’m sure if you google Gantt Charts, you will find a much better explanation than I can offer. So we currently have the our process for creating our teaser trailer completely planned out. We assigned roles to everyone and make sure we enforce the dealines. That way everyone knows what to be working on for the next three months without any confusion.

Example of a Gantt Chart

So! Now for the updates on the actual production. We are steadily working on generating the base assets for the trailer. Max is finishing up the model sheet for Eli, which is then passed off to Jeremy for the character to be sculpted  in ZBrush. Once the model for Eli is finalized, Max will begin designing the weapon that Eli will be carrying with him. Before the actual model sheet is done, he will be doing a page of silhouettes. This is both to find a design that we personally enjoy, and a design that is interesting.

Mitch has been tasked with working on all the effects that will be seen in the trailer. This includes effects that will be seen at the beginning of the video and the whole “Coming Soon” deal that is seen in all trailers. Originally, we had planned on doing these effects using a mixture of Adobe Photoshop and Premiere, mainly because we are all familiar with these programs. We then decided that even though none of us have used it before, we could get much better results by using Adobe After Effects. So for the past week Mitch has been learning how to use After Effects so we can use it for our final product. Most of what he is learning can be found here, Video Co-pilot, a great site with free tutorials.

This week I spent my time working on the environment that will be used in the trailer. First I had to decide how I wanted to go about creating it. Originally I had wanted to do the cave in modular pieces, but then decided against it. Because this environment is for a cinematic trailer, it will be created differently than the in-game environments, to compensate for different camera shots and angles you won’t see in the actual game. I would still like to use modular wall and floor pieces for the actual game environments, but decided it would be best to create all unique meshes for the cinematic environment. So I opened up 3DS Max and after thinking for a few minutes, I came up with a fast and effective way to create a pretty nice cave environment. I’ll write out a short tutorial for it.

1.  Block Out Environment

Using basic boxes and extrusions, I blocked out the environment, using a concept as reference. Use this stage to make sure your proportions and sizes are correct. Because this will be imported into the Unreal Engine, I made sure the to size everything correctly by following the rule that 16 units in 3DS Max =1 foot in Unreal.

2. Subdivide

I then went through and using “Connect”, added in edge loops to create more vertices to work with. I kept all my quads fairly even in size because you will be able to see most of the environment, so I wanted the same amount of detail everywhere. If there is an area you will never be able to see, you don’t have to add as much detail there, as it will just be a waste of tris.

3.  Noise Modifier

Add a “Noise” modifier to the top of the stack. Play with the strength of the X, Y, and Z axis, and then the Seed and Scale to get the desired effect. Feel free to go a little overboard, we will control that in the next step.

4. Relax

Add a “Relax” modifier to the stack and turn up the Amount and Iterations. This will smooth out your the noise affect and give it a more natural look.

5. Smooth

I then through on a “Smooth” modifier to correct the faceted look that you will end up with. For mine I set everything to one smoothing group.

6. Fine Tune

At this point, just go back and tweak settings until you get the affect you want. If you go back to your Noise modifier and turn on “Show End Result” you will be able to see your changes in real time with the relax modifier applied. I also went in with the paint deformation tool and sculpted in some details I couldn’t get through this little trick.

7. Optimize (Optional)

Depending on how much you subdivided, you may end up wanting to optimize your model. You can do that with the “Optimize” modifiers that come with 3DS Max, or you could export your model to an external program such as Mesh Lab. Since our environment is fairly small, I wasn’t too worried about the tri-count that I ended up with, so I did not optimize the model.

I wrote this up kind of fast, so if you have any questions or would like to see images of the steps, just let me know.

I then went on to do a quick texture test using a tileable diffuse texture, which was also used to generate a normal map by using CrazyBump.

I will write up more on that later. It is currently 3:30 AM and I need some sleep. So as always, thanks for the support and check back often! We now have links to our Twitter and Facebook, so check those out if you haven’t yet.

You may have noticed in the past couple weeks a significant surge of new Elysian Games content popping up everywhere. You’re probably sick of getting facebook notifications, twitter updates, and for those of you that know us personally, us pestering you through whatever method of communication happens to be on hand. But hey, gotta get our names out there somehow right? Now that the spring quarter has started back up at AIP, we’ll be harder pressed for time, but don’t expect any slow down in production. If anything, being back in classes has made us even more productive.

Over our short break, we managed to meet up almost everyday (usually over the internet. I highly recommend using Skype and Google Apps.) and used that time to get started on our official game document. I have to say, I was not looking forward to this at all. The game document is probably the single most important document you will create during the production of a game. It will contain every last detail of every last gameplay element, such as characters, levels, weapons, stats, and anything else you can think of. Its not uncommon for these documents to be several hundred pages long. Luckily for us, our game is not as large in scope as a major release, so I think we should be able to keep ours under 100 pages. That isn’t to say it isn’t still a huge pain to do, but, alas, it has to be done. You want to make sure you have all your gameplay elements thought out before moving on to any other stage of production. To produce models and other assets only to realize later down the line that you won’t need them for your game after all is just a huge waste of time, and that is something we can’t afford to do. Also, if anyone has any question about the game whatsoever later on in production, they should be able to pick up the game document and find the answer.

So we pressed on, hours at a time, writing out first the backstory of our game universe, and then the backstory of each individual character. It took a little longer than anticipated to nail down a story that was interesting and feasible, but I think it was worth the extra time. Now that we have a richer story than we originally planned, we can find ways to incorporate that into the gameplay more. Having the backstory to the world and characters allows us to move on to designing the aesthetics of them, so they visually feel like they fit into the story. This is where the team will start to split up to work on separate parts of the game document. For example, Max is currently designing the main character, while Jeremy is working on level design and balancing statistics for certain gameplay elements. Although they are working on these individually for the most part, we all go over the work as a group before it is finalized.

I’d like to use these development updates as a way to help other aspiring game developers by sharing our insight and lessons we are learning while developing our first title. I think the first of those lessons should be “Do not take anything personally, and do not hold grudges”. Arguing is a staple of game development, and that is never going to change. I am working with 3 of my best friends, and we argue (read: scream at each other) over design elements on a daily basis. But once it’s over with, we are back to being best friends. You have to realize that it is nothing personal. Everyone wants to make the best game possible, and everyone has different opinions on how that game should be. Your ideas will sometimes be changed and molded into something completely different from what they originally were. In the games industry, its vital to learn to be part of a team and how to accept criticism(hopefully constructive criticism). Now, this doesn’t mean its okay to be a straight up, for lack of a better term, asshole. Always try to be respectful of each other, and make sure you offer constructive critique and can explain why it is you feel strongly about your opinion. Also, don’t just point out the negatives of something, try to include stuff that you do like about it. Telling someone nothing but negative things about their ideas will just discourage them. Your project will get nowhere if everyone on the team resents each other.

Anyway! We do most of the work on the game document every Sunday. During the week, we try to get as much production work as we can. This is only stuff we can work on without a game document, such as a logo and the website. We had a bit of luck this quarter, which should really help out production. The four of us are all in the same Project Management class at AIP, where we also get to work in a group. The goal of the class is to act as if you are producing a game for a company, and to run an advertisement campaign for that title. Not much of a stretch for us is it? We will be using our website for part of the class, but our main focus will be on producing a teaser trailer for ECHO. So you can be expecting the first official trailer to be released in about 3 months!

One of the biggest concerns we have about this project is that none of us have ever programmed a game before. We decided as a group that we will try to program the game start to finish ourselves first, and if that fails miserably (which wouldn’t be a surprise) we are considering finding someone to help us out with it. There is a ton of material out on the internet that serves as a good starting point to learn from, but for someone who has never coded anything before, learning to program a whole game from scratch is quite an undertaking. So tonight I sat down and started to teach myself basic UnrealScript. All in all I think it went very well. I even started to enjoy it, which was surprising to me. So far tonight I managed to set up the folders for our game, get the engine to recognize our custom content, and run our game mode. I also created our own Pawn and PlayerController to be called on by the engine. I’ll go more into this in another update. Anyway, here is a screenshot of ECHO’s very first line of code! Not very exciting, I know, but to us this is like watching our baby’s first steps.

Our first line of code!

So as this is our first development blog, I didn’t really get into much detail about anything. This served as a way to get everyone caught up to where we are now. In future updates I’d really like to go into detail about specific problems we encounter, including technical details and how we solved them. I really want this blog to be a resource for aspiring game artists to use and reference when working on their own projects. So check back every week for another update!

Now that our new site is up and running, we are working on putting together a more detailed overview of our current title. This will be released along with even more concept art showing off more environments and creatures. Head over to the Projects page and check it out.

The new Elysian Games website is currently under construction. It will be undergoing a face lift over the next couple weeks as new content is being added. We will also be posting new content and details for our current title, ECHO.