Game Dev House: A New Approach to Workshops

In this article, game developer Erin Margolis discusses why she feels game design workshops are still useful experiences in an age full of online courses and describes her recent experience running a game jam at Game Dev House.

In this information-filled age, there is no lack of access to articles, tutorials, and courses. However, there is a lack of human empathy and people who can listen and understand one another. Workshops are a playing ground where gamers and players can connect and practice use of what skill sets they have, but more importantly gain social interaction and share personal experiences.

Anyone can find all of the information that they need on their own online, but there is a synergy in forming communities. Community, in the truest sense of the word, is about growing and sharing.

Articles that inspire, new software that helps to guide a person’s vision, group discussions that engage where others can be heard: This is all community. It’s a place of substance and can be a powerful place for people to create alongside one another and advance to the next step.

Game Dev House ran a game jam on June 29th this past year where we had over 20 attendees. It was a free event that took place at Monmouth Mall in Eatontown, NJ and was advertised for a month. There were 2 guest speakers, lectures, game demos, and prizes. Our main event turned out great in getting people who did not know each other to work in small teams and make a project idea which they presented in front of the entire group.

After hanging out with this group for most of the day and getting to know them, I was able to assign them a role on the team and get them to collaborate and build. We had storyboard conceptions, character creators, presenters, and illustrators. It varied a bit per team.

It was really cool to see the teams working together and having a great time! This was a foundational starting point for the attendees to experience game development with other people.

After the workshop was over, the attendees expressed a wide range of interests in different aspects of the game development process. Since their interests were as varied as their experience and age, I surmised that it would be most beneficial to get an online group going where separate sects could be formed addressing each of their goals and needs. It seemed to be that this group of people liked hanging out and socializing together, but it would be easier to teach them through online coaching and or small classes.

Ultimately, it is enjoyable instructing both online and onsite classes and connecting with many different students. Game Dev House facilitates the bringing together of developers and students who are looking for more than a conventional approach to learning. The combination of international ideas, home-grown games, and student projects has proven to do more than we expected! The culture has been free to define who they want to be and been given a platform of recognition. This builds up the individual to pursue whatever goals and dreams that they have outside of conventional game development, and we support that!

Erin Margolis is a NJ resident and has been working as a game developer since 2005.  She is passionate about game development and its impact on the betterment of society.  Game Dev House was launched on 10/31/12; ironically, the day after Superstorm Sandy.

Is HTML5 Ready for Prime Time? (Part III)

In Part I, game developers Raymond Jacobs and Tom Novelli take a look at HTML5's capabilities and dispel common misconceptions about JavaScript.  In Part II, they propose a solution to HTML5's nightmarish audio problems. In Part III, they give a rundown of other issues that may be encountered when making HTML5 games.

WebGL

One of the principle buzzwords in the HTML5 movement, WebGL holds great promise, the ability to use the native graphics API for 3D games. Our experimentation however, has shown webGL is /not/ ready for prime-time today. The fact that I can run an OpenGL example program written in C++, and on the same machine fail to run the same example written in WebGL, means there are still issues. Damn those proprietary NVidia/ATI drivers! WebGL also has a steep learning curve, compared to Canvas. That all being said, if these issues can be overcome, WebGL should be a very viable option for 2D and 3D graphics middleware - hopefully by year's end.

Annoyance: WWW Baggage

Browsers support a ton of document-formatting features (CSS, HTML, XML, SVG, etc) that aren't terribly useful for Canvas and WebGL games, and are probably best avoided as much as possible. A simple game requires only a half-page of HTML as a container to load the Javascript. Unfortunately if for some reason you know nothing about web design, you'll have to learn basic HTML and CSS in order to create JS games. It's necessary for landing pages and UI dialogs anyway.

Because text rendering is awkward in Canvas and WebGL, you'll probably want to use HTML for in-game text (notifications, character dialogues, etc). The trick is to use "pointer-events: none" (CSS) to prevent the text from blocking mouse clicks.

Using CSS "the right way" can be tedious and pointless. When in doubt, use and abuse "position: absolute" with reckless abandon!

XML being a close cousin of HTML, one would think browsers would have excellent XML facilities. To the contrary, we have found them to be awkward and sometimes buggy, so we converted our old XML assets to JSON.

Also, you'll probably need to install a web server program such as Apache. You may be able to run your game by opening the HTML file on your hard drive (as a "file://" URL), but there are some arcane security restrictions that'll stump you, especially if you get into AJAX or WebGL.

Pitfall: Web Browsers are not 100% Compatible

There's always a catch; "cross-platform" is never seamless. Our advice is to support the top 3 or 4 browsers, and test your game on all of them regularly. Chrome and Safari are generally the best for games, and they both use the WebKit engine so they're nearly 100% compatible. Firefox is also good - better in certain respects - but be careful to avoid bleeding-edge features like "let [x,y] = point". IE and Opera require extra effort which may not be worthwhile for /serious/ games because better browsers are available for all devices. For simple casual games, on the other hand, supporting IE is easier and probably essential for commercial success.

If you're making phone/tablet games, beware: mobile browsers are different beasts.

Resource Packing and Loading

Unlike other platforms where you can zip everything up in an installer package, HTML5 requires a bit more effort. Atlas your sprites and sound effects, embed small HTML files in JSON, embed GLSL shaders if you're using WebGL, embed JSON files in JS, then combine and minify all your JS files. We automate the process using Make, PHP and NodeJS scripts, ImageMagick, LAME, and OggEnc.

Then, when your game starts up, pre-load all your resources (except perhaps music). We use async.js to ajax-fetch everything in parallel, then start the game loop.

AppCache (AKA Offline Mode) is a fairly easy way speed up pre- and re-loading (even for an online multiplayer game) if you keep it simple. Beware, it can go horribly wrong; read the highly entertaining Application Cache is a Douchebag article before you get too excited.

In the beginning, when you're running your game from your own machine, none of this matters. Do whatever works. Just be forewarned, if you finish an HTML5 game, resource loading issues could delay your release by a few days or weeks.

Summary

The potential of making games in a single language that can seamlessly blend with existing web services, have all the trappings and simplicity of web development in free and open platform makes HTML5 very attractive from both development and availability angles.

Raymond Jacobs is the driving force behind Ethereal Darkness Interactive (EDIGames), a western Massachusetts indie developer focused on the Action/RPG genre. Their most notable game is Morning’s Wrath, a fantasy RPG released in 2005. 

Tom Novelli is a game developer and musician in western Massachusetts. He is currently porting Morning's Wrath to HTML5.

October 2013: Story Frameworks

Recently, game developer Kaolin Fire posed this question in the Game Writers Facebook group:

Do you think there's value in adding a story to a dead-simple puzzle/arcade game (a la Tetris)? If so, where/how would you put it? An optional menu link? A "joining our intrepid adventurer" before the game starts that's skippable? Maybe just in advertising copy/the game description?

To which Altug Isigan responded:

If you have a strategic system that frames the tactical gameplay, then you have already something that functions similar to the frame story technique. İmagine that after every round of Tetris you gain a Tetris token which you use to complete a puzzle, lets say building sort of a key that lets you escape from the Tetris universe. In that sense, many games tend to use multi-layered gameplay architectures in order to achieve a frame story effect. 

I've played several casual games where the story seems to be sandwiched between some gameplay.  Or seemed somewhat ludicrous. 

• What kind of techniques do you have for stories in casual puzzle games? 
•  Do these stories feel fulfilling to you?  
• What's the best way to tackle this issue?

Kaolin Fire is VP of product development at Blindsight. He's been developing software independently since the days of DOOR games, not counting hours entering machine code from the back of COMPUTE!'s Gazette. He's had fiction and poetry published in Strange Horizons, Crossed Genres, and Murky Depths, among others; has taught computer science at high school and college levels; dabbles in cover art and cover design; and obsesses about the human brain.

Altug Isigan is a scholar at the Eastern Mediterranean University, Department of Radio-TV and Film, in sunny Famagusta, Cyprus, where he is writing a dissertation on narrative in games. You can read more of his work at his blog, the Ludosphere. 

Sande Chen is a writer and game designer whose work has spanned 10 years in the industry. Her credits include 1999 IGF winner Terminus, 2007 PC RPG of the Year The Witcher, and Wizard 101. She is one of the founding members of the IGDA Game Design SIG.

Is HTML5 Ready for Prime Time? (Part II)

In Part I, game developers Raymond Jacobs and Tom Novelli take a look at HTML5's capabilities and dispel common misconceptions about JavaScript.  In Part II, they propose a solution to HTML5's nightmarish audio problems.

Audio

So I’m gonna come right out and say it, audio in HTML5 sucks. There is no reason to dance around the issue. Before I go any further, let me assure you, you can get a decent audio experience in HTML5, but here are some issues you’ll face:

• Audio format issues: 

Certain browsers can only play certain audio formats, this means you will have to deploy at least two audio formats (currently .mp3 and .ogg). Blame software patents.

• Bad Information: 

There is an API to ask a browser what kind of audio formats it can play; sadly this API is horrible with such decoder support responses as “maybe”. Across the myriad of browsers, we’ve also found the API to outright lie about what it can and can't support.

• Cruddy Implementations: 

Some browsers, even though they swear they can play a format; their decoder/stream implementations are just broken. High start latencies, bad audio quality, incorrect timing. Some browsers (or operating systems) seem to implement the bare minimum just so they can say they support a format.

• High start latency: 

If you load a sound file via http and hit play, by the time the sound has downloaded the moment has passed. This is okay for background music, but it's unacceptable for sound effects action games.

This all sounds really hard!

Audio is the #1 problem with HTML5 today; thankfully a lot of smart people have come together, and technology is emerging that makes HTML5 audio at least functional, if not feature-rich.

Audio Sprites to the rescue!

Just as the Atlas is a 2D packing solution for images, to reduce loads of http calls and nominal overhead; the Audio Sprite is a 1D solution for sounds. We took our lead from the ground work done by Remy Sharp. The basic idea is that you pack your sound effects into a single audio file, with a half-second of padding (silence) between each sound to allow for timing irregularities. An accompanying .json file lists all of the files contained in the audio sprite, and their start and end positions.

With audio sprites, you only need to convert one file to ogg and mp3, and you only need one http request to download it.

• Latency b-gone! 

The main benefit of having one large sound file is that we avoid streaming issues with small audio files. The browser preloads the single audio file, then seeks to the beginning of each sound effect when called for, with minimal latency. Our only issue is that we need to monitor and stop the stream after the sound ends but before the next one begins.

• “What about bad format detection?” 

This is still somewhat of an issue; we’ve found that you can favor MP3 and get coverage on most browsers; but at the time of writing it would not be a bad idea to include an MP3-or-OGG setting in your options menu. Also, make sure you're doing it right; a lot of people cut corners in format detection.

• “This all sounds like a bit much to handle!” 

Yeah it’s a pain; it took us weeks to develop the necessary tools and tricks. If you’ve got a project in the works and need some help, drop us a line at this e-mail.

By the way, there is hope. Most web browsers already support the new Opus format and/or the spiffy new OpenAL-based WebAudio API. It's probably just a matter of time before they all do.

Raymond Jacobs is the driving force behind Ethereal Darkness Interactive (EDIGames), a western Massachusetts indie developer focused on the Action/RPG genre. Their most notable game is Morning’s Wrath, a fantasy RPG released in 2005. 

Tom Novelli is a game developer and musician in western Massachusetts. He is currently porting Morning's Wrath to HTML5.

Is HTML5 Ready for Prime Time? (Part I)

In Part I of this article, game developers Raymond Jacobs and Tom Novelli take a look at HTML5's capabilities and dispel common misconceptions about JavaScript.

I will make the assumption that you, the reader, have already come to the conclusion that writing a game in a single language and releasing it on multiple platforms without porting or even recompiling is a benefit to your business, through greater visibility and empowering the player.

There has been a lot of misinformation floating around the web concerning HTML5. The most important question is, “Is HTML5 ready for prime time?”

The short answer is yes, you can write polished games in HTML5 and have them run across a myriad of browsers, platforms and devices with consistent results.

The longer answer - the subject of this article - is that HTML5 is still young, and there are real-world pitfalls which should be avoided whenever possible.

Beyond the Buzzword

So when we’re talking about HTML5, what we really mean is Javascript (JS) coupled with graphics and interactive APIs exposed to JS by the browser. Like any mature technology, Javascript comes with its own set of dogma and misinformation.

Here is a short list of common misconceptions:

• "Javascript is slow!"

This was true until the browser makers started pouring R&D into JS optimization, circa 2005. Nowadays, according to this list, it's generally the fastest dynamic language - on par with static languages Java and C#, and only about half the speed of native-compiled C. That's not bad - it's awesome.

• "Javascript doesn’t have classes!"

We hear this one a lot, and it just isn’t true; the prototypal inhertiance in JS delivers all the basic OO features you’d want in a game: member variables; member functions; sub-classing; static members; polymorphism; reflection; function/constructor overloading; type identification (instanceof).

Check out the object-oriented section of Tom Novelli’s JS reference for more information.

• "Javascript isn’t secure because it isn’t compiled!"

The use of minification and obfuscation (if reflection isn't needed), turning your code into a whitespaceless, commentless heap of nonsense to the human eye is as effective as native code compilation. Remember, anything run on the client, be it Javascript, Java or C++ is not secure, and obscurity is not security.

• "Javascript isn't a real programming language!"

This is just silly; look at http://en.wikipedia.org/wiki/ECMAScript. From a language design perspective, Javascript is pretty nice. It's a pared-down version of Scheme Lisp with a C-like syntax and Smalltalk-style prototypal objects.

By the way, the next version of Javascript - ES6 - is going to be sweet.

***

Now that we’ve addressed some dogma concerning Javascript, let’s talk about HTML5. HTML5 simply adds to the existing HTML specification we all know and love, and as game developers we only really care about a few choice bits. So here are some exciting things you can use today with HTML5, and some pitfalls.

Canvas

It’s the feature we’ve all heard about concerning games in HTML5. The Canvas creates a 2D drawing space on your web page. You can control the frame buffer size (pixel width and height) and set the screen size of the canvas element; it will automatically stretch or shrink the buffer to the element size. You can even create off-screen canvases and copy one canvas to another, giving the potential for powerful effects and/or performance enhancements.

With a simple setInterval timer (or better yet, the requestAnimationFrame API) and a canvas, you’re ready to start drawing things in less time it would take to install a typical IDE.

“Pitfalls!” 

Besides blitting bitmap images at lightning speed, canvas includes a robust API (based on PostScript) for geometric lines and fills, and rudimentary text rendering facilities; use these sparingly however, as they tend to sap frame-rate.

Also, canvas likes to draw from a small number of source images and would prefer that you keep your drawImage calls down (this is probably a reality of underlying drivers/API which are 3D in nature). So, atlas those tiny images (you’ll want to anyway to reduce http load calls), and use offscreen canvases to cache unchanging parts of the scene (turn those 6400 drawn tiles into a single drawImage call).

Raymond Jacobs is the driving force behind Ethereal Darkness Interactive (EDIGames), a western Massachusetts indie developer focused on the Action/RPG genre. Their most notable game is Morning’s Wrath, a fantasy RPG released in 2005. 

Tom Novelli is a game developer and musician in western Massachusetts. He is currently porting Morning's Wrath to HTML5.

Left Hand Meet Right Hand: Advantages of Distributed Development and Work from Home (Part III)

In Part I, developer Judy Tyrer discusses the disadvantages and disruption caused by mandatory colocation. In Part II, she demonstrates how distributed development can be more productive but cautions that team building is still necessary. In Part III, she lists the benefits of working from home in a distributed development environment.

Work From Home

Studies have shown an increase in productivity when workers are allowed to work from home. One reason for this is how people view their time. When a person is in an office, they view all the time in the office as time worked. This includes gabbing with co-workers, playing ping-pong, mid-day power walks, etc. When people work from home, the only time they view themselves as working is time actually spent working. Breaks to do the dishes, take the dog for a walk, etc. are not considered work time.

Working from home also helps reduce the person's carbon footprint, unless they are the rare individual that commutes by bike or walks. For companies in urban areas such as Los Angeles, where programs to discourage individual commuting are in place, this improves the company's score card. Commuting can also take up to 3 hours of a person’s day. Those hours can be split between the developer’s personal life and the work with gains in each.

Working from home allows parents to be more involved in their families and less dependent on outside care takers. The result is less time spent making arrangement for the children while at work, less anxiety on the part of the parent, and a result in higher concentration and higher quality of work.

Innovation

But what about Ms. Myers’ assertion that people need to be in the same office to innovate? As I know of no studies verifying or denying her hypothesis I will address it with questions about innovation rather than with data.

How much innovation is needed?

Does every single employee at a company need to innovate? Do you want your build system to be innovative or would you prefer a tried and true system that has been doing its job for 10 years. Do you want innovative accountants thinking outside the box on your tax returns? I contest the idea that everyone in the company needs to be innovative.

Do we have to be in the same room to innovate?

Often meetings where brain-storming and innovation take place are dominated by the same loud voices. When one or more members of a team are dominant, others are often quiet and their input gets lost in the noise. While this can also happen in on-line meetings, the ability to type text into a chat field during the meeting allows people who may not be as verbally assertive to still ensure their input makes it into the meeting without having to develop skills in interrupting others. And the record of the meeting allows review which can facilitate greater innovation.

Do we want to innovate for the sake of innovation?

Innovation is the hot new buzzword. But is innovation for its own sake necessarily desirable. Just because no one has ever made an FPS where bullets travel a player defined path rather than a physics defined trajectory does not mean that particular innovation will increase sales, provide a better experience or is in any way a good idea.

Benefits versus Risks

The risks for developers in a distributed model mostly fall on the shoulders of middle management as it requires more than just showing up at the office and delegating tasks. Managers have to be willing to work with their team based on work results alone. No more can a manager say “if I don’t see you working, you’re not working” (a fairly ridiculous assertion in a creative medium as dependent on inspiration as on hard work). The manger must actually look at and evaluate the work of the employees and this takes time.

In addition, since managers don’t casually pass their employees, often giving them the illusion they are aware of what that person is doing, in a distributed environment managers must actually schedule time to sit down with their direct reports. Having worked for 2.5 years at one studio before ever receiving feedback from my manager other than a yearly raise, the value of regular meetings with direct reports cannot be over-stated. Managers and direct reports need to communicate regularly. The processes necessary for a distributed team are those which would help all teams, but the distributed nature of the work requires those processes be in place and be followed.

The benefits to allowing work from home can also be found in talent retention. Better communication, autonomy over work environment, and being judged by the quality of your work and not arbitrary measures are all benefits that help talent remain satisfied with their position. And while all of these can happen in a single location, they can also be easily overlooked in such an environment. Distributed development, when it works, puts these things as top priorities and they become integrated into the corporate culture for the benefit of all.  

Judy Tyrer began in serious games with PLATO in the late 1970s, moved into distributed operating systems and enterprise software before rejoining the game industry in 2005. She worked for Ubisoft, Sony Online Entertainment and Linden Lab before branching out to start her own studio, 3 Turn Productions LLC which is coming out with the virtual world of Jane Austen for Kickstarter this summer.

September 2013: Teaching Game Design

Hello! 

Two weeks ago, I presented, "What's in a Name? Serious Games vs Gamification" at the Serious Play Conference, held at DigiPen, a college focused on game development.  At the conference, there were numerous presentations on how to use games to educate children in topics such as math, science, and history.  Dr. James Rosser, Jr.spoke about how video games could improve the skills of laparoscopic surgeons while Professor Mihaly Csikszentmihalyi unveiled an application to help managers facilitate flow states for employees.  The research indicated that companies actually make a profit while employees achieve flow!

During my time there, I did get to talk to an instructor at DigiPen.  There was not much discussion about teaching game development at the conference, although Lee Sheldon's book, The Multiplayer Classroom: Designing Coursework as a Game did come up during my Q&A period.

When I went to college, there weren't schools like DigiPen dedicated to game development.  Now, it's not odd to see game design offered in various departments, in colleges big and small.  I noticed that while GDAM has covered Game-Based Learning and Game Designer Skills, we have never had  a topic about teaching game design.

As it is the month children traditionally head back to school after the summer break, I think it's fitting that September 2013's topic is Teaching Game Design.

I invite readers to submit an article on this topic. Please read the submission guidelines first. Thanks!