EDI was founded by me, Raymond Jacobs, in around 2002. Since around the early- to mid-90's I'd been a passionate gamer; mostly adventure games, and after long I decided that I wanted to be like the designers I admired and create interactive experiences that moved people too. As I was very young when I started this journey, it was a long while before I had the experience, skill and commitment to develop anything worthwhile, not to mention commercially viable; EDI Games is my first attempt at this.

Morning's Wrath, was EDI's first game title... however that doesn't tell the whole story. I created a non-published adventure game under a different name than EDI Games; but it really wasn't any good. There are however, plans to take the original base story and design and bring it up to date as a new IP for EDI Games, as it represented a very raw, misdirected application of my inspiration and I think there is some value in that.

Well, I'd lurked and posted about it on GameDev.net long before we released it in 2005; those were very exciting times, I was learning a lot about game development and engine design and GameDev.net didn't have many folks working on serious releases; this seems to have changed since then though.

The initial ideas for Morning’s Wrath came out of desperation; I had just scrapped a partially finished game idea and knew I wanted to go for something a bit medieval and epic. Diablo was an obvious inspiration in terms of gameplay; but I also mixed it with a lot of traditional adventure game concepts. In writing the story; I took the standard cliché, of a princess whose kingdom has come under attack, but mixed in a magical well, which granted immense power but at the cost of your health and sanity. Princess Morning would have to sacrifice herself to save her kingdom, but instead of dying she would have to live with her sacrifice.

Morning's Wrath was much better received by critics than I would have thought; due to the dated graphics. Our reviews were quite good and we routinely get emails from gamers telling us how much they like it. We have a gamespot user score of 7.4 and a PC GameZone score of 7.4. Sales were modest, selling around 500 copies independently; and a few hundred more through resellers such as Stardock; as well as doing a distribution deal with Game Tap.

Yup, we still sell Morning's Wrath, though the site is currently down for redesign since Morning's Wrath 2 is nearing :)

We sell a handful of copies each month; being four years old now, I think it has excellent staying power; and with Morning's Wrath 2 coming it should only energize the original.

Being our first game, management wasn't what it should have been; so there were many of folks coming and going; but there were some whose efforts really made Morning's Wrath possible...

• Raymond Jacobs - yours truly - probably a bit of bad form to put myself first, but I ended up doing the majority of the work on Morning's Wrath, 90% of the graphics and animation; building the engine, over half the writing and gameplay scripting.
• Zach Todd did a lot of writing for Morning's Wrath, primarily the back-story, he also did a lot of level design and gameplay scripting.
• Adam Frechette was responsible for the soundtrack; which lots of folks seemed to really like.
• Jenna Hoffstein did some great work on character modelling; taking my initial works and making them better.
• Morgan Chaput was responsible for the great sketches in the intro and a lot of the in-game items; all hand drawn and scanned.

We learned a ton of lessons while making Morning's Wrath - the first being that a game can't take four years to create! This time-line was the result of inexperience and bad time management. In terms of game engine development, the use of existing, proven tools is paramount; no one cares how hard you worked on your engine, or how many bugs you fixed.

I learned that the gaming press is pretty much just waiting for news; it doesn't take much to get basic notice; so write up a basic press release and some screen shots, email them to key sites and your news will spread. Fun gameplay is paramount to an enjoyable gameplay experience; good graphics that resonate with your target market, is paramount to getting folks to try your game.

After Morning's Wrath, we jumped straight into our second game, The Lost City of Malathedra, which was released Nov 1 2008. I do remember it wasn't that long of a break... maybe a month or two; but work started with the development of a new engine, since Malathedra was a traditional point and click adventure game, but with some modern flair; 3D terrain and pixel shader lighting. This took us three years to create, because we didn't learn our lesson in some areas, and we over-designed in others.

Malathedra was a completely different animal; I had enough with the medieval RPG genre after working four years on Morning's Wrath; I decided a modern semi-realistic adventure setting would be a nice change.

Nope, we used a completely different team; in part because Malthedra was a very different animal which didn't resonate with Morning's Wrath team members. Some team members were just "done" with game development for the foreseeable future – it’s not for everyone.

For Malathedra we had far less team member turnover than with Morning's Wrath; primarily due to enforcing higher requirements of team members to weed out folks who weren't skilled or committed. Malathedra was a three man team:

• Myself, doing all of the art, engine development, most of the writing and half of the gameplay scripting
• Brian Linton did additional writing and did the other half of the gameplay scripting.
• Joe Francis was in charge of Malathedra's soundtrack, which I feel had some really great themes, we'll likely revisit.

Absolutely; the biggest lesson forward was that 'we are now in the business of making games'; it was no longer an experiment as to 'if' we could create and sell a game, we already did that - now we had to try and refine the process.

I developed our second engine for Malathedra; mainly because it was vastly different from the Morning's Wrath engine; and the Morning's Wrath engine suffered from major design flaws and feature creep. A key element in our engine design change was to make the engine 100% data driven, using XML and Lua scripting. In Morning's Wrath we had to muck about in C++ every time we wanted a new feature; we would create a basic adventure engine and use external data to shape the experience.

We also used a lot more 'off the shelf' and proven components to make development fast and stable, the C++ Standard Library, Lua, Boost, TinyXML to name a few. We saw major benefits from this new engine; Morning's Wrath development was plagued by engine tweaking and debugging where there was almost none of this during Malathedra's development.

The folks involved in EDI change drastically from game to game; at the moment you can say that my wife Jacki and I are the two solid members.

STATIC is a real exciting game for us; a complete departure from what we've done in the past. It intertwines traditional adventure gameplay, with gathering evidence of paranormal activity; and some personal scares :)

It is a paranormal adventure; where you assume the role of Julie Masters, a young woman, interested in all things paranormal, who is seeking membership with Berkshire Paranormal, a Paranormal Investigation society based in the Houghton Mansion in North Adams, Massachusetts USA.

The Mansion was the scene of a gruesome tragedy in the early 1900's where Mary Houghton was killed in an automobile accident when her chauffeur John Widders made an error and the soft-shoulder of the road collapsed, sending the vehicle down a cliff. John survived the accident; only to commit suicide a day later with a horse pistol; not long after that A.C. Houghton Mary's father died mysteriously as well.

Julie is granted an opportunity to investigate the mansion; and if she does well she'll become a member of Berkshire Paranormal. As she investigates the mansion and its surrounding areas; she begins to discover there is more to the history of the Houghton Mansion than first met the eye.

Jacki discovered Berkshire Paranormal and the Houghton mansion; while she was looking for some local stories to base a game from. We both attended once of their fall events, where you can investigate the mansion; we approached Nick Mantello (head of Berkshire Paranormal) and he was excited from the start. We worked closely with him to understand the history of the mansion and Jacki wound an interesting twist into the historical accounts of what happened there.

Jacki wanted to do a paranormal investigation game; and we felt that using footage instead of drawn/rendered characters and areas would help to convey the mood and show people that it is based on real life happenings. In addition to that; we were able to capture the beauty of the mansion with very little effort; modelling and rendering an equivalent of it would have been costly and time consuming.

Absolutely; it was our first game of this kind; so we had to develop some special ways to capture video and photograph scenes to get what we needed.

There is also way more of a 'human element' in doing a game like this; props, clothing, acting direction, schedules; photo releases, location releases; waivers of personal injury, etc. etc.

Absolutely; it is very rewarding and it seems as if folks like it; Jacki is taking the holidays off, but then she'll be back working on STATIC 2; which is set in Salem, Massachusetts

Due to the nature of the game, it had the most human involvement of any of our games - but as for developers, it was Jacki and I.

Writing: Jacki handled all aspects of writing, from initial idea to complete design document; the design of STATIC was meticulous.

Programming: I handled all the programming for STATIC; compared to our two previous games, programming was the least time consuming process; mainly due to our new engine Selenite.

Location work: Jacki handled the on-location relationships with Berkshire Paranormal; while I handled the business side of things.

Casting: Jacki handled all casting work, including planning/coordinating filming schedules and photo shoots

Technical: I handled all of the technical aspects; video equipment, specialized editing tools; even the preparation of a chroma-key green sprayed tread-mill that would capture realistic walking cycles from actors.

Voice Talent: Jacki was in charge of writing all the dialogue; instructing voice actors and the capture process; I was in charge of processing audio for EVPs and other special effects.

Costume Design: Jacki handled most of the costume design/ preparation for the actors.

Video Processing: Jacki and I both shared the work of processing source video into sprites; which was very labor intensive.

Additional Graphics: I handled all the special effects work and additional graphics; as well as processing a lot of photographs for in-game use.

Filming Direction: Jacki instructed all the actors; I oversaw the process and chimed in about any technical implications/limitations.

Actors:

• Laura Frechette - Julie Masters
• Nick Mantello - As himself
• Tara McCaughey - Lindsey
• John Erickson - John Widders
• Shana Goodman - Mary Houghton
• Billy Grimaldi - A.C. Houghton
• Brenda Grimaldi - Cordelia Houghton

Yup, engine development is a good piece of what we do at EDI Games.

There are a couple of reasons; one being, I personally enjoy engine development - and now, three engines in, I am also rather good at it. While at EDI we develop games, we also aspire to be a game engine/middleware company; this is going to be more apparent in early 2010 when we start licensing Selenite to the public. We already have some valuable folks set to be early adopters of Selenite, a notable celebrity would be Dave Gilbert and Wadjet Eye Games (of The Shivah and Blackwell series fame).

I also feel that most 'serious' game engines these days are still far too complicated and generalized; what we need is 'RPG Maker and AGS' for commercial games, and that is a big part of what Selenite brings.

Absolutely; there are major benefits to using stable third party technology. We’re currently using Ogg/Vorbis, Lua, AnnoSoft, ScintillaNet, NSIS, Box2D, Subversion and of course DirectX.

The main feature of Selenite is to remove as much drudgery as possible between a game concept and resources, and a completed game.

Selenite presents the developer with a basic world, formed out of rooms; and within the rooms exist actors; actors can be anything from scenery, to sound emitters to full interactive characters.

Selenite also provides the following features:

• event driven scripting
• subversion integration
• integrated one-click installer maker with dependencies; share your game the moment you've got something to share.
• a physics enabled world
• copy and paste ability of elements at every level of design.
• WYSIWYG design concepts
• a traditional adventure inventory
• integrated dialogue choice system
• XML based project storage; know that your project data is parsable should you want to process it with external tools.
• spatially aware audio system
• a class/instance architecture to allow component design.
• a robust scripting API with waitable functions for ease.
• programmable shaders
• localization editor for multiple languages, auditing dialogue and integrating voice talent.
• skinnable user interface
• video/cutscene system
• multiple output platforms: Windows PC/Web/OS X (with Flash, iPhone and XBox360 forthcoming)
• game object centric resource system; no resource duplicates or file name conflicts ever again, due to cryptographic hashing of resource data.
• game project local resource cache; no linkage to external resource import source.
• integrated instructions/tutorial system
• feedback system; users can provide voluntary feedback in the field through the game over HTTP to a web CGI
• error reporting system; users may report errors to you with a concise actions journal to better diagnose issues.
• statistical tools, script code line counter; code distribution stats and class/instance ratio

It allows us to build games, really, really fast; it is as if developing a game has become just another application. I can sit down, pop open Selenite and load my game project, and just start working away at it; no lengthy compilations. It does the hard work and lets me concentrate on adding gameplay features.

First off, Selenite has been our fastest developed engine, with development starting Jan 10, 2009 and being feature complete around July 2009. Also factor that in we developed a good portion of Morning's Wrath 2, and STATIC: Investigator Training during this time.

The biggest challenge when developing Selenite has been to create a really good game design system. In game development tools are key and I had to deal with the age old question:

“an external editor that exports to an engine? or an engine with a built-in editor?”

I decided to go for an external editor; I didn't need the editor (which is a huge part of the time spent on Selenite) mucking up what could be a very small and elegant engine. Given our goals for having multiple engines for various platforms, keeping the engine light was essential. A lot of the groundwork for Selenite was laid in the Malathedra engine; in short, how to represent a game entirely as data, without needing to dig into real code for each game.

Absolutely; we have plans for an early 2010 roll-out to early adopters; and we've still got some slots open if anyone serious indie developers are out there.

Once we've decided on what the game is about; how to lead into it, what you'll do in the game and how it will end; we work to flesh it out in extreme detail. We write a design document which meticulously details the flow of the game and what can be done in it, because "if it isn't in the design document, it's not in the game", a common motto around here. This is also a point where we 'assetize' the game, to create an asset and deliverables list, mainly for art and other things, sometimes sound and music.

Then we go hunting for folks (many times in the GameDev.net help wanted forum) who are interested in working on the game; everyone from volunteers looking for their name in the credits to contractors making a couple hundred up front. I then coordinate all of the resource producers, making sure things are done in the proper order and to spec. I usually integrate assets into the game, as I tend to program alone these days.

We set realistic deadlines and adjust features and timelines as necessary to maintain quality and keep close to our intended deadlines. Once we have elements worth showing we begin to leak information to the game press via e-mail press releases.

Once we reach a 'feature complete' stage we begin the polishing stage and get the game sent off for an initial round of usage and bug testing; we have a small group of dedicated folks that beta our games, we've recently named it 'The Copper Group' and there is a Google group dedicated to it so we can communicate easily.

I'd say we're about half adventure and half RPG; what really excites me about RPG is the focus on gameplay mechanics and action; rather than just predetermined story common in adventure games. Certain stories need some heart pumping action; and a lot of gamers like that, so we try to cater to them as well.

For the past, games like the Kings Quest series, Diablo, the Monkey Island series and Phantasmagoria, have all been heavy hitters for my inspiration. Modern day, I've taken some cues from Gish; Gears of War, Penumbra and The Lost Crown.

Story is very important in our games; it is there to convey emotion and build an understanding with the player; to personally invest them. We also try to let the player draw their own conclusions at points, sometimes saying too much is bad - when it comes to story what the player can imagine is almost always better than what you can fabricate.

It really depends on the game; but for our adventure and adventure/RPG games story always comes first, as it is such a large part of the game. We're working on some casual titles which don’t really have any story, so there’s the contrast.

There is often way more backstory than we can practically get in game; this was particularly the case in Morning's Wrath. We have mounds of stuff which didn’t make the cut, but it serves as good material to use in subsequent games. We've never been good with 'lots of zany characters' kinds of games, we try to keep things relatively solitary; most of our games, notably Morning's Wrath and Malathedra have some heavy undertones in them if you look deep enough.

For stories, I usually bounce them off of gamers; and if I hear 'wow that sounds awesome' I consider it a hit. We try to keep fairly restrained in our gameplay innovation; especially in games where it isn't the focus (e.g. adventure games). For Morning's Wrath and the like, user testing was really the only way to insure it worked.

Oh yes, 'the hard part'! The only thing that really keeps me going is that I have a game to deliver - not delivering is not an option! In addition to delivering, it's gotta be good, because otherwise no one is going to purchase it. So really, the drive to finish games and create a quality product keeps my nose to the grind stone. I know it is notorious for indie game developers to lose interest in projects and early on it was the same for me, but once I started treating it like a business instead of a hobby and committed my life to it is when I was able to justify the long hours and tedious work.

When I started, my only thought was 'can I actually create and sell a commercial game', the idea seemed ludicrous to most people I spoke with and not having ever sold anything before the implications were scary. I knew however that, assuming I could hack it, this is what I wanted to do.

Digital distribution is all we do; though admittedly we haven't got into many channels yet. We have used Game Tap and do most of our selling through Plimus which has opened many reseller doors to us.

Absolutely; we're able to develop the games we'd like to develop; with budgets that are very very realistic. The flop of a single title doesn't mean the doors close.

The cash flows are much, much smaller - we can always do with more liquid assets and that is what we're trying to maximize now.

EDI Games is currently able to support 90% of its financial needs - almost all of what we make is re-invested back into the company to create subsequent games. EDI Games is still a part-time gig for me, but I easily put 40 hours into it most weeks.

Absolutely!

Funnily enough, for Malathedra, we experienced a dreaded issue - some pirates modified the games resources in an attempt to make it smaller. However, in doing so, they broke the game! This breakage created a particular issue which didn't exist in the non-pirated retail version; we actually had folks who pirated the game come to our forums looking for a solution; it was a bad side of humanity.

Short of being draconian there is no way to really prevent piracy and even then it is rarely successful; we think it is better to focus our efforts on honest customers.

First and foremost; Morning's Wrath 2 is going to be a very fun, very polished experience. If you enjoy story, and battle gameplay you're going to love it.

From a story perspective; Princess Morning has restored peace to her kingdom but due to her illness from the mana well she's turned rule of the kingdom to those she deems 'better' for the job. The mana poisoning is killing her and she has (outwardly) come to terms with this. However, as in Morning’s Wrath 1 her mentor Haliphen the wizard will show her that to just lay down and die isn't an option as he sets her on a quest to discover the The Northern Altar.

Morning's Wrath 2 will have a much more casual approach; you'll have more freedom to engage in the story; or just wreak havoc on enemies. With that being said, we'll also delve way more into Morning's personality; we didn't much get to know her mind in MW1, but in 2, she's been through a lot from the mana poisoning, and she's gonna soften a bit... and the outcome is going to be pretty unexpected I think.

Both STATIC and Morning's Wrath 2 are our '3rd generation' games and one thing they both exhibit is a massive discipline for development, planning and time management. In the old days, I'd just half bake a story and start in on some graphics; these days, the story gets hammered out first and then it gets put into production, so there aren't many mistakes and surprises.

I am particularly proud of the artwork in Morning's Wrath 2, we managed to get an industry veteran Mathew Skutnik, previously of Cyberlore Studios to do the environmental art and a newcomer, Alexander Zubov to do some additional scenery; they're both responsible for the game looking really nice at this point.

Another great aspect is the physics system we get from Selenite; I decided that almost any new game needs physics and using physics for gameplay and spells in MW2 is turning out to be awesome, leading to very dynamic gameplay and lots of fun.

We were hoping to get it out for the holiday season 2009, but that didn’t happen; Morning's Wrath is our flagship IP and it needs to be really, really good so we're going to take our time on it so we can deliver a quality product. I would expect it early 2010, but for Morning's Wrath in particular, it'll be done when it's done.

Absolutely; we're currently probing the web casual market and all the fun that goes with it. We have a secretive partnership with another developer in the co-creation of a Facebook game as well.

You can expect to see a few free-to-play casual web games (Selenite based) from us in early to mid 2010, where our model will likely be ad-based; and we plan to have Facebook integration for scores and other achievements. We're also working on fleshing out how we can best use microtransactions for dynamic content in our games... and we're also planning to offer small-fee ($4.95 to $1.95) downloadable versions of our web games, for those who wish to play offline; again with Selenite it is a breeze for us to do that.

Our 2009 and 2010 goals have been (and still are) to create more, better quality games, with new and varied IP's to increase our product catalogue. This also means touching other platforms to capture audiences and revenues from those areas; the web, OS X, Facebook, iPhone, XBLA. We've got some ambitious goals, but so far our plans have been really effective with proof from our past record. A major part of this was to stabilize our technology and to get onto a system we can grow, instead of re-invent. STATIC has proved that our system not only works, but also works very efficiently.

GameDev.net was the community where I really started to understand the game development community at large; it was a place to get great feedback on my games and be recognized.

Well, my Journal on GameDev.net for one; it has some very no-nonsense articles on it pertaining to engine development. I also found the programming articles to be particularly helpful when I was just starting out. The help wanted forum can be very handy for finding like-minded help on your next game project.

I have always wished that GameDev.net was less of a hobby focused resource and more of an indie developer resource with more things like the Developer Showcase to urge developers to finish games and provide more avenues to turning those games into sales.

Each and every person who has dreamed of being a game developer has the potential to be one; it just takes time, patience and the undying will to succeed.

My name is Flavien Brebion, 32. I’m French and live in Brussels, Belgium. I am an aspiring game developer, although I currently have a full-time job in a side industry (virtual reality using game techniques).

I’ve been programming games since my childhood. I started around the age of 11 on an Amstrad CPC, then later on an Atari ST, and then moved to the PC. I created various games, including a humorous point & click adventure game, an isometric single-player RPG, and even a sim-city “colonization” game. Most of those games were abandoned but still reached the “alpha” stage and were somewhat playable, although not complete. The main reason for that was mainly shift of interests (from myself or from the people I worked with).

My main and only project at the moment is Infinity – The Quest for Earth. To simplify, this is a space-sim, sandbox MMO, a bit like Eve Online, but twitch-based (no point & click, you directly control your ship). It is directly inspired from the old franchise Elite/Frontier, and one of the main “selling” points, like Elite, is its realistic universe with seamless planetary landings and a massive procedural universe.

Yes and no. When I started to hunt for a job, I decided to specialize myself in one area, graphics programming, as it was one of my main interests. Although I’m not as specialized in the other domains, I have decent-to-excellent knowledge of all critical game programming areas, including networking, databases, physics, game systems, interfaces, etc.

Through research & experimentation. I keep my skills current by researching works from other programmers, watch conferences or reports from other companies online, like the GDC or SIGGRAPH reports. I also spend quite a bit of time experimenting with new techniques myself, or discussing ideas with friends. Also, I frequently watch over advanced topics on game programming sites, such as our very own gamedev.net’s, even if I don’t post as much as I would like to.

I wouldn’t say the very latest, but I upgrade my computer regularly, normally every two years. I’m currently on an Intel Q6600, Vista, 3 GB of RAM and a Radeon HD 4890, however I will change it next year. I can’t wait to get one of those SSDs, hopefully it will drastically reduce my compilation times, especially with a large code base such as mine (nearing half a million lines of code in C++).

My previous project before Infinity was a sci-fi high-speed hovercraft racing game, codenamed “Lightspeed”. It also reached the “alpha” stage of development. One track was playable but the project died due to a lack of content and teammates going off to university (hence having no more time to dedicate to the project). I think it was pretty much at that time that I started to fully realize that relying upon others wasn’t a good idea, especially when they’re not getting paid. Meanwhile, I was working on an experimental procedural planet renderer, and decided that for my next project, I would try to do something that requires as little content as possible (ironically, I’ve never had as much content as I do now for Infinity), which screamed “procedural space game”. I also consciously avoided any type of game that required complex animations, such as characters. Not for programming reasons, but for content reasons (finding good animators is even more difficult than finding good modellers or texture artists).

At the very beginning, it just started out as an experiment. As it grew in complexity, I soon realized it was a perfect candidate for a sci-fi space sim. So for all but a few months, it has always been my intention to make a game from the code.

It’s hard to give an exact date, because while I started early (around 2004 if I remember well), I didn’t concentrate on it until it became my main focus of interest, which occurred around the end of 2005. So, more or less 5 years now. As I already have a full-time job, Infinity is developed part-time, so it goes relatively slowly (when compared to funded projects with a dedicated team).

Programming-wise, it’s still pretty much a one-man effort. A few other people have volunteered to make independent prototypes though (for example, there’s a pretty complex economy prototype that has been in the works for a year). For the rest, there’s a team of 5 other dedicated developers responsible for content development (artwork, sounds, writing). Design is more or less collective.

Finally, there’s also a contribution system. Interested parties are free to submit 3D models, textures, sounds & music . Many have become quite involved and very skilled, bordering on professional quality level. So we’ve received a pretty insane amount of contributions from hundreds of people, and even if only a fraction of those will eventually get into the final game, that’s still more content that I would have dreamed of at the beginning.

Since the core team is quite small, the work is naturally split depending on each developers competences. We all work remotely. Day-to-day communication happens through IRC and forums. Assets management is done via FTP or the website/wiki. I think the biggest issue is communication, and getting people from different time zones to stay in contact, especially when they get busy IRL for various personal reasons.

The idea simply came from looking at Elite: Frontier, and thinking, “How did they achieve such an amazing technology (a realistic universe with seamless planetary landings) on two floppy disks, 15 years ago” ? That’s how I started to investigate procedural techniques and terrain generation/rendering.

The algorithm itself is pretty straightforward, although the details require a lot of attention. It’s based on a quadtree subdivision, similar to geo-mipmapping (although at the time I wrote it, I had no idea what geo-mipmapping was). One of the key differences is that it deforms a spherical surface instead of a flat plane. It’s pretty much like a cube morphed into a sphere, then displaced by a heightmap. Of course, the real difficulty is the 1001 little problems that appear when you want a realistic seamless planet. Such as, handling of gaps between terrain patches, handling lighting, generating heightmaps, normal maps and textures procedurally, keeping a high-resolution precision to have a real-sized planet, etc.

Fairly important, but not to the point of not having to look good, artistically. Immersion is probably the most important factor. For example, Spore uses a similar technology, but the planets feel tiny/cartoonish, almost like toys. In Infinity, I wanted to have real-sized planets, that the players can explore for hours, if they so desire. The sense of scale is something that very few games have successfully achieved, and I think Infinity will be particularly impressive in that area.

No, Newtonian physics is restricted to ships and human entities. However the universe is based on modern astronomy/astrophysics knowledge, using Kepler’s stable orbits. Statistics are used to control the proportion of procedural bodies appearing in the galaxy. You will be able to find gas giants, multiple-stars systems, rings/belts of asteroids/dust, icy/barren/volcanic planets, and of course Gaian (Earth-like) planets. They’re based on real theories, so you will not find a Gaian planet outside its star’s habitable zone for example. All these bodies move in real-time, so it’s possible to attend a sunset over the mountains on an alien world.

True. I read astronomy/physics magazines regularly every month for the past 6 years. When implementing new space features I take at least a few hours to re-read old magazines, search on the web for statistics/pictures to give me a good understanding of what they are and how they should look. However, I’m not stubborn so if something doesn’t go as planned, or if we discover in beta that it just doesn’t work/isn’t interesting, I have no problem adapting to make it more interesting and fun to play. Realism and immersion, yes, but not at all costs. One typical example are Gaian planets. They’ll probably be more frequent in-game than in reality, because they’re also the most interesting type of planets that players can explore and interact with.

As you can imagine, working with a single type of unit doesn’t work. I use a hierarchical system of units. At the galactic level, light-year (LY) units are utilized. At the star system level, the kilometer is the base unit, and coordinates are represented by double-precision floating point numbers. At render time, vertices are generated as single-precision floats, but translated into camera space to minimize the loss of precision due to large numbers.

Pretty much from the beginning, after I wrote the first prototype of the seamless procedural planetary engine. A procedural sandbox universe is a very interesting challenge design-wise, and a perfect setting for a sci-fi MMO, so it was a natural choice.

A bit of both, actually. The shard design is similar to Eve Online’s, but due to latency reasons (the game is twitch based, not point & click), there will likely be at least 3 shards, in Europe, USA and Asia. For financial and practical reasons we’ll probably launch the game with a single server (Europe) and expand as needed.

Scalability and complexity of development (with various server nodes sending messages to each other, asynchronously). The server isn’t finished yet, but so far I’d say scalability is and will remain the major concern. For example, the server has to perform collision detection since the client cannot be trusted in an MMO. It’s pretty complex, since our ships have different hit zones (each thruster, each weapon, and even different hull sections). When balancing weapons, you have to take into account not only the type of weapon, the damage it does and its other effects, but also how much it will stress the server due to a high firing rate. Keeping the amount of SQL requests low and caching the data is also a concern.

Yes. It’s based on UDP, with a reliable layer for messages that need it. I use a few other external libraries like curl for HTTP requests or downloading patches.

There will be no more updates of the ICP, since maintaining it would require work that is better invested in getting the actual game out as soon as possible. The primary goal of the ICP was to test the network model, the Newtonian physics/controls, and get a feel of what the combat would be like. A secondary objective was to release something to the community to keep it motivated while waiting for the development cycle to culminate to launch. To show that there is light at the end of the tunnel, and that Infinity is not just another vapourware project.

I’m using many third-party libraries. OpenGL/DirectX for rendering, OpenIL for loading images, OpenAL for sounds, ODE for physics, TinyXML for XML files, squish for DXT compression, Curl to download files/access the web, ZLib for ZIP compression, and probably a few others that I forgot to mention.

Yes, it has been the plan all along. Unfortunately, it requires the engine to mature, especially in the domain of documentation and tools, and I prefer to spend my time on Infinity development to get an alpha out as soon as possible. But it will be done, eventually.

The size of the area of play may look huge at first, but in reality the actual area where you’ll find quests and NPCs is much smaller. It is concentrated in the populated regions, whereas the rest of the galaxy is just here as a bonus for the explorers at heart.

For the story, we started with a rough plot and began to refine it. Our goal is to create a rich and immersive universe, with complex political intrigues, tensions between various factions and sub-factions. We want to offer players all sorts of missions, some procedural, others much more advanced and context-dependant. One nice feature of a procedural universe is that you can get rid of static spawns of NPCs, so even generic missions can push you into unknown territories.

Both! The single story part is still experimental, and it’s not even written yet. However, our plan is to propose an evolving scenario similar to the one of a solo game, except that it wouldn’t be focused on a specific player. It would be split into chapters, and there would be objectives to reach, that could be accomplished by any player. Of course, it’s not mandatory to participate in the main story.

In addition, there will be tons of smaller missions, some will be pretty generic, but many will be more advanced, and may even be related to previous missions or be context-sensitive. We’re also looking at creating some PvP missions, two (or more) players could get conflicting objectives at the same time and would have to compete to win.

There are three main factions. The Centaurus Oligarchy, the Deltan Federation and the Star Fold Confederacy. They’re all human. We decided early on against introducing alien races, as they are cheesy and overdone in most games/movies, and also require dedicated content. In addition to those, there will be dozens of smaller factions and organizations, corporations of conflicting interests.

That’s a hard question, as the definition of fun is different for every player. In general, I think trying to make a game fun for everybody is the best way to ensure that it isn’t fun for anybody. So our main goal is to make it fun for ourselves and hope that many gamers will share our vision.

More specifically, there are features that we absolutely want to have in our game and that are part of our vision of what “fun” is, and will not change. For example, the twitch-based combat (you fly your own ship directly, and don’t just point & click and watch the battle). The Newtonian physics. The “Star-Wars” short-range combat with explosions and special effects. The seamless immersive and realistic universe, with planets/moons orbiting in real-time. And the freedom to explore the galaxy without being bottlenecked by jumpgates, etc.

Infinity is primarily a sandbox game, so there’s a lot to do for many kinds of players. While combat will remain an important part of the game, we don’t want to make the mistake of proposing an empty sandbox, so there will be plenty to do otherwise. Trading, prospecting, mining, developing a business/industry, transporting, crafting, exploring, etc. And of course, all the missions/quests related to the story/factions.

This is very true, but the game is designed around what we call “cores”, geographical zones of the galaxy where the human populations are located. That’s where you’ll find cities, NPCs, quests, services, social activities, etc. That’s also where the new players start. We fully expect that players will cluster around those zones. Finally, there are other game mechanics to ensure that exploration of deep space is not without danger. For example, refuelling involves ram-scooping a star or gas giant, as there is no nearby space station to refuel at.

The Unknown. Since the galaxy is procedurally generated, there’s a chance to see things that nobody else in the player base has seen (including the developers). It’s also possible to find rare ore deposits or visit strange new places. Some of those may be directly involved in the storyline, like the “quest for Earth”, whose location has been lost.

Yes, I think that will be a very important part of the game. We will provide all sorts of tools to encourage players to group and/or interact with each other. For example, ships can be equipped with various sensors/scanners that detect the presence of other ships/entities, based on the energy emissions (so stealth is also possible). Players can form corporations/organizations, share ships/stations/cities, set up their own rules/laws, join squads for missions, or for large warfare, in fleets.

Our current plan is to use a 3-tiered system. Standard navigation for low accelerations. Warping for intra-system navigation (planet to planet), up to lightspeed. And finally hyperspace jumps for inter-stellar navigation or long-range planetary jumps. We will try to balance the game so that it takes no more than a couple of minutes to jump from a star system to another.

There are also HIPs (hyperspace interstellar portals) that link the cores together. Here we are speaking of long-range interstellar navigation, which is otherwise not accessible to the ship’s jumpdrive in a single jump

Very important. It’s probable that Infinity wouldn’t have progressed to what it is today (and what it will be tomorrow) without its community. In addition to giving feedback on ideas and designs, the community is directly responsible for the majority of the content in the game, through the contributions system.

Sometimes it feels a bit overwhelming. The community has helped a lot, but the hype and the expectations are so high after all these years, that I’m concerned there could be some disappointment and frustration for some when the first version of the game is released for testing. The game cannot, and never will be perfect, and everybody has their own personal vision for the game.

There is no external investment. I’ve been saving money for a couple years to be ready for the launch of the game. My plan is to start small, maybe with a few thousand players to limit the costs, and grow over time, add new nodes to the server so that it can support more players. In that respect, I’m glad that the game hasn't become that well known outside the hardcore communities, because if it had millions waiting, I sure would have to revise my plans.

It pretty much “just happened”. We aren’t actively marketing the game yet, but if a magazine or website wants to do an interview or speak to us, they are more than welcome.

It will most likely be based on a small monthly subscription fee with an unlimited time trial. Digital download only, no box sales, no initial costs.

Microtransactions seem to be well received by casual gamers, but are frowned upon by the hardcore gamers. Infinity being a niche game relying on word-of-mouth, I think it wouldn’t be wise to go in that direction.

The alpha test should start in 2010, but will have missing features. The beta will probably be open to everybody (although limited in number of places), but I think it’s unlikely to happen before end 2010, or even 2011. As for the release… when it’s done!

Gaming - recently I’ve been playing Dragon Age and Left For Dead 2; watching TV series such as House MD & Dexter and reading – I’m a fan of Isaac Asimov.

As a disclaimer, what I’m about to say only applies to my experience of working as an indie developer with a team of volunteers over the net.

I would say that the most important thing would be to start small and to grow slowly, and to avoid reliance on others as much as possible. Ideally, as a programmer you’d have all the skills to complete the programming side by yourself, and use stock art/music that you could replace with “real” content once talented people join your project. Sometimes I see a project leader that tries to get 20-30 people as early as possible, and I can’t help but think, “this project is doomed from the start”. Finally, you have to stick to the decisions you have made in the past, even if they’re not necessarily the best ones. For example, maybe you’ll discover that the 3D engine you’ve been working with has some limitations you didn’t envision. Work around those limitations, don’t just decide one day to switch to another engine, or worse, make your own.

The Cutscene Editor is a tool for creating realtime cutscenes in Unity. It's inspired by existing video editing applications like Final Cut and Adobe Premiere. The developer places media clips (animations, audio, etc.) on a timeline, where they can be rearranged and trimmed. None of this requires scripting, meaning that veteran game developers and traditional filmmakers alike can pick up the tool and create a cutscene right away. The ability to easily modify clip timing on a timeline will hopefully allow developers the same freedom of experimentation that filmmakers enjoy, which in turn will hopefully lead to more engaging in-game cinematics.

A goal of the project is to present the developer with a user interface that’s as user-friendly as Unity itself. It’s a lofty goal, and one that might take a while yet to achieve, but it’s certainly attainable.

I'm a recent graduate of Vancouver Film School and a current student at the University of Waterloo, where I'm partway through a computer science degree. Despite being an avid fan of the Unity game engine, I don't actually play very many video games myself; a few games of chess a week against the computer are about all the gaming I get in. I find their potential though as an art form fascinating. Human-computer interaction and interactive media are topics I find very interesting, and in the future I hope to explore new and novel ways for developers to build engaging experiences for their audience.

I've been tinkering with Unity since it was released in 2005. I have yet to complete a full game — most times I start one then drop it shortly afterwards for another when a new idea strikes. I have a folder overflowing with half-completed projects. Only recently have I been exploring the ability to extend the Unity editor itself, which oddly I've found more rewarding than game creation.

As far as coding goes, I've been doing a little bit of everything since secondary school. I’ve done a fair amount of Java programming in the past, which has made learning C# (one of the three languages in Unity) a breeze. And while arguably not coding, I've spent many years building websites using all the usual languages.

I'm a huge fan of programming and an even bigger fan of cinema. If you're a filmmaker there's fantastic tools for cutting the footage you've shot, but if your films happen to be inside a video game then your options are limited. As game projects grow in scale I imagine the expertise of traditional filmmakers will become an essential part of building cutscenes, and they’ll demand tools as flexible and powerful as the ones available in the film industry. I figured I might as well start building those tools.

And I must say, I’ve sat through many a terrible cutscene. I realize they’re not easy to make, so hopefully my project can help.

The Cutscene Editor doesn't do anything new that can't already be done by a developer and several scripts. What it provides is a visual environment to build your cutscene, which I think is a more natural way of putting one together. I honestly don’t know if other tools like this exist; as far as I’m aware it’s the first of its kind for Unity.

Unity is the glue that holds all the elements of a game together. You get a 3D environment, a physics engine, an audio and video playback system, and a slick user interface to tie it all together. The excellent asset importing system provides a smooth workflow for artists and developers to collaborate. Basically, Unity takes care of all the stuff you don’t want to do while building a game and allows you to focus on the fun part of development (relatively speaking of course — if you have no love of programming, Unity won’t suddenly make writing code pleasurable). It's about as easy to use as a game authoring tool can foreseeably be without limiting the developer's creativity.

I was just becoming interested in game development when Unity rolled along. Its ease-of-use was attractive to a newcomer programmer like myself. I didn’t have to compile every time I wanted to tweak a value; I could just hit play, make changes, and see the results instantly. Making a game before was something that would take me a month and still look like garbage. With Unity I could make something that actually looked and played decent in a weekend. It allowed me to do things I previously thought to be the realm of professional game studios only.

I’m mostly interested in web deployment. High quality 3D games are a rarity on the web, and it’s an area that I think has huge potential. Social networking sites like Facebook and MySpace have enormous amounts of users who love to interact with each other, and video games are a great way to have fun with other people online. It’s a real untapped market.

While the web player penetration isn’t as high as it could be, it provides the easiest install of a browser plug-in that I’ve experienced. Web deployment is simply one of the best ways for an indie developer to get their game out and enjoyed; no publisher needed. So while I don't actually make many games myself, if I did that's the platform I would target. A year ago I would have answered the iPhone, but with over 21,000 games on the App Store, getting exposure looks to be an intimidating challenge.

It looked like an interesting competition, and the timing was right. Any other summer I wouldn't have been able to participate, but it just happens that I'm working for the summer as a freelancer and have a flexible schedule. I have a long list of Unity projects I'd like to work on, so the prospect of getting paid for one was attractive.

A local company named OverInteractive Media offered any winners from the Vancouver area a spot in their office to work for the duration of the program, which sweetened the deal even more. Being surrounded by other Unity enthusiasts in a fast-paced startup company sounded like a valuable experience (which, I might add, it was).

Yes, though it would have taken a much longer time. For whatever reason I tend to be much better at meeting deadlines imposed by others than at ones that I set for myself. Time management is easier when someone's waiting to see results. With money involved I treated the project like a full-time job, which I wouldn't have done had I viewed it as a hobby.

Yes, though it would have taken a much longer time. For whatever reason I tend to be much better at meeting deadlines imposed by others than at ones that I set for myself. Time management is easier when someone's waiting to see results. With money involved I treated the project like a full-time job, which I wouldn't have done had I viewed it as a hobby.

I took a look at video editing applications and wrote down features that I felt were essential for editing together a scene. I then thought about how they would have to be modified to work with media in a video game cutscene. I wanted to keep the basic concepts the same. After all, camera shots in a video game and camera shots in a film are basically the same thing. I didn't spend very long in the planning stages, as I had a concrete idea of what I wanted the final product to be when I first applied to the Summer of Code. The day after I learned I was accepted I dived right into the coding.

When I started I had a clear idea of what I wanted to achieve. Once my initial plan was in place I didn't make many changes to it. With more time I might have tried out different solutions to problems, but my mentality throughout the development period was just "make it work." In its current state the Cutscene Editor looks and behaves fairly close to how I originally envisioned it.

I tossed together a small scene with assets from past projects and used the Cutscene Editor to make it come alive. Putting the tool to use gave me insight into where improvements needed to be made, what worked well and what didn't. I tried to approach the task of creating a cutscene as someone first using the editor would.

The interface is responsive and feels natural. The timeline in, say, Final Cut doesn't feel very different from the timeline in the Cutscene Editor. When I started I wasn't sure if I would have difficulty making Unity do my bidding, but fortunately it wasn't limiting at all. Once you understand how the GUI system in Unity works and how it can be used to manipulate objects in the scene you're really able to build whatever you like.

The transitions and filters system is a bit rough around the edges. It's almost just as easy to add a filter yourself by dropping a fullscreen effect onto a camera manually. This was the last feature I worked on before the submission deadline, and it's admittedly very rushed. Lots of work has yet to be done to make this system as easy to use as it's intended to be. Fortunately I don't think it's the most essential feature and some may not notice its crude state.

I made the mistake of working on everything at once; over the course of a day I'd do some coding for the scissors tool, work a while on media importing, and tweak the GUI a bit. In the final week of development I had a lot of features that didn't work particularly well and desperately needed polishing (like the transitions and filters I mentioned above), and I was scrambling to finish them up. Looking back, this most certainly wasn't the best way of approaching the project. A better development path would have been to work on each feature one at a time – build it and make sure it works great before moving on to the next one.

Keeping the feature set limited was a good choice. This project could have easily spiralled out of control if I had attempted to include all the features I want in a cutscene editor.

Designing the GUI was really enjoyable. I've always been obsessed with user interfaces; making sure things appear exactly right tends to be a priority. Most of my interface designing experience comes from building web sites, so it was a nice change to be creating something more application-like.

Trying to get a list of objects of a particular type from the project's assets still has me stumped. I spent a while on this specific problem, and they weren't the most enjoyable hours of my life.

A month and a half was, I think, enough time to complete a project. It certainly wasn't enough time to complete the project I initially had in mind. I realized that from the start though and limited the features I planned to implement.

Customizing the display of subtitles isn't as easy as it could be and will require some effort by the developer to get exactly right. Ideally you could simply drop in a background image and position it on the screen by dragging with the mouse, but unfortunately this isn't yet the case. A seasoned developer should have no trouble getting it to appear as they want it to, but beginners might have a more difficult time. I've read several requests on the Unity forums for easy dialog scripting, and I think the Cutscene Editor could offer a really attractive solution given a bit more development time.

If you have a problem, there's a good chance that it's already been encountered and solved by somebody else. I learned a lot by looking at somebody else's solution. Reinventing the wheel is only a good idea when you have the time and resources to make a better one; most of the time that existing wheel will work just fine.

I’ve never developed an addon of this scale. In the past I've written a few editor scripts that manipulate game objects in the scene view, but that’s about all. Needless to say, I learned quite a lot about editor scripting during the past two months.

At times it was incredibly frustrating. The documentation on editor scripting has a little ways to go. It’s not always particularly obvious what a particular function does – some functions have extensive documentation with example code snippets while others lack even a sentence describing their purpose. Editor scripting is relatively new and not the focus of most Unity developers, so I can understand that this area of the script reference might not be a priority. There's also not a huge number of examples to learn from, unlike actual game creation where there's a wealth of resources.

With that said, just having the ability to create an add-on indistinguishable from the tools the Unity team makes is incredible. I wish every application could be extended so easily. There's been some amazing addons built, and I imagine we'll see many more as time goes on. Every new Unity release makes it easier to extend the editor.

Most definitely. Almost all the projects I hope to work on in the future involve creating addons for Unity.

The Unity forums were a constant source of reference. Answers to a lot of the questions I had were a quick search away. The Unify Community Wiki was also a valuable source of knowledge. It contains a wealth of scripts that beginner and veteran developers alike will find useful.

The Cutscene Editor is far from being perfect, and it has a long way to go until it can match the power of the video editing software that inspired it. I intend to keep developing it as much as possible and add in all the features that got put on the backburner. To hopefully gain some additional developers I plan to place the Cutscene Editor under a liberal open source license and encourage community involvement. I imagine there’s many areas where it can be improved that I haven’t even considered yet.

Absolutely. By being a participant I’ve met a lot of cool people that I wouldn’t have met otherwise, and being able to talk directly to the Unity developers has been a great opportunity. For a student like myself it’s been a very positive experience. I would encourage anyone with a good idea and some spare time to apply when the next Summer of Code rolls around.

If you're a game developer (or have dreams of being one) and haven't yet checked out Unity, I highly encourage you to do so. I continue to be impressed by its capabilities. And the Unity community's usefulness can't be understated. I have yet to find a friendlier, more resourceful group of people.

As for my own project, if it sounds interesting to you and you'd be interesting in helping with its development, I'd love to hear from you. The project hasn't yet been released to the public, but it hopefully will be after Unity 2.6 is released.

The project is about creating an easy way to improve the scene look by adding pre-computed lighting and shadows from external applications. Basically the system creates a powerful bridge between the Unity game engine and rendering engines such as VRay and Mental Ray. This means that Unity game developers will now be able to create lighting and shadows of a quality seen in architectural visualizations incredibly easy.

I’m a second year Informatics student at Wroclaw University of Technology. I’m widely interested in Science and Technology, focussed mainly around Mathematics, Physics, Computer technology and Biology. As a young child I always wanted to make my own game and I tried to learn DirectX at that time, but I needed more mathematical background at that time, so I’ve turned into mathematics and physics for some time. Later I’ve started to develop some software (simple game engines, calendars etc. ) using multiple languages (python, java, c++, c#, maxscript, as3, php) for my own usage from which I’ve published only a small part. Idealist is one of the examples that will be shipping to shops on days.

Some time ago I was earning money on freelance scene rendering and when I first saw Unity I thought to myself that it would be great to have such beautiful lighting on which I worked before in Unity.

Well, everyone has its own light mapping workflow- some less painful than others, but my system minimizes the amount of work needed to bake the scene not only the first time, but also later on when changes are needed.

I would say that Unity is a great tool that both greatly minimizes the amount of work needed when developing games and simplifies amazingly the workflow with other tools (I think that’s what the name is about !) such as Photoshop, 3d Studio Max, Maya and so on.

Using Unity you can spend more time thinking about what your game should be about, rather than spending it on figuring how the engine behaves.

Actually, my friends and I were searching for an good game engine with a quickly growing learning curve and after trying many engines we decided to pickup Unity.

Well, Unity currently works almost everywhere, but I would target PC and IPhone mainly.

My friend Piotr Szwach (great music composer and programmer) encouraged me to send my proposal and I’m really grateful him for it.

Probably yes, but the other and easier way, which wouldn’t be such effective. The competition made me put more effort in its quality also.

A priceless feeling that my effort wasn’t fruitless and this is most important to me.

On the beginning I had to make sure that I’ll not get to any roadblocks, so I’ve planned everything and so the development wasn’t that hard. However later on when I’d got some initial feedback I decided to make the system more general and extendable in future. Whilst the system grew the development got a little bit harder and sometimes made me searching for solutions for hours and even days.

This was one of the hardest parts of the project. I’ve had to do numerous tests to make my system work, but really soon I’ve started to send the project at beta stage to people interested in the project. Lucas (my mentor) also did some testing and was giving me a really quick feedback.

The project really simplifies the lightmapping process and can save a lot of time. I really like the feature for saving light, rendering and material presets that I’ve implemented in 3d studio max.

I didn’t know that there are such huge problems with FBX importing compatibility in 3dsmax, as I developed the system it turned out that only the latest FBX plugin for 3dsmax imports the ASCII FBX file in the right way.

I would feel much better if FBX would have had even the simplest possible documentation when comes to ASCII format. What was probably even worse is that it's easy to find some kind of documentation for the newest FBX 2010.2 version, but there's no chance of finding the old ones.

I would probably develop a binary FBX exporter which has more chances on being compatible. However the good news are that supposedly someone at Unity is already working at some kind of a FBX exporter which could be later plugged into my system instead the current one.

I think that there’s not much to change now – so probably I would do everything the same way.

Testing gave me a lot of fun. The cycle: “Export scene” -> “Tweak lights” -> “Rebake all” -> “Come back and see the changes” -> “Export scene”.... is pretty fun actually.

Reverse engineering Autodesk FBX format was fun, but also very hard and sometimes irritating, so I think that it was the worst part.

Luckily, yes. My family was pretty tolerant in this case and I could start my project almost at any time and end up late at night.

Yes, providing the FBX exporter would be binary I would love to extend the system to Modo – which currently is my favourite modelling tool.

Yes – Do not focus on adding new functionality but rather keep figuring out how to make the old ones faster, more solid working and more user-friendly.

Yes, for instance a batch cubemap creator for materials which should pretend glossy, but I’ve never published it. Currently I’m thinking about adjusting them a little and sharing with the society.

Well, Unity has an enormous amount of examples at the wiki community and one of the existing scripts gave me the idea, which I’ve then pushed forward using the Scripting Documentation which comes with Unity.

I didn’t need any, it was a very basic stuff. However I could turn to Unity Forum and some smart guys there.

Well, there’s more than a lot on my mind recently. First I’d like to finish the game I and some of my friends started before Unity SOC, this surely will take me a lot of time.

Of course! Developing the system gave me a lot of satisfaction and priceless experience.

Get Unity – it’s really great stuff. Get involved in developing it – it’s awesome.

Actually it is the first game I'm making. We’re not out to make a big, huge, glamorous project like games from EA or Activision so we’ve decided not to make a FPS, RPG, or an RTS game. We are trying to make small but not casual game for children. I'm not going to tell you what is the game's plot or who is the main character to keep it still confidential. Although I can tell you which games are the inspirations for us: Thief, Mirror's Edge, Assassin's Creed, Crysis, Wiedzmin, Tomb Raider and of course some Disney-like games.

So what will it be? A platform game with next-gen graphics for children and adults who wish to face up with (or not) the dangerous world while sneaking, jumping, grabbing and solving logical clues designed by 3 of us: me, Peter Szwach and Blazej Stanek with music composed by Peter.

I know making great looking graphic for games is very difficult thing. There are many small indie groups that have great ideas and graphic artists but their final game is simply crappy. Since it is our first project I expect to gain great experience with it. Also we're not going to release any demo until we know it is looking great. The visual quality is very important for us and that is also one of the things why I made my Lightmapping system. Its first implementation was made for our game. After joining Summer of Code I started from a scratch to make it easy for people to use and extend.

The objective of my project was to develop a toolset for the Unity Editor which would streamline and improve the workflow involved in creating realistic terrains for games. It contains a range of 'filter' style tools which allow a Unity artist to easily generate, erode and texture terrain objects.

I worked on the project alone, but had help along the way – both from developers who were willing to share bits of code and of course support from the Unity team.

I actually don't have a background in game development as such. I started out my career as a designer, mostly focusing on editing, motion graphics and visual effects. I later switched into working in digital and I currently work in the role of Art Director at Amnesia Razorfish in Sydney where I've been involved in the creation of quite a few Flash games for a number of high-profile clients including Microsoft, Pepsico and Smirnoff.

I’ve had an interesting in creating games for a long time. I grew up with a Commodore 64 and I remember reading books about coding in BASIC, but none of it really made much sense to me at the time. I wrote my first actual working game in Director about ten years ago while was at university and started to get more seriously into game development about 3 years ago. I've been using Unity for the last 2 years.

The idea behind the project was to enable indie developers to create large scale, realistic and playable game worlds within a short time span. I think procedurally generated content is a great solution, particularly for indie game development projects with limited time, budgets and human resources.

Unity already has a great terrain engine as one of its core features - I believe my project expands on this by providing the user with the ability to rapidly create a variety of different landscapes directly within Unity without needing to use third party software. An additional advantage is that landscapes can now be generated dynamically at runtime. This means a Unity game can have a potentially infinite number of levels with a negligible impact on the file size.

Unity is a game engine with a clean and very user-friendly integrated development environment. I think its strongest feature is in its flexibility. On one hand it allows indie game artists and developers to jump in and start actually creating a game without a long and time consuming learning process – instead it encourages you learn as you create. On the other hand, it does this without becoming oversimplified or by losing any of the more complex features that one expects from a game engine and therefore is a viable solution for small and middle sized teams to develop commercial games.

When I started looking for game engines, everything seemed to be very much focused on the PC platform only. I did try Torque, but found the learning curve too steep and didn’t make much headway, especially due to the need to learn C++ which I had never used before. Unity on the the other hand was available for the Mac platform and was quite easy to get into and start using, especially as I had prior experience in Flash development – Unity Javascript being structurally quite similar to ActionScript.

I also like the fact that it was originally developed for the Mac platform, rather than ported from a PC product. Previous to the release of Unity 2.5 it got a bit of criticism for being limited to Macs only, but when you look at the software now and see the attention that has been given to the interface, the workflow and the user experience, I think you can really see the great benefit that a Mac-centric design influence has brought to it.

I develop for Mac and PC. I haven't really delved into the iPhone side of things quite yet, but I definitely intend to. I’d also really like to have the opportunity to develop for the Nintendo Wii in the future.

I’ve had an interest in game development for quite a while and I thought the Unity Summer of Code was a great opportunity to get more involved in the game development community as well being as a chance to get my name out there.

Yes, for sure. Though, it probably would have taken a lot longer to complete.

I was a bit surprised. I don't think I really expected to be one of the successful applicants. I think it was a great opportunity and I'm really keen to see the response of the Unity community to my project as well as the projects developed by the other participants. I'll definitely be looking into how I can benefit from using their Summer of Code projects in my own games.

I began the project by prototyping some of the more basic erosion scripts. These scripts were originally implemented as ‘wizards’, but once I had a system in place for applying various kinds of filters to terrain objects, I later turned them into filters which could be run directly from the component inspector. I then focused on creating a usable interface for the toolkit and began working on and adding the various planned features.

As early on as possible I integrated features that were fundamental to the usability of the tools such as quality settings, a progress bar to give the user feedback on the application of filters, as well as features such as the brushes. Throughout this time I continued to work on, test and optimise the existing erosion scripts as well as constantly testing new ideas and methods for erosion using more advanced techniques such as velocity fields. I also added the generator tools, which allow for the creation of base terrain using Voronoi, fractal and Perlin noise algorithms. It was quite late in the timeline to add completely new features, but I think the value they added to the project far outweighed the investment in time.

Towards the end of the project timeline my main focus was refinement of the existing features and writing documentation for the tools, including a scripting reference for the runtime API.

A bit of both really. I scoped out most of the features before I started and for the most part I stuck to that plan. However, there were definitely a few completely new ideas that found their way in to the final version.

For this project the testing process was continuous. All of the erosion and terrain generation filters were tested extensively as I refined them. I also wrote some additional code to visualise erosion data such as terrain height, water flow and velocity fields, which were exported as image sequences so I could really see what the filters were doing to the terrain heightmap at each iteration.

Not really, and looking back I think I really should have done so more. Aside from another Unity developer I work with and the guys at Unity, no-one else really got to see it. I did get some assistance indirectly from a couple of other developers who shared some of their code. This meant that I didn’t have to write fractal and Perlin noise algorithms from scratch, which was a big help.

I think pretty much everything in the early stages of the project went quite well. All of the basic features like getting the simpler erosion filters working and creating a user interface for the toolset got completed in less time than I had originally expected. After that everything started to get a bit complicated!

Unsurprisingly, I struggled in trying to understand computational fluid dynamics – shallow water models, Navier-Stokes equations and so on. Without a degree in physics, I didn't get very far. It was too ambitious for such a short time frame. I hope to revisit this in the future to come up with a better solution for hydraulic and glacial erosion.

I also ran into problems in capturing mouse events. I was pretty unhappy with the solution that I had to use for applying erosion brushes. I hope this will be one of the first things to get fixed in the first update.

I would do more research in the early stages of the project. As it was, I did some research to start off with, then jumped into writing code and only got back to looking at the research side of things again quite late in the project. However, by this time there wasn’t really enough time to implement anything new that I was able to learn.

The tools for generating base terrain weren’t part of the original scope of the project, but I think they really added a lot of value to the end product and really helped to create an integrated solution for creating terrain. If I were to do the project over, these features would definitely stay in.

Learning how to create custom component inspectors for the Unity editor was quite cool. My job (during daylight hours) involves a lot of interface and user experience design, so it was satisfying to be able to utilise the full extent of Unity's Editor GUI to put this knowledge into practice.

Writing the documentation was probably the least fun part - tedious, but necessary.

I have enough commercial experience (including some bad experiences!) to know that I needed to start out by setting realistic deliverables for the project. I divided my feature set into 'must have', 'should have' and 'nice to have' features and agreed on a minimum number of deliverable features with the guys at Unity. While I ended up both exceeding the minimum amount and delivering a couple of originally unscoped features, there were still some features that never made it in, mostly due to their high level of complexity. I will definitely continue to support the project with improvements to existing features as well as the addition of new features. Destructible terrain is something I’d really like to see in a future version.

I really wanted to find a better solution for hydraulic erosion that was based on real fluid dynamics but as I discussed before, these simulations were far too complex to include within the time span, they would be a whole other project unto themselves.

I can’t stress enough how important it is to scope the project properly. Set yourself or your team realistic and achievable goals, particularly when there’s a client involved. It’s far better to under-promise and over-deliver than to over-promise and under-deliver.

Unity is a great environment to work in and though it has a reasonably smooth learning curve – like all software it takes time to really get proficient at it, so this was definitely a learning process for me. I think the main challenge in creating tools for other people to use is getting the interface design right. The things that are second nature to you as the developer will probably not be so obvious to other users. For this reason I probably spent only half the time working on the erosion, generator and texturing code and the other half was all about the interface elements.

Yes, definitely. If I create something that is useful within my own projects, then I’m sure that it may be helpful to other Unity users as well. Also, I think there is a real advantage in creating tools and features for games in an ‘add-on’ format. This means that the features will be easily portable and the features they provide will be more high-level rather than being too specific to single game.

Our main line of support for the Unity Summer of Code was an email mailing list. The benefit of this was that everyone was able to see the challenges that were being faced by other participants and be able learn from them. It also meant that most of the issues we ran into were resolved pretty quickly.

I will continue to work on and improve the Terrain Toolkit, but first I’m keen to hear the response of the Unity community to the tools I have developed, as their feedback will definitely affect which features that I add or improve. Other than that, my main focus will be on other projects including getting back to work on a game I have had in production for a while. I also have plans to release one of the planned features of this game as an add-on for Unity. It's a procedural combat animation system, which should be quite cool – if it works.

Possibly, but I'd also be very keen to see what great ideas other Unity developers can bring to the community.

I'd just like to thank the Unity team for giving me the opportunity to get involved in this project, and I also want to thank the community for being so supportive of this great piece of software.

The project is called Detonator, and it's a parametric explosion system for Unity. It helps Unity developers get good looking explosions into their games quickly and easily.

Just myself, though I got feedback from some industry friends as well as a few of the Unity devs, Jonas Echterhoff and Rune Skovbo Johansen.

My Unity experience was minimal before this project. I actually took it on so I could learn it because in the few weeks that I'd spent tinkering beforehand I was really impressed. My prior experience in the game industry includes time at Sony as a Senior Artist and at Vicarious Visions/Activision as a Lead Technical Artist. I then founded the website MrsRiley.com and coded the Flex application for that. I've written a lot of code, but it's been in high level languages like Maxscript, Actionscript3, PHP, and now C#. Really, I'm most skilled as an artist but my interest is focused on making games, whether I'm doing art, code, or design.

I've had the opportunity to create explosions in a few games and I've always enjoyed the combination of problems in lighting, physics, and animation that they present. However, every time I've done explosion effects, the process has been complex. With the rise of the Indie game scene many developers don't have the time to focus properly on effects, but they are really important to the feel of the final product. Prior to the Summer of Code announcement I had just come off of doing some explosions for Marvel Ultimate Alliance 2 for the Xbox360 and PS3. I enjoyed it so much that I was looking for a way to bring that experience into my work again, and the fact that I was starting to get interested in Unity at that time made it all fit.

Detonator can help any Unity developer that wants to incorporate explosions into their game. A solo developer can quickly integrate it like any other Unity component and with zero effort can create a great looking explosion. The effect can easily be scaled, recolored, or its duration changed with a single parameter each. Folks that are more interested in creating custom effects can take advantage of the system's modular nature, arbitrarily piecing together components like fireballs, glows, sparks, heat distortion, shockwaves, and more. The system automatically builds its materials from provided textures, but materials can be replaced as well. Even sound has a place, as the system lets the user define different arrays of sounds for close up and distant explosions with a definable threshold in between. Lastly there's a level of detail system that lets developers tie into the global quality settings or change via distance. It's really flexible and I'm excited to see what the Unity community does with it.

I'd tell them that Unity is kind of like Flash but is built specifically to make games using a 3D engine. Everything about Unity is structured around making a game and removing the annoying, trivial tasks that most developers are unfortunately very accustomed to. Iteration is ridiculously fast, from import pipelines to script compilation, and you can spit your game out to multiple platforms.

Unity caught my eye a few years ago when it was still Mac only, but I didn't give it a real go until they released the Windows version with 2.5. Having worked as a technical artist in the game industry for several years, my job was to build pipelines to help artists quickly and efficiently get their art into games. I read some things about Unity's import pipeline and it blew my mind. It just looked so easy... and it is. I have a great deal of respect for what these guys have done and if I have an opportunity to do pipeline work again I'll be using a lot of concepts I've learned from working with Unity.

I'm currently involved in some Unity iPhone projects with Infrared5, and I'll be doing some webplayer stuff in the future as well. I'm also looking forward to seeing what additional platforms Unity supports in the future.

I saw a tweet from Tom Higgins of Unity. Once I read the description, the concept for a parametric explosion system just popped into my head. I sat on it for a few days but then just took a few hours to write up the proposal. Honestly, I didn't expect to be accepted since I really whipped it out, but when I heard they had chosen it I was really excited.

Maybe if I was working on an explosion-centric game, but otherwise probably not. That's the great thing about events like the Summer of Code. They give developers a reason and incentive to try out ideas that would not otherwise have found a place in their workday.

Well besides just being exciting to be picked, hopefully it means that the project will get enough exposure to continue to grow and live on after release.

Well, first I had to learn the peculiarities of the Unity particle system by making a prototype effect that looked as good as I expected the final system to look. This took a little over a week of working at night and along the way I posted some Unity webplayers on my blog to get feedback. Once we were all excited by the look, I started building out the architecture of the system, recreating each piece of the explosion in code and making the system able to scale the explosion, change its duration, color, detail, etc. This process essentially took the remainder of the project.

The first step in the project was to develop a detailed development plan. The Unity guys and I needed to come to an agreement on what would be built. The final result is very close to that plan, but the implementation details did shift somewhat over the course of the project.

I built a test scene early on and pretty much just used the system in it. I also sent a few beta versions to Martin Schultz of Decane in Germany and he gave some nice feedback a few weeks from release. His feedback was great and his enthusiasm was really reinforcing that Detonator was headed in the right direction. Post release, Slippy Douglas of Nectar Games was kind enough to test on Unity Indie.

Yeah Rune and Jonas at Unity provided some valuable insights, often contributing code snippets in areas that I was confused about. This was one of the reasons I wanted to get involved in SOC and their contributions were very useful. I also got feedback from Andy Zupko at Infrared5, Dan Bernard at Robomodo, and Jesse Brophy at Blizzard, in addition to the great user comments on my blog and the Unity blog.

I feel great about the architecture going forward. This really could be a framework for any kind of scalable composite particle system. I'll put some documentation together about creating additional Detonator Components and we'll see what happens.

I am extremely tired!

Really, nothing. I suppose if I could go back and do my project again, that would mean I had a Time Machine, which I would use to catch up on my sleep.

Pretty much everything. No regrets.

Digging into Unity and reaching a point where I understood the system so well that I'd be confident doing my own game. I've not seen an engine or system that I felt this way about before, so it's really exciting. It was also fun watching my 3 year old nephew Luke play with the test scene. Everyone likes blowing stuff up.

The whole thing was fun. I mean, I was making explosions for video games, right? ;)

It was tight, but certainly a reasonable amount of time, even considering I had a day job.

I would've liked to get a Camera Shake component in. That'll be in the first post SOC release. I plan on continuing work on Detonator for the foreseeable future. More details to come on that.

On this project, getting multiple sets of eyes on the project as it was being built was a great benefit. The model of developing web games is really unfamiliar to those in the traditional game industry, where the game is worked on in secret for months or years and is only seen by the press and internal parties. It's so nice to be able to pop off a prototype early in the process and get feedback. This has been familiar for the web and Flash folks for years, and game guys should take advantage of this as well. So if you're thinking about doing stuff in Unity, get a blog going and start posting as early as you have something to show, even if you're slightly embarrassed by it.

I'm going to continue development on Detonator, make some blog posts about Unity, and get started on some personal game projects. You can follow development on Detonator at http://variancetheory.com/detonator

Just me. I did pretty much everything except for the music (I would have liked to have done that too, but the schedule was tight).

The music comes from Kevin MacLeod’s awesome library of Creative Commons songs (incompetech.com). Hopefully the judges don’t get sick of them – it looks like a significant number of this year’s entrants are using Kevin’s work.

I also had the invaluable help of a number of my friends and my family with testing and advice and such.

It’s a 2D physics-puzzle-platformer, with shadows.

The game is intentionally abstract and linear. There’s no dialog or explicit story or “save the princess” objectives. And there is no player death. The idea is to let the player flow through the game, solving puzzles as they come to them.

From a technical standpoint it is a platformer built around a physics engine, with 2D geometry-based soft-shadows from multiple coloured light sources.

At the start of the competition, the idea of doing something with 2D occlusion just popped into my head. Shadows were the obvious thing to try. I would have liked to try rain as well, but time was limited.

I started to learn to program “properly” in 1999, when I was in high school (I say “properly” because I had messed around with C64 BASIC and QBasic long before then). My family didn’t have the Internet yet, and so I was learning C++ from magazines, using compilers from cover-disks.

Once we finally did get the Internet, I stumbled upon NeHe’s OpenGL website and started game development. After a couple of years learning the ropes I had the opportunity to take over the Stick Soldiers 3 project (incidentally: also a polygon-based platformer) from the original developer of Stick Soldiers 1 and 2.

That four-year calamity could be kindly described as a “learning exercise”. Once I finally killed it off, I went and focused on finishing my degree in Software Engineering, which I hadn’t really been paying attention to.

I also started paying attention to new technology – C# and XNA in particular caught my eye as a vast improvement on the way I had been doing things. So I started learning and working with those, which culminated in me entering Dream Build Play this year.

When I started I was “in it to win it”. The prize money and being noticed by Microsoft for XBLA would be of enormous value someone like me, just starting out as an indie developer.

Now that it’s over, and having seen some of the other jaw-dropping games out there, I’m not nearly as confident about winning. That being said, I’m very pleased with what I accomplished from scratch in just four man-months. I have to keep reminding myself that many of the better-looking games have taken significantly longer.

I would have loved to enter in previous years, but this is the first time that I’ve had the time to spare.

Absolutely!

I started with the idea of doing 2D shadows. This meant a 2D game – and a platformer is ideal for a gamepad-controlled game. A polygon-based (as opposed to tile-based) game would best show off the shadows. I decided it would be best let somebody else’s physics engine handle the required collision detection, and that that would give me physics for free as well.

I dedicated the first month prototyping those two components – shadows and platformer-on-a-physics-engine. This went really well and by the end I had seemingly solid core mechanics.

The next month was supposed to be spent working those prototypes into an engine and an editor. But about half way through I found that the shadow-generating code I had come up with was absolutely riddled with bugs that the prototype wasn’t exposing. It took about two weeks to fix – a huge portion of the four month schedule. From that point on I gave up on any kind of structured schedule and just winged it.

In the last month I brought together a group of my online friends to help me with testing. About this time I started working all day, every day – serious crunch. It was also about this time that I started moving ideas from my head (at least the ones that could be done with the time and technology I had available) into prototypes.

It wasn’t until the last week and a half that I actually started work on the final levels. At this point I was using the programming equivalent of duct tape to patch up all the bugs (mostly performance issues) that having real levels introduced. The game was finished about six hours before the deadline.

Dark is very short – about 20 minutes of gameplay. I had storyboarded twice as many levels. Most of the light-based puzzles had to be cut because they weren’t finished in time.

I had also wanted to have more “critters” in the game. I had designed some interesting interplay between frail, organic, insect-like light-emitting creatures and blocky, solid, shadow-casting creatures. The “triangle man” and the player’s avatar are leftovers from the shadow species.

I would be a bit more careful with the math-heavy stuff. I’d write some more flexible visual-testing code (everyone who has moved from OpenGL to XNA misses being able to just spit out GL_LINES). And I’d probably try to work things out on paper more carefully in the first place, too.

For level dynamics I went with an actors-with-properties model, similar to the Unreal Engine. While I’m sure this works for a huge team of level designers who can’t program, and a huge team of programmers who maintain the system; for me it was one big mess and a lot of work whenever I needed to add a new level behaviour. In the future I plan to replace it with a code-behind, similar to how WinForms works.

I’d definitely start again by prototyping and experimenting with the core gameplay mechanics, quickly and separately.

After the prototyping I’d continue with the very-YAGNI, build-it-directly-on-XNA, minimal-code, rapid development, code-is-the-design (although that’s not to say “badly coded”) approach I’ve found so suitable for game development (except for the “maths-heavy” algorithmic stuff that I mentioned earlier – that, I would be more careful with). It makes my inner software-engineer a little queasy, but the point is that it works well – especially being a one-man shop.

And I’d build a fancy-pants level editor again. It’s a lot of work to have a proper Windows GUI, WYSIWYG, undo/redo support, and the ability to play the game in the editor. However all that effort means that those same prototyping and experimenting techniques can be used again at the level design stage. Plus it means that the highly important results of playtesting can be integrated almost immediately.

Speaking of which: playtest, playtest, playtest!

Yes. In the months before Dream Build Play I made a couple of small XNA games. I also used it as a platform for my thesis at university.

Self taught. I checked out the occasional tutorial and community sample, but by-and-large I simply read MSDN whenever I needed to know something.

I used the Farseer Physics Engine. It would have been insane to try to make my own.

But I did have to bring my own platformer movement system. And I had to fix a few of their bugs myself – a demonstration of how important source-code access is for such a critical component.

In the editor I used some more libraries: one for line-drawing, one for triangulation. The triangulation algorithm wasn’t entirely robust - I spent a lot of time fiddling with polygons to try to coax them into not being inside-out.

C# and XNA is easily the most productive platform I have ever worked on or heard of (short of a full-blown engine). I was able to work many times faster than I did back in the bad old days of C++ and OpenGL.

Some bits of the XNA documentation assume knowledge of DirectX, and expect you to work out the mapping between the two (in other words – in several places the XNA documentation uselessly restates the variable/enumeration names).

Fortunately I know a number of DirectX users who I could ask for help, and I became fairly well-versed in the workings of DirectX myself, towards the end. Poking around with PIX also helped.

The big problem on the Xbox 360 is keeping your frame rate up. I hit this issue three times during development.

A well-known problem with XNA on the Xbox 360 is that the garbage collector is ridiculously slow, such that you practically cannot allocate memory while the game is running. I knew this ahead of time and so hid all my allocations in the blackout between levels. Unfortunately Farseer Physics (the version I used, at least) was allocating memory in a couple of places during updates. The answer to this is to use the CLR Profiler to track down where they happen. Once I realised memory allocation was the problem, it was surprisingly easy to fix.

The next problem was when I found myself fill-rate limited – partially because I insisted on running at 60FPS at 1080p with 4x MSAA – mostly because drawing all those lights and shadows writes to an astonishing number of pixels. I had been hoping to get away with simply culling light sources that aren’t on-screen, but in the end I had to add some pretty aggressive scissoring as well.

Everything worked fine until the DAY BEFORE the deadline, when I found that some of the more complicated levels were making me batch-limited (too many draw calls). I spent the last day furiously adding more culling, as well as tweaking the levels to have fewer polygons in each light’s influence.

In the end, one level was just too slow (about 45FPS) – so I hacked in a flag for that particular level, so that it would run at 30FPS instead of 60.

I moved to 3.1 about 2 weeks before the deadline. I don’t use any of the new 3.1 features, so the conversion was trivial.

Well – there are lots of hints embedded in my answers. But the bottom line is to not forget that you’re making a game. The moment you start thinking of the end product as an engine or an editor or a library or a tech-demo, you’ve lost focus.

Yes. My only complaint about XNA is that it’s not cross-platform enough. I would particularly like to try developing for Silverlight and for the iPhone – at least I can still use C# (I’ve got my eyes on SilverSprite and MonoTouch).

In the last week or two of the competition, the code turned into a bit of a mess, and I introduced some fairly severe bugs into the editor. So I’m going to pull apart all the “duct tape” additions from that mad scramble to the finish line, and fix up a few niggling things that I never had time for.

Then I plan to expand Dark to the size that I originally designed for and put it up for sale on XBLIG (if not XBLA, if by some miracle I get Microsoft’s blessing), and also selling it on Windows.

After that I’m keen on getting something going cross-platform between Windows, Xbox 360, Silverlight and iPhone.

Of course! If I started making game for Windows right now, I’d use XNA. And, seeing as you can port it to the Xbox 360 almost “for free”, it’s a no-brainer. I don’t think I’d target XBLIG on its own – I don’t think the market is big enough.

Screenshots and videos, anyone?