Why is the #ME3 ending like Javascript in the browser?

With @ArchAzrael and @mike_acton
Check out what Double Cluepon is doing. I’m a big fan of their open development model.

Game tools

With @gorlak, @fuzzybinary and @mike_acton
Make sure to join up with the IGDA Tools SIG (#toolsmiths) if you’re interested in a community of tools developers. And check out The Toolsmiths blog

I know that there’s a group of gamedevs, researchers and students who will be in San Francisco during the GDC timeframe but for one reason or another (including financial) aren’t able to attend the conference. #AltDevBlogADay will be hosting a free summit on Wednesday to give you another chance to meet other gamedevs and generally have some good discussion and a good time.

We’ll have a rough structure throughout the day, but I imagine that we will make ad hoc adjustments depending on the group and what would be the most interesting or fun for all of us.

I would also like to thank Game Connection for sponsoring #AltDevSummit!

Mike.

We started this experiment in January and so far it’s been an amazing experience for me personally, and I hope the rest of the #AltDevAuthors.

In this year, we’ve had to change servers TWICE (here’s hoping that we even outgrow our current heavy-weight server in the future!) and have tried a lot of different things: Starting with my favorite, posts that share stories about experiences and our place in the lifelong journey of #gamedev. But we’ve also had technical articles (of all disciplines), audio posts, video posts, at least one google hangout, one unconference as well as an online conference to come soon!

A few of our guys will tell you why they joined (and why you should too!)

From Paul Evans:

From Jonathan Adamczewski:

From Alex Darby:

You definitely need to check out the one from Jaymin Kessler:

And a note from Don Olmstead:

“Imitation is the sincerest of flattery.” – Charles Caleb Colton

When working in an industry that is always advancing you need to be constantly learning. As an engineer I gravitate towards articles providing new insights in programming, and there are plenty of those here on #AltDevBlogADay. My favorite articles go a step further. After reading them I want to sit down at my computer and pound out my own implementation. The first #AltDev article to cause that reaction was James Podesta’s Debugging in Your Web Browser.

In it he presents the potential benefit of his solution, citing multiple examples. He then goes and provides a reference implementation all the while discussing why certain design decisions were made, and noting how it could be expanded. From there a programmer reading it can take that information and start coding up a solution that meets their own needs.

Some other articles that have had me working out my own implementations in the first 1024 posts are Niklas Frykholm’s C++ Duck Typing, Don Williamson’s epic Reflection in C++: Part 1, and Stefan Reinalter’s Quasi compile-time string hashing.

I hope you’ve enjoyed our first 1,024 posts. And I here’s hoping we’ll all reach the next power of two together! More good things to come.

Mike.

I’m also going to leave a link to this post on the right panel and keep it live so we can keep the discussion open between now and then.

Mike.

Creating Your Dreams – A Gentle Introduction to Experimental Hardware and the World It Opens

Track: Programming (Design secondary as it’s about enabling new experiences)
Format: 60 minute talk
Speaker: Richard Sim

Where and how we play games is rapidly changing. With new markets emerging and existing markets diversifying, new experiences are becoming available with each change. The Wii was hot in the past, mobile, tablet, and social games are hot today, and who knows what will be hot tomorrow. The electronics industry is undergoing similar transitions; with the bar for entry for what used to be sophisticated technology coming down so low that it’s now within the reach of casual experimentation thanks to the advent of open source hardware and what is often referred to as the Maker Movement.

This presentation will provide the audience with an overview of Android USB Accessories, the Arduino platform, what open source hardware is, and how they all come together to give developers new, unbounded power to define what tomorrows innovations will be. There’s nothing in the way of a regular developer coming up with the next Guitar Hero, AR Drone, or Ubisoft tablet.

I will not be focusing on electronics or hardware design per se, but how open hardware can be leveraged as building blocks that can be used to easily create new controllers, feedback and output devices, and other such peripherals, which can then be programmed in a similar fashion to what we’re used to on established platforms. It is these building blocks that have lowered the bar for entry so dramatically, and it’s all happened very fast.

Once the foundations have been covered, I will go into the details of creating a simple controller that will act as an Android USB Accessory. If time allows I will also cover changes required to create a Bluetooth accessory, which opens up the possibility to target both iPhone and Android devices.

To close I will take the audience’s imagination one step further and onto creating games that are played in the Real World(!). I will show how sensors, data logging, real-time feedback, and simple gameplay mechanics can be used to add a new dimension to existing sports. Why play SSX online when you can go down a double black-diamond with your friends and compete for the highest score in real life?

The take-away for the audience will be a spark to dive in and get started creating devices that nobody but themselves have ever imagined, to enable the gameplay experiences that have only ever existed in their dreams, with enough knowledge of the subject to know where to start and hopefully with all the excitement they need to get them on their way to a working prototype!

Game Tools as a WebApp: Lessons from Insomniac’s Next-Gen Tools and Engine

Track: Programming
Format: 60 minute talk
Speaker: Mike Acton

Insomniac, like many developers, has traditionally treated development tools as a second-class development effort. While we have had dedicated Tools programmers for many years, very little effort was put into the overall user experience and runtime performance was always valued over development effort. This resulted in a systematic increase in development cost and an entire “Engine Economy” based on brute-force effort. Two years ago, we decided to tackle this problem head-on. The result is an entirely new suite of tools, written from the ground up to fundamentally change the way we work as a studio.

It was also clear that the world was changing. The explosion of web-based enterprise applications, fully-web enabled mobile devices (like the iPhone and iPad) and browser-based gaming sent a clear signal that the era of native applications living in a sandbox was over. Not just for games, but also for the tools we use to develop games. We felt this was an opportunity to make a strategic change that would position us much better and net us valuable experience for the inevitable changes to operating systems, development tools and user expectations.

This is the story of our experience so far.The first game Insomniac will ship on these tools is Overstrike. We will share our most significant choices and the costs of those choices. We will suggest alternatives where we feel that better results can still be achieved. And we will share details of the technical architecture of the new tools suite.

Details such as:

Usability is not random. We needed first-class information to develop first-class tools. We set up a formal usability practice without a lab or additional budget using a single PC. We will also share specific, novel tools features such as our “neighbor” and “tile” mode which allowed us to increase production time on common tasks by as much as 20x.

The choice to go webapp. The initial version of the tools was not web-based. It was a native application which used Flash for the front-end. This model was not significantly improved over the traditional native model and introduced the same data complexities. Webapp tools allowed us to not only take advantage of many available development tools, it forced a clean separation of UI and back-end data.

Client/Local-server model. One of the concerns of browser-based tools is adding latency. We largely solved this issue by running a mongoose-based web server local to each machine.

Additional details. We will also share our experience with allowing custom tools and UI development by non-tools programmers. Our take on the Flash vs. HTML5 debate. Details of integrating a native engine. And browser and security workarounds.

We’ll share enough about how we made our tools and why so that you could begin to duplicate the process. We’ll share why we made the choices we made so that you can justify the effort and search for reasonable alternatives. And we’ll share where we went wrong so that you can avoid the same costly mistakes.

#AltDevBlogADay Post Mortem: The First Year

Track: Business and Marketing and Management; Programming
Format: 60-Minute Panel
Speakers: Jaymin Kessler, Jonathan Adamczewski, Michael Jungbluth, Mike Acton, Tiffany Smith, Wolfgang Engel

#AltDevBlogADay is all about the sharing of knowledge and ideas about game development in a way that is unprecedentedly open and eager. What better way to continue the online initiative of transparency for all things game dev related than a post mortem?

Started by Mike Acton, #AltDevBlogADay is a grand experiment in decentralized collaboration and information sharing. With hundreds of authors from around the world spanning a full range of specializations and levels of experience, and each author posting once every 15 days, there is always something new and interesting to read. Select articles even appear on Gamasutra, GameIndustry.biz, and in Game Developer Magazine. This talk will bring together a handful of those contributors to talk about how it formed, why they think it is valuable and what more can still be done.

The panel will start with how the idea came about, straight from the founder Mike Acton, and how it grew through social networks such as twitter and google groups. He will also discuss how it maintained a consistent stream of posts through server changes, copyright discussions and initiatives with other websites and publications, all the while keeping it casual and barrier free for anyone wanting to post.

Authors on the panel will speak to why they felt it important to join the website and keep up a continual posting schedule while balancing a full developer workload. They will speak to any benefits they have found from posting from networking to even advancement opportunities in their careers. One student contributor even got recruited by the studio he now works for after the studio’s owner read one of his posts.

Panelists will also speak to what responsibility they feel for the content generated, correcting any faulty information on the site, and any need to affect the wider culture of game development. In one instance, Mike Acton put out a call for more female developers to join the site, to help drive forward a gap in the industry both he and many others identify as cultural concern. Both he and panelist Tiffany Smith will touch on how that initiative went and if more can still be done.

Authors will also touch on some of the topics that have gotten the most attention industry wide, be it about a specific discipline’s skill set or opinions on general development culture or practices. This includes how they have dealt with the replies, when the traditional role of developers is to not engage online comments, especially when the post goes viral outside of the traditional industry community through sites like reddit or facebook.

Finally, they will touch upon where they want to see it grow and what the future can hold for this initiative to give a daily voice to the developers of the world.

Attendees of all disciplines will walk away from the talk with new tools and insights towards getting their voice out there and realizing that every day can be a networking and learning experience like the one at the conference.

Cutting the Pipe: Achieving Sub-Second Iteration Items

Track: Programming (Design secondary as it’s about enabling new experiences)
Format: 60 minute talk
Speaker: Niklas Frykholm

Often there is a perceived conflict between dynamic/flexible systems, where objects can be manipulated directly and high-performance systems that pre-process and pack their data as efficiently as possible. This session will show that this conflict is not innate, by presenting a pipeline design that combines sub-second iteration times with highly efficient load-in-place data structures.

This is achieved by combining several techniques:
Game resources are organised into binary pieces that can be compiled and reloaded individually. A central resource manager keeps track of all resources and a reload broadcasts a function call with the new and old resource pointers to all affected systems. Each system is responsible for handling this in the correct way.
A data compiler process is always kept running as a local TCP/IP server to eliminate startup/shutdown times.
Data that persists between compile sessions is kept in fast in-memory databases.
Directory watching eliminates the need for file tree scanning.
Tools use the actual engine and final data formats for visualization.
Tools talk to the engine over TCP/IP and can tell it to reload individual resources.
Lua is used for reloadable gameplay code and also acts as an interface for the tools (over TCP/IP).

By using this method, the recompile time for a project becomes proportional to the number of changed resources, rather than to the total number of resources, with a very low static overhead. A zero-compile (no data changed) touches no files on the disk.

Additional benefits include:
Immediate drop-in play from the level editor on both PC and console.
Live near-instant reload/recompile of all game resources.
Artists and gameplay programmers see the result of changes immediately.
No central data compiler needed, everyone can work distributed in local repositories.
Consoles can run in slave mode to an editor running on a PC and immediately show what levels, particles and animations will look like on the final hardware.
Tools can be written in any language.

This method has been implemented in the BitSquid engine and is being used by multiple titles currently under development, including the recently released Hamilton’s Great Adventure. Using this method, a recompile of a 10 000 file project with one changed Lua file takes less than 500 ms.

Technical Animation Roundtable

Track: Visual Arts
Format: 60-Minute Roundtable
Speaker: Tim Borrelli

Over the last 2 years, the Technical Animation Roundtable at GDC has been very successful, and I plan on keeping that success going.

This year, there will be a much broader range of discussion topics that will keep people coming back each day. For example, one topic that has been discussed from many angles is character performance. Since a large part of technical animation relates to getting a character to look its best in-game, the conversations have veered towards discussing how, as tech animators, we can better work with and facilitate meaningful dialogue with modelers, animators, designers, writers, and AI programmers. I plan on promoting this as a full session topic for one of the days.

I will change the intended audience to be broader, to include not just tech animators, animators and programmers, but also modelers, writers, designers and concept artists. In order to get that audience, I will become more active pre-GDC to encourage other disciplines to attend. I know the title will still cause some people in the aforementioned disciplines to skip over it, but my hope is that word of mouth will bring in these other disciplines so that more cross-discipline discussion can occur.

The roundtable will focus on the process of a character’s performance in game, including the initial design spec, the concept phase, modeling for animation, rigging, creating animations for proper player input or AI controls, use of motion of performance capture, creation of state machines and blendtrees, voice recording, implementing in the game engine, and finally what the end user will experience.

I will encourage the entire audience of modelers, animators, tech animators, designers, writers, and programmers to participate in a productive discussion about how the process works for them, and how it can be improved.

Ultimately, the participants should walk away having seen the process through each other discipline’s eyes, and be able to go back to work with a newfound understanding on how to best communicate with their coworkers in order to deliver, as a team, the best character performance possible. Participants will also learn what common skills effective technical animators share and how to apply those skills to their specific company, as well as the value it will bring to their projects.

Animators Demanding Respect

Track: Visual Arts
Format: 60-Minute Panel
Speaker: Michael Jungbluth; Nate Walpole; Tim Borrelli

We are tired of seeing beaten down, unmotivated animators in the game industry. It shouldn’t be standard for designers and programmers to throw animations under the game dev bus with ridiculous rate scaling, blending animations that were never meant to go together into a Frankenstein’s monster, and tossing the wet blanket of universal compression rates over all the animations. Producers will often praise the performance of an actor in a mocap suit, and never once mention the animation team’s effort in pulling it together. We are fed up with losing some of our best talent to film where a character’s performance isn’t sacrificed for gameplay’s, when the two need not be mutually exclusive.

In this panel, three experienced game animators will talk about how best to deal with these pitfalls and misconceptions, all the while driving home the point that animation is more than just the motions of a character, but also their emotions. Their solutions for how to gain respect and push forward game animation as a whole include a better integration of technical abilities, a renewed focus on traditional artistic principles and a better understanding of the grey area between game design and animation.

Tim Borrelli will speak about the task at hand as a technical animator and lead, and how all the tools in the animators wheelhouse are making them more important by the day. This includes:
- Communication between tech art and animation
- Animation tech working WITH design, not around it (rate scaling tools, compression tools, performance issues)
- Proficiency with scripting (Maxscript, Mel, Python, etc) and Excel

Nate Walpole will talk about how its not just the tools but the need to fully embrace and implement the artistic and traditional roots of animation to take game animation to a new level. This involves:
- Use of appeal in character creation
- Need for pauses in acting, action and simultaneously gameplay
- Motion quality on par with other assets (lighting, fx, modeling)
- Motion style complimenting overall gameplay design (mocap on a twitch shooter?)
- Necessity for motion blur as resolution/visual budget increases and gameplay moves faster in parallel
- Animation fidelity and purpose (play as the character, not the UI)

Mike Jungbluth will focus on the need to embrace the area where game design and animation overlap and why animators need to step it up in this regard.
- How soon animation should be included in the design process
- What to do when 4 or more of the 12 animation principles are in the hands of game design, not animation
- Where animators need to inject more purpose (transitional animations and pathing)
- How player input should be considered as much as design output during gameplay (Making the button presses by the player match the intent of the animation on the screen)

Attendees will walk away with not only a renewed sense of respect for what game animation is capable of, but the tools they need to make it happen across their team.

Fail Tales: What We Did (Or Should Have Done) To Ship Troubled Projects

Track: Production
Format: 60-Minute Panel
Speaker: Ed Byrne; Keith Fuller; Marc Scattergood

This panel will provide real-world solutions to the pitfalls faced by well-known AAA developers while shipping MMO’s, original IP’s, and franchise sequels. Each of the three panelists will present the details of a project on which they were a key participant, delivering a description of things that went wrong and what was done to fix those problems and ship the product. While each participant takes center stage in this series of mini-lectures/post-mortems, the other panelists will be weighing in with their own thoughts as to what solutions should have been attempted. We’re encouraging each other to inject a little humor into the process while bringing alternative expert opinions to the discussion. Keeping the talk lively, giving personal behind-the-scenes accounts, and providing the audience with multiple viewpoints will make this session much more valuable than the standard white-washed post-mortem.

Some specific problems and solutions we’ll cover:

How 70 people can finish a game more easily than 150 people (a bigger team can be more problematic)
How experienced developers making something very similar to their last project can still have trouble – what you should watch for
How to cope when delays force you to ship well after your marketing budget has been expended
How good leadership can overcome technical failures, political upheaval, and design mismanagement
How you can go wrong by being too careful with your original IP

Keith Fuller (Production Consultant, Fuller Game Production) was Producer for Raven Software’s Singularity. He describes the design difficulties and leadership changes that took the game from studio darling to almost-canceled to a mid-70′s Metacritic. Although I’m submitting the session under my name, I’ll be an equal participant with the other panelists.

Marc Scattergood (Senior Product Manager, PopCap) was Associate Producer for now-defunct Sigil Games while working on Vanguard: Saga of Heroes. He talks about the tumultuous 6-year development of this MMO.

Ed Byrne (Creative Director, Imba Entertainment) was designer of several games in the SOCOM series and brings to light the problems he encountered and the solutions he employed with that franchise.

What is a self-avoiding walk?

Put simply, a path on a grid that does not cross itself.

For more detailed introductions, see also:

• How to Avoid Yourself by Brian Hayes
• Self-Avoiding Walk on Wolfram MathWorld
• Self-Avoiding walk on Wikipedia

Counting walks

From the wikipedia entry:

Calculating the number of self-avoiding walks in any given lattice is a common computational problem. There is currently no known formula for determining the number of self-avoiding walks, although there are rigorous methods for approximating them. Finding the number of such paths is conjectured to be an NP-hard problem.

This is typical academic bullshit.

The problem with declaring (or conjecturing) this problem to be NP-hard is that it’s completely the wrong question being asked. It’s not a question of creating a “formula for determining the number of self-avoiding walks” given no other information. Or at least, it’s not an interesting or relevant question. As a practical matter, it tells us exactly nothing about the real problem: How we can find that number in a reasonable amount of time given any information or method which might be useful.

So that’s where we’ll start this series. We’ll look at different methods for counting paths of arbitrary lengths in a reasonable time (assuming you have a method of adding increasingly huge numbers.) In the first few parts I hope I to convince you that with a little bit of data analysis (because it’s always about the data), that you can calculate the total number of self-avoiding walks exactly for fairly large path lengths in a reasonable time. And then we might look at other interesting properties and related problems.

End points

Let’s start small.

Here are the self-avoiding walks of length 3. (By convention, the center point is not counted as part of the length of the walk.)

Each next step of the walk is denoted by the direction:

• C=Center
• W=West
• E=East
• S=South
• N=North

C,W,W,W   C,W,N,W   C,S,S,W
C,W,W,S   C,W,N,E   C,S,S,E
C,W,W,N   C,W,N,N   C,S,S,S
C,W,S,W   C,E,E,E   C,N,W,W
C,W,S,E   C,E,E,S   C,N,W,S
C,W,S,S   C,E,E,N   C,N,W,N

C,E,S,W   C,S,W,W   C,N,E,E
C,E,S,E   C,S,W,S   C,N,E,S
C,E,S,S   C,S,W,N   C,N,E,N
C,E,N,W   C,S,E,E   C,N,N,W
C,E,N,E   C,S,E,S   C,N,N,E
C,E,N,N   C,S,E,N   C,N,N,N

Which can also be visualized like this:

Note that some of the paths end at the same point:

We’ll call those points “End Points” and that’s what we’ll concentrate on first. Let’s visualize where those end points end up for these length 3 paths. Here, the center is denoted by “*” and each “X” denotes an end point (where one or more paths end.)

- - - X - - -
- - X - X - -
- X - X - X -
X - X * X - X
- X - X - X -
- - X - X - -
- - - X - - -
EndPointCount: 16

This is true for any path length n.

Let’s look at another example. The end points of path length 15:

- - - - - - - - - - - - - - - X - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - X - X - - - - - - - - - - - - - -
- - - - - - - - - - - - - X - X - X - - - - - - - - - - - - -
- - - - - - - - - - - - X - X - X - X - - - - - - - - - - - -
- - - - - - - - - - - X - X - X - X - X - - - - - - - - - - -
- - - - - - - - - - X - X - X - X - X - X - - - - - - - - - -
- - - - - - - - - X - X - X - X - X - X - X - - - - - - - - -
- - - - - - - - X - X - X - X - X - X - X - X - - - - - - - -
- - - - - - - X - X - X - X - X - X - X - X - X - - - - - - -
- - - - - - X - X - X - X - X - X - X - X - X - X - - - - - -
- - - - - X - X - X - X - X - X - X - X - X - X - X - - - - -
- - - - X - X - X - X - X - X - X - X - X - X - X - X - - - -
- - - X - X - X - X - X - X - X - X - X - X - X - X - X - - -
- - X - X - X - X - X - X - X - X - X - X - X - X - X - X - -
- X - X - X - X - X - X - X - X - X - X - X - X - X - X - X -
X - X - X - X - X - X - X - X * X - X - X - X - X - X - X - X
- X - X - X - X - X - X - X - X - X - X - X - X - X - X - X -
- - X - X - X - X - X - X - X - X - X - X - X - X - X - X - -
- - - X - X - X - X - X - X - X - X - X - X - X - X - X - - -
- - - - X - X - X - X - X - X - X - X - X - X - X - X - - - -
- - - - - X - X - X - X - X - X - X - X - X - X - X - - - - -
- - - - - - X - X - X - X - X - X - X - X - X - X - - - - - -
- - - - - - - X - X - X - X - X - X - X - X - X - - - - - - -
- - - - - - - - X - X - X - X - X - X - X - X - - - - - - - -
- - - - - - - - - X - X - X - X - X - X - X - - - - - - - - -
- - - - - - - - - - X - X - X - X - X - X - - - - - - - - - -
- - - - - - - - - - - X - X - X - X - X - - - - - - - - - - -
- - - - - - - - - - - - X - X - X - X - - - - - - - - - - - -
- - - - - - - - - - - - - X - X - X - - - - - - - - - - - - -
- - - - - - - - - - - - - - X - X - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - X - - - - - - - - - - - - - - -
EndPointCount: 256

Let’s look again at the end points of path length 3:

- - - X - - -
- - X - X - -
- X - X - X -
X - X * X - X
- X - X - X -
- - X - X - -
- - - X - - -
EndPointCount: 16

And at the end points of path length 4:

- - - - X - - - -
- - - X - X - - -
- - X - X - X - -
- X - X - X - X -
X - X - * - X - X
- X - X - X - X -
- - X - X - X - -
- - - X - X - - -
- - - - X - - - -
EndPointCount: 24

Notice that in the odd numbered path the center point is excluded from the area defined by the end points (n+1)*(n+1); in the even numbered path, the center point is included in the area but can obviously not itself be an end point.

Here’s some simple javascript to help you validate the pattern: walk_11.js (Note: I’m using jsdb to run this javascript, you may need to slightly modify for a different environment.) This script brute force calculates all paths for a given length n, then prints out the end points in the form above. Since it’s brute forcing all paths, it’s only usable for small n.

Now just with Observation-1 and Observation-2, you can already significantly reduce the amount of time enumerating self-avoiding walks. By knowing where paths must end and where paths cannot end, you can reduce the search space significantly. i.e. Traditional brute-force walk enumeration (as in the javascript example above), begin at the center point and simply work out every path one-by-one. However, if you know all the end points, you can iterate through each end point and find the paths that connect the two points instead (end point and center point).

However, we’ll put that aside for now so that we can look at some additional data.

Let’s look at the number of paths found at each end point of a length 3 walk:

----- ----- ----- 00001 ----- ----- -----
----- ----- 00003 ----- 00003 ----- -----
----- 00003 ----- 00002 ----- 00003 -----
00001 ----- 00002 ***** 00002 ----- 00001
----- 00003 ----- 00002 ----- 00003 -----
----- ----- 00003 ----- 00003 ----- -----
----- ----- ----- 00001 ----- ----- -----
EndPointCount: 16
TotalWalkCount: 36

This is obvious. If we know all the points at which paths can end and we know how many paths end at each point we can simply add them all up to get the total number of walks (in this case, 36.)

Another example. End point path counts for path length 8:

----- ----- ----- ----- ----- ----- ----- ----- 00001 ----- ----- ----- ----- ----- ----- ----- -----
----- ----- ----- ----- ----- ----- ----- 00008 ----- 00008 ----- ----- ----- ----- ----- ----- -----
----- ----- ----- ----- ----- ----- 00028 ----- 00042 ----- 00028 ----- ----- ----- ----- ----- -----
----- ----- ----- ----- ----- 00056 ----- 00092 ----- 00092 ----- 00056 ----- ----- ----- ----- -----
----- ----- ----- ----- 00070 ----- 00118 ----- 00126 ----- 00118 ----- 00070 ----- ----- ----- -----
----- ----- ----- 00056 ----- 00120 ----- 00118 ----- 00118 ----- 00120 ----- 00056 ----- ----- -----
----- ----- 00028 ----- 00118 ----- 00112 ----- 00092 ----- 00112 ----- 00118 ----- 00028 ----- -----
----- 00008 ----- 00092 ----- 00118 ----- 00076 ----- 00076 ----- 00118 ----- 00092 ----- 00008 -----
00001 ----- 00042 ----- 00126 ----- 00092 ----- ***** ----- 00092 ----- 00126 ----- 00042 ----- 00001
----- 00008 ----- 00092 ----- 00118 ----- 00076 ----- 00076 ----- 00118 ----- 00092 ----- 00008 -----
----- ----- 00028 ----- 00118 ----- 00112 ----- 00092 ----- 00112 ----- 00118 ----- 00028 ----- -----
----- ----- ----- 00056 ----- 00120 ----- 00118 ----- 00118 ----- 00120 ----- 00056 ----- ----- -----
----- ----- ----- ----- 00070 ----- 00118 ----- 00126 ----- 00118 ----- 00070 ----- ----- ----- -----
----- ----- ----- ----- ----- 00056 ----- 00092 ----- 00092 ----- 00056 ----- ----- ----- ----- -----
----- ----- ----- ----- ----- ----- 00028 ----- 00042 ----- 00028 ----- ----- ----- ----- ----- -----
----- ----- ----- ----- ----- ----- ----- 00008 ----- 00008 ----- ----- ----- ----- ----- ----- -----
----- ----- ----- ----- ----- ----- ----- ----- 00001 ----- ----- ----- ----- ----- ----- ----- -----
EndPointCount: 80
TotalWalkCount: 5916

For validation, here’s another javascript which will brute force through all paths, add up the number of paths at each end point and output in the format above: walk_12.js

This is where we will concern ourselves. If we can predict the number of self avoiding walks for each end point, we can eliminate the work in walking those paths and simply add up the results. The tricky bit is of course determining what those patterns are exactly. But rest assured, they exist.

First let’s rearrange the format of the data. End points are an (n+1) by (n+1) diamond shape, which if rotated 45 degrees, can be made into a square matrix. Here’s the same data from above for path length 8 in that form:

00001 00008 00028 00056 00070 00056 00028 00008 00001
00008 00042 00092 00118 00120 00118 00092 00042 00008
00028 00092 00126 00118 00112 00118 00126 00092 00028
00056 00118 00118 00092 00076 00092 00118 00118 00056
00070 00120 00112 00076 ***** 00076 00112 00120 00070
00056 00118 00118 00092 00076 00092 00118 00118 00056
00028 00092 00126 00118 00112 00118 00126 00092 00028
00008 00042 00092 00118 00120 00118 00092 00042 00008
00001 00008 00028 00056 00070 00056 00028 00008 00001
EndPointCount: 80
TotalWalkCount: 5916

Let’s start with the easy stuff.

Notice that the walk counts are rotated and mirrored about the center. That makes intuitive sense: Any walk that begins in one direction has an equivalent walk that begins in the other three directions.

This observation is well known and is the basis for most high-level optimizations of the brute force algorithm. And it’s easy to see why. By simply starting the path in one known direction, the total count is simply multiplied by four to account for the other quadrants.

Here the end points paths which are simply mirrors or rotations of one direction for path length 8 are marked in red.

00001 00008 00028 00056 00070 00056 00028 00008 00001
00008 00042 00092 00118 00120 00118 00092 00042 00008
00028 00092 00126 00118 00112 00118 00126 00092 00028
00056 00118 00118 00092 00076 00092 00118 00118 00056
00070 00120 00112 00076 ***** 00076 00112 00120 00070
00056 00118 00118 00092 00076 00092 00118 00118 00056
00028 00092 00126 00118 00112 00118 00126 00092 00028
00008 00042 00092 00118 00120 00118 00092 00042 00008
00001 00008 00028 00056 00070 00056 00028 00008 00001
EndPointCount: 80
TotalWalkCount: 5916

But there is still more duplication here.

In other words, all the paths which are found after you first turn right have equivalent paths if you had turned left instead. You can see how the end point path counts are mirrored along the diagonal of that quadrant.

Which leaves us with just the following green end points for paths of length 8.

00001 00008 00028 00056 00070 00056 00028 00008 00001
00008 00042 00092 00118 00120 00118 00092 00042 00008
00028 00092 00126 00118 00112 00118 00126 00092 00028
00056 00118 00118 00092 00076 00092 00118 00118 00056
00070 00120 00112 00076 ***** 00076 00112 00120 00070
00056 00118 00118 00092 00076 00092 00118 00118 00056
00028 00092 00126 00118 00112 00118 00126 00092 00028
00008 00042 00092 00118 00120 00118 00092 00042 00008
00001 00008 00028 00056 00070 00056 00028 00008 00001
EndPointCount: 80
TotalWalkCount: 5916

This is true for paths of any length n. Here is another example with paths of length 13.

00001 00013 00078 00286 00715 01287 01716 01716 01287 00715 00286 00078 00013 00001
00013 00132 00607 01683 03190 04521 05214 05214 04521 03190 01683 00607 00132 00013
00078 00607 02106 04398 06467 07656 08128 08128 07656 06467 04398 02106 00607 00078
00286 01683 04398 07072 08506 08923 08956 08956 08923 08506 07072 04398 01683 00286
00715 03190 06467 08506 08924 08518 08080 08080 08518 08924 08506 06467 03190 00715
01287 04521 07656 08923 08518 07366 06387 06387 07366 08518 08923 07656 04521 01287
01716 05214 08128 08956 08080 06387 04116 04116 06387 08080 08956 08128 05214 01716
01716 05214 08128 08956 08080 06387 04116 04116 06387 08080 08956 08128 05214 01716
01287 04521 07656 08923 08518 07366 06387 06387 07366 08518 08923 07656 04521 01287
00715 03190 06467 08506 08924 08518 08080 08080 08518 08924 08506 06467 03190 00715
00286 01683 04398 07072 08506 08923 08956 08956 08923 08506 07072 04398 01683 00286
00078 00607 02106 04398 06467 07656 08128 08128 07656 06467 04398 02106 00607 00078
00013 00132 00607 01683 03190 04521 05214 05214 04521 03190 01683 00607 00132 00013
00001 00013 00078 00286 00715 01287 01716 01716 01287 00715 00286 00078 00013 00001
EndPointCount: 196
TotalWalkCount: 881500

At this point, using Observation-5 and Observation-6, you could reduce the work of enumerating self avoiding walks significantly again. It’s hopefully clear that if you can just find those walks which end in the end points in green, you can derive all the remaining walks.

However, again we’ll put this aside for now to concentrate on digging into the data still further.

Here’s where we take a step away from the view of the problem in isolation and use more available data.

For example, if we want to get the end point path counts for paths of length 15, it helps to know the counts for all the paths of lengths less than 15. Or rather, if we want to calculate end point counts for paths of length 15, we can assume we’ve already done that for all the paths of length 14, 13, 12, 11, 10, 9, etc. previously and we can use that data to help.

Let’s have a look at all the end point counts of path lengths between 1 and 15:

n 1
v     1     1
v     1     1 

n 2
v     1     2     1
v     2     0     2
v     1     2     1 

n 3
v     1     3     3     1
v     3     2     2     3
v     3     2     2     3
v     1     3     3     1 

n 4
v     1     4     6     4     1
v     4     6     4     6     4
v     6     4     0     4     6
v     4     6     4     6     4
v     1     4     6     4     1 

n 5
v     1     5    10    10     5     1
v     5    12    11    11    12     5
v    10    11     6     6    11    10
v    10    11     6     6    11    10
v     5    12    11    11    12     5
v     1     5    10    10     5     1 

n 6
v     1     6    15    20    15     6     1
v     6    20    26    24    26    20     6
v    15    26    20    16    20    26    15
v    20    24    16     0    16    24    20
v    15    26    20    16    20    26    15
v     6    20    26    24    26    20     6
v     1     6    15    20    15     6     1 

n 7
v     1     7    21    35    35    21     7     1
v     7    30    52    55    55    52    30     7
v    21    52    54    45    45    54    52    21
v    35    55    45    28    28    45    55    35
v    35    55    45    28    28    45    55    35
v    21    52    54    45    45    54    52    21
v     7    30    52    55    55    52    30     7
v     1     7    21    35    35    21     7     1 

n 8
v     1     8    28    56    70    56    28     8     1
v     8    42    92   118   120   118    92    42     8
v    28    92   126   118   112   118   126    92    28
v    56   118   118    92    76    92   118   118    56
v    70   120   112    76     0    76   112   120    70
v    56   118   118    92    76    92   118   118    56
v    28    92   126   118   112   118   126    92    28
v     8    42    92   118   120   118    92    42     8
v     1     8    28    56    70    56    28     8     1 

n 9
v     1     9    36    84   126   126    84    36     9     1
v     9    56   149   231   259   259   231   149    56     9
v    36   149   260   286   277   277   286   260   149    36
v    84   231   286   256   220   220   256   286   231    84
v   126   259   277   220   140   140   220   277   259   126
v   126   259   277   220   140   140   220   277   259   126
v    84   231   286   256   220   220   256   286   231    84
v    36   149   260   286   277   277   286   260   149    36
v     9    56   149   231   259   259   231   149    56     9
v     1     9    36    84   126   126    84    36     9     1 

n 10
v     1    10    45   120   210   252   210   120    45    10     1
v    10    72   226   416   532   560   532   416   226    72    10
v    45   226   486   636   661   660   661   636   486   226    45
v   120   416   636   654   598   568   598   654   636   416   120
v   210   532   661   598   468   396   468   598   661   532   210
v   252   560   660   568   396     0   396   568   660   560   252
v   210   532   661   598   468   396   468   598   661   532   210
v   120   416   636   654   598   568   598   654   636   416   120
v    45   226   486   636   661   660   661   636   486   226    45
v    10    72   226   416   532   560   532   416   226    72    10
v     1    10    45   120   210   252   210   120    45    10     1 

n 11
v     1    11    55   165   330   462   462   330   165    55    11     1
v    11    90   326   699  1026  1176  1176  1026   699   326    90    11
v    55   326   840  1301  1500  1546  1546  1500  1301   840   326    55
v   165   699  1301  1552  1532  1467  1467  1532  1552  1301   699   165
v   330  1026  1500  1532  1340  1157  1157  1340  1532  1500  1026   330
v   462  1176  1546  1467  1157   744   744  1157  1467  1546  1176   462
v   462  1176  1546  1467  1157   744   744  1157  1467  1546  1176   462
v   330  1026  1500  1532  1340  1157  1157  1340  1532  1500  1026   330
v   165   699  1301  1552  1532  1467  1467  1532  1552  1301   699   165
v    55   326   840  1301  1500  1546  1546  1500  1301   840   326    55
v    11    90   326   699  1026  1176  1176  1026   699   326    90    11
v     1    11    55   165   330   462   462   330   165    55    11     1 

n 12
v     1    12    66   220   495   792   924   792   495   220    66    12     1
v    12   110   452  1110  1860  2364  2520  2364  1860  1110   452   110    12
v    66   452  1364  2470  3210  3510  3584  3510  3210  2470  1364   452    66
v   220  1110  2470  3428  3712  3686  3644  3686  3712  3428  2470  1110   220
v   495  1860  3210  3712  3558  3216  3054  3216  3558  3712  3210  1860   495
v   792  2364  3510  3686  3216  2532  2164  2532  3216  3686  3510  2364   792
v   924  2520  3584  3644  3054  2164     0  2164  3054  3644  3584  2520   924
v   792  2364  3510  3686  3216  2532  2164  2532  3216  3686  3510  2364   792
v   495  1860  3210  3712  3558  3216  3054  3216  3558  3712  3210  1860   495
v   220  1110  2470  3428  3712  3686  3644  3686  3712  3428  2470  1110   220
v    66   452  1364  2470  3210  3510  3584  3510  3210  2470  1364   452    66
v    12   110   452  1110  1860  2364  2520  2364  1860  1110   452   110    12
v     1    12    66   220   495   792   924   792   495   220    66    12     1 

n 13
v     1    13    78   286   715  1287  1716  1716  1287   715   286    78    13     1
v    13   132   607  1683  3190  4521  5214  5214  4521  3190  1683   607   132    13
v    78   607  2106  4398  6467  7656  8128  8128  7656  6467  4398  2106   607    78
v   286  1683  4398  7072  8506  8923  8956  8956  8923  8506  7072  4398  1683   286
v   715  3190  6467  8506  8924  8518  8080  8080  8518  8924  8506  6467  3190   715
v  1287  4521  7656  8923  8518  7366  6387  6387  7366  8518  8923  7656  4521  1287
v  1716  5214  8128  8956  8080  6387  4116  4116  6387  8080  8956  8128  5214  1716
v  1716  5214  8128  8956  8080  6387  4116  4116  6387  8080  8956  8128  5214  1716
v  1287  4521  7656  8923  8518  7366  6387  6387  7366  8518  8923  7656  4521  1287
v   715  3190  6467  8506  8924  8518  8080  8080  8518  8924  8506  6467  3190   715
v   286  1683  4398  7072  8506  8923  8956  8956  8923  8506  7072  4398  1683   286
v    78   607  2106  4398  6467  7656  8128  8128  7656  6467  4398  2106   607    78
v    13   132   607  1683  3190  4521  5214  5214  4521  3190  1683   607   132    13
v     1    13    78   286   715  1287  1716  1716  1287   715   286    78    13     1 

n 14
v     1    14    91   364  1001  2002  3003  3432  3003  2002  1001   364    91    14     1
v    14   156   794  2456  5214  8228 10362 11088 10362  8228  5214  2456   794   156    14
v    91   794  3120  7416 12302 15958 17895 18480 17895 15958 12302  7416  3120   794    91
v   364  2456  7416 13706 18430 20724 21502 21652 21502 20724 18430 13706  7416  2456   364
v  1001  5214 12302 18430 21260 21568 20941 20584 20941 21568 21260 18430 12302  5214  1001
v  2002  8228 15958 20724 21568 20030 18006 17100 18006 20030 21568 20724 15958  8228  2002
v  3003 10362 17895 21502 20941 18006 14220 12240 14220 18006 20941 21502 17895 10362  3003
v  3432 11088 18480 21652 20584 17100 12240     0 12240 17100 20584 21652 18480 11088  3432
v  3003 10362 17895 21502 20941 18006 14220 12240 14220 18006 20941 21502 17895 10362  3003
v  2002  8228 15958 20724 21568 20030 18006 17100 18006 20030 21568 20724 15958  8228  2002
v  1001  5214 12302 18430 21260 21568 20941 20584 20941 21568 21260 18430 12302  5214  1001
v   364  2456  7416 13706 18430 20724 21502 21652 21502 20724 18430 13706  7416  2456   364
v    91   794  3120  7416 12302 15958 17895 18480 17895 15958 12302  7416  3120   794    91
v    14   156   794  2456  5214  8228 10362 11088 10362  8228  5214  2456   794   156    14
v     1    14    91   364  1001  2002  3003  3432  3003  2002  1001   364    91    14     1 

n 15
v     1    15   105   455  1365  3003  5005  6435  6435  5005  3003  1365   455   105    15     1
v    15   182  1016  3471  8177 14300 19734 22737 22737 19734 14300  8177  3471  1016   182    15
v   105  1016  4466 11941 22211 31730 38052 41007 41007 38052 31730 22211 11941  4466  1016   105
v   455  3471 11941 25124 37813 46068 50084 51540 51540 50084 46068 37813 25124 11941  3471   455
v  1365  8177 22211 37813 48188 52301 52705 52104 52104 52705 52301 48188 37813 22211  8177  1365
v  3003 14300 31730 46068 52301 51932 48665 45958 45958 48665 51932 52301 46068 31730 14300  3003
v  5005 19734 38052 50084 52705 48665 41872 36443 36443 41872 48665 52705 50084 38052 19734  5005
v  6435 22737 41007 51540 52104 45958 36443 23504 23504 36443 45958 52104 51540 41007 22737  6435
v  6435 22737 41007 51540 52104 45958 36443 23504 23504 36443 45958 52104 51540 41007 22737  6435
v  5005 19734 38052 50084 52705 48665 41872 36443 36443 41872 48665 52705 50084 38052 19734  5005
v  3003 14300 31730 46068 52301 51932 48665 45958 45958 48665 51932 52301 46068 31730 14300  3003
v  1365  8177 22211 37813 48188 52301 52705 52104 52104 52705 52301 48188 37813 22211  8177  1365
v   455  3471 11941 25124 37813 46068 50084 51540 51540 50084 46068 37813 25124 11941  3471   455
v   105  1016  4466 11941 22211 31730 38052 41007 41007 38052 31730 22211 11941  4466  1016   105
v    15   182  1016  3471  8177 14300 19734 22737 22737 19734 14300  8177  3471  1016   182    15
v     1    15   105   455  1365  3003  5005  6435  6435  5005  3003  1365   455   105    15     1

Relationships between different path lengths may not be apparent in this form. So let’s transpose this data. Instead of looking at each path length independently, let’s look at each column together:

c  0
------------------------------------------------------------------------------------------------------
n  0 |     1
n  1 |     1     1
n  2 |     1     2     1
n  3 |     1     3     3     1
n  4 |     1     4     6     4     1
n  5 |     1     5    10    10     5     1
n  6 |     1     6    15    20    15     6     1
n  7 |     1     7    21    35    35    21     7     1
n  8 |     1     8    28    56    70    56    28     8     1
n  9 |     1     9    36    84   126   126    84    36     9     1
n 10 |     1    10    45   120   210   252   210   120    45    10     1
n 11 |     1    11    55   165   330   462   462   330   165    55    11     1
n 12 |     1    12    66   220   495   792   924   792   495   220    66    12     1
n 13 |     1    13    78   286   715  1287  1716  1716  1287   715   286    78    13     1
n 14 |     1    14    91   364  1001  2002  3003  3432  3003  2002  1001   364    91    14     1
n 15 |     1    15   105   455  1365  3003  5005  6435  6435  5005  3003  1365   455   105    15     1 

c  1
------------------------------------------------------------------------------------------------------
n  1 |     1     1
n  2 |     2     0     2
n  3 |     3     2     2     3
n  4 |     4     6     4     6     4
n  5 |     5    12    11    11    12     5
n  6 |     6    20    26    24    26    20     6
n  7 |     7    30    52    55    55    52    30     7
n  8 |     8    42    92   118   120   118    92    42     8
n  9 |     9    56   149   231   259   259   231   149    56     9
n 10 |    10    72   226   416   532   560   532   416   226    72    10
n 11 |    11    90   326   699  1026  1176  1176  1026   699   326    90    11
n 12 |    12   110   452  1110  1860  2364  2520  2364  1860  1110   452   110    12
n 13 |    13   132   607  1683  3190  4521  5214  5214  4521  3190  1683   607   132    13
n 14 |    14   156   794  2456  5214  8228 10362 11088 10362  8228  5214  2456   794   156    14
n 15 |    15   182  1016  3471  8177 14300 19734 22737 22737 19734 14300  8177  3471  1016   182    15 

c  2
------------------------------------------------------------------------------------------------------
n  2 |     1     2     1
n  3 |     3     2     2     3
n  4 |     6     4     0     4     6
n  5 |    10    11     6     6    11    10
n  6 |    15    26    20    16    20    26    15
n  7 |    21    52    54    45    45    54    52    21
n  8 |    28    92   126   118   112   118   126    92    28
n  9 |    36   149   260   286   277   277   286   260   149    36
n 10 |    45   226   486   636   661   660   661   636   486   226    45
n 11 |    55   326   840  1301  1500  1546  1546  1500  1301   840   326    55
n 12 |    66   452  1364  2470  3210  3510  3584  3510  3210  2470  1364   452    66
n 13 |    78   607  2106  4398  6467  7656  8128  8128  7656  6467  4398  2106   607    78
n 14 |    91   794  3120  7416 12302 15958 17895 18480 17895 15958 12302  7416  3120   794    91
n 15 |   105  1016  4466 11941 22211 31730 38052 41007 41007 38052 31730 22211 11941  4466  1016   105 

c  3
------------------------------------------------------------------------------------------------------
n  3 |     1     3     3     1
n  4 |     4     6     4     6     4
n  5 |    10    11     6     6    11    10
n  6 |    20    24    16     0    16    24    20
n  7 |    35    55    45    28    28    45    55    35
n  8 |    56   118   118    92    76    92   118   118    56
n  9 |    84   231   286   256   220   220   256   286   231    84
n 10 |   120   416   636   654   598   568   598   654   636   416   120
n 11 |   165   699  1301  1552  1532  1467  1467  1532  1552  1301   699   165
n 12 |   220  1110  2470  3428  3712  3686  3644  3686  3712  3428  2470  1110   220
n 13 |   286  1683  4398  7072  8506  8923  8956  8956  8923  8506  7072  4398  1683   286
n 14 |   364  2456  7416 13706 18430 20724 21502 21652 21502 20724 18430 13706  7416  2456   364
n 15 |   455  3471 11941 25124 37813 46068 50084 51540 51540 50084 46068 37813 25124 11941  3471   455 

c  4
------------------------------------------------------------------------------------------------------
n  4 |     1     4     6     4     1
n  5 |     5    12    11    11    12     5
n  6 |    15    26    20    16    20    26    15
n  7 |    35    55    45    28    28    45    55    35
n  8 |    70   120   112    76     0    76   112   120    70
n  9 |   126   259   277   220   140   140   220   277   259   126
n 10 |   210   532   661   598   468   396   468   598   661   532   210
n 11 |   330  1026  1500  1532  1340  1157  1157  1340  1532  1500  1026   330
n 12 |   495  1860  3210  3712  3558  3216  3054  3216  3558  3712  3210  1860   495
n 13 |   715  3190  6467  8506  8924  8518  8080  8080  8518  8924  8506  6467  3190   715
n 14 |  1001  5214 12302 18430 21260 21568 20941 20584 20941 21568 21260 18430 12302  5214  1001
n 15 |  1365  8177 22211 37813 48188 52301 52705 52104 52104 52705 52301 48188 37813 22211  8177  1365 

c  5
------------------------------------------------------------------------------------------------------
n  5 |     1     5    10    10     5     1
n  6 |     6    20    26    24    26    20     6
n  7 |    21    52    54    45    45    54    52    21
n  8 |    56   118   118    92    76    92   118   118    56
n  9 |   126   259   277   220   140   140   220   277   259   126
n 10 |   252   560   660   568   396     0   396   568   660   560   252
n 11 |   462  1176  1546  1467  1157   744   744  1157  1467  1546  1176   462
n 12 |   792  2364  3510  3686  3216  2532  2164  2532  3216  3686  3510  2364   792
n 13 |  1287  4521  7656  8923  8518  7366  6387  6387  7366  8518  8923  7656  4521  1287
n 14 |  2002  8228 15958 20724 21568 20030 18006 17100 18006 20030 21568 20724 15958  8228  2002
n 15 |  3003 14300 31730 46068 52301 51932 48665 45958 45958 48665 51932 52301 46068 31730 14300  3003 

c  6
------------------------------------------------------------------------------------------------------
n  6 |     1     6    15    20    15     6     1
n  7 |     7    30    52    55    55    52    30     7
n  8 |    28    92   126   118   112   118   126    92    28
n  9 |    84   231   286   256   220   220   256   286   231    84
n 10 |   210   532   661   598   468   396   468   598   661   532   210
n 11 |   462  1176  1546  1467  1157   744   744  1157  1467  1546  1176   462
n 12 |   924  2520  3584  3644  3054  2164     0  2164  3054  3644  3584  2520   924
n 13 |  1716  5214  8128  8956  8080  6387  4116  4116  6387  8080  8956  8128  5214  1716
n 14 |  3003 10362 17895 21502 20941 18006 14220 12240 14220 18006 20941 21502 17895 10362  3003
n 15 |  5005 19734 38052 50084 52705 48665 41872 36443 36443 41872 48665 52705 50084 38052 19734  5005 

c  7
------------------------------------------------------------------------------------------------------
n  7 |     1     7    21    35    35    21     7     1
n  8 |     8    42    92   118   120   118    92    42     8
n  9 |    36   149   260   286   277   277   286   260   149    36
n 10 |   120   416   636   654   598   568   598   654   636   416   120
n 11 |   330  1026  1500  1532  1340  1157  1157  1340  1532  1500  1026   330
n 12 |   792  2364  3510  3686  3216  2532  2164  2532  3216  3686  3510  2364   792
n 13 |  1716  5214  8128  8956  8080  6387  4116  4116  6387  8080  8956  8128  5214  1716
n 14 |  3432 11088 18480 21652 20584 17100 12240     0 12240 17100 20584 21652 18480 11088  3432
n 15 |  6435 22737 41007 51540 52104 45958 36443 23504 23504 36443 45958 52104 51540 41007 22737  6435 

c  8
------------------------------------------------------------------------------------------------------
n  8 |     1     8    28    56    70    56    28     8     1
n  9 |     9    56   149   231   259   259   231   149    56     9
n 10 |    45   226   486   636   661   660   661   636   486   226    45
n 11 |   165   699  1301  1552  1532  1467  1467  1532  1552  1301   699   165
n 12 |   495  1860  3210  3712  3558  3216  3054  3216  3558  3712  3210  1860   495
n 13 |  1287  4521  7656  8923  8518  7366  6387  6387  7366  8518  8923  7656  4521  1287
n 14 |  3003 10362 17895 21502 20941 18006 14220 12240 14220 18006 20941 21502 17895 10362  3003
n 15 |  6435 22737 41007 51540 52104 45958 36443 23504 23504 36443 45958 52104 51540 41007 22737  6435 

c  9
------------------------------------------------------------------------------------------------------
n  9 |     1     9    36    84   126   126    84    36     9     1
n 10 |    10    72   226   416   532   560   532   416   226    72    10
n 11 |    55   326   840  1301  1500  1546  1546  1500  1301   840   326    55
n 12 |   220  1110  2470  3428  3712  3686  3644  3686  3712  3428  2470  1110   220
n 13 |   715  3190  6467  8506  8924  8518  8080  8080  8518  8924  8506  6467  3190   715
n 14 |  2002  8228 15958 20724 21568 20030 18006 17100 18006 20030 21568 20724 15958  8228  2002
n 15 |  5005 19734 38052 50084 52705 48665 41872 36443 36443 41872 48665 52705 50084 38052 19734  5005 

c 10
------------------------------------------------------------------------------------------------------
n 10 |     1    10    45   120   210   252   210   120    45    10     1
n 11 |    11    90   326   699  1026  1176  1176  1026   699   326    90    11
n 12 |    66   452  1364  2470  3210  3510  3584  3510  3210  2470  1364   452    66
n 13 |   286  1683  4398  7072  8506  8923  8956  8956  8923  8506  7072  4398  1683   286
n 14 |  1001  5214 12302 18430 21260 21568 20941 20584 20941 21568 21260 18430 12302  5214  1001
n 15 |  3003 14300 31730 46068 52301 51932 48665 45958 45958 48665 51932 52301 46068 31730 14300  3003 

c 11
------------------------------------------------------------------------------------------------------
n 11 |     1    11    55   165   330   462   462   330   165    55    11     1
n 12 |    12   110   452  1110  1860  2364  2520  2364  1860  1110   452   110    12
n 13 |    78   607  2106  4398  6467  7656  8128  8128  7656  6467  4398  2106   607    78
n 14 |   364  2456  7416 13706 18430 20724 21502 21652 21502 20724 18430 13706  7416  2456   364
n 15 |  1365  8177 22211 37813 48188 52301 52705 52104 52104 52705 52301 48188 37813 22211  8177  1365 

c 12
------------------------------------------------------------------------------------------------------
n 12 |     1    12    66   220   495   792   924   792   495   220    66    12     1
n 13 |    13   132   607  1683  3190  4521  5214  5214  4521  3190  1683   607   132    13
n 14 |    91   794  3120  7416 12302 15958 17895 18480 17895 15958 12302  7416  3120   794    91
n 15 |   455  3471 11941 25124 37813 46068 50084 51540 51540 50084 46068 37813 25124 11941  3471   455 

c 13
------------------------------------------------------------------------------------------------------
n 13 |     1    13    78   286   715  1287  1716  1716  1287   715   286    78    13     1
n 14 |    14   156   794  2456  5214  8228 10362 11088 10362  8228  5214  2456   794   156    14
n 15 |   105  1016  4466 11941 22211 31730 38052 41007 41007 38052 31730 22211 11941  4466  1016   105 

c 14
------------------------------------------------------------------------------------------------------
n 14 |     1    14    91   364  1001  2002  3003  3432  3003  2002  1001   364    91    14     1
n 15 |    15   182  1016  3471  8177 14300 19734 22737 22737 19734 14300  8177  3471  1016   182    15 

c 15
------------------------------------------------------------------------------------------------------
n 15 |     1    15   105   455  1365  3003  5005  6435  6435  5005  3003  1365   455   105    15     1

Now looking at these counts, it should be much more apparent there is a relationship between end point path counts of different path lengths.

Let’s start by looking at column 0. When you take into account mirroring and rotation of the quadrants, column 0 represents the “outer edge” of the square matrix of end point counts.

For example, of path length 8, these counts:

c  0
------------------------------------------------------------------------------------------------------
n  0 |     1
n  1 |     1     1
n  2 |     1     2     1
n  3 |     1     3     3     1
n  4 |     1     4     6     4     1
n  5 |     1     5    10    10     5     1
n  6 |     1     6    15    20    15     6     1
n  7 |     1     7    21    35    35    21     7     1
n  8 |     1     8    28    56    70    56    28     8     1 
n  9 |     1     9    36    84   126   126    84    36     9     1
n 10 |     1    10    45   120   210   252   210   120    45    10     1
n 11 |     1    11    55   165   330   462   462   330   165    55    11     1
n 12 |     1    12    66   220   495   792   924   792   495   220    66    12     1
n 13 |     1    13    78   286   715  1287  1716  1716  1287   715   286    78    13     1
n 14 |     1    14    91   364  1001  2002  3003  3432  3003  2002  1001   364    91    14     1
n 15 |     1    15   105   455  1365  3003  5005  6435  6435  5005  3003  1365   455   105    15     1

Are found here:

00001 00008 00028 00056 00070 00056 00028 00008 00001
00008 00042 00092 00118 00120 00118 00092 00042 00008
00028 00092 00126 00118 00112 00118 00126 00092 00028
00056 00118 00118 00092 00076 00092 00118 00118 00056
00070 00120 00112 00076 ***** 00076 00112 00120 00070
00056 00118 00118 00092 00076 00092 00118 00118 00056
00028 00092 00126 00118 00112 00118 00126 00092 00028
00008 00042 00092 00118 00120 00118 00092 00042 00008
00001 00008 00028 00056 00070 00056 00028 00008 00001
EndPointCount: 80
TotalWalkCount: 5916

If the pattern of values in column 0 seem familiar, that’s because:

In other words, the outer edge of end point counts for path length n are the values in the nth row in Pascal’s Triangle.

At the very least it should be apparent why the first column of column 0 is always 1. That value represents the outermost tip of the end points. Which always only be reached by exactly one path. Or, for any paths of length n, there are four paths (NSEW) that are straight line paths that reach the four furthest corners permissible by a path of length n.

To generate column 0, we can define it (Pascal’s Triangle) as a recursive function (recurrence relation):
Let’s call the function that generates column 0, f0. And n is the path length (down) and i is the column in this form (across)
f0(n,i) = f0(n-1,i) + f0(n-1,i-1)

Here is an awk script which generates the values in this form. fcol0.awk

c  0 | f0(n,i) = f0(n-1,i) + f0(n-1,i-1)
------------------------------------------------------------------------------------------------------
n  0 |     1
n  1 |     1     1
n  2 |     1     2     1
n  3 |     1     3     3     1
n  4 |     1     4     6     4     1
n  5 |     1     5    10    10     5     1
n  6 |     1     6    15    20    15     6     1
n  7 |     1     7    21    35    35    21     7     1
n  8 |     1     8    28    56    70    56    28     8     1
n  9 |     1     9    36    84   126   126    84    36     9     1
n 10 |     1    10    45   120   210   252   210   120    45    10     1
n 11 |     1    11    55   165   330   462   462   330   165    55    11     1
n 12 |     1    12    66   220   495   792   924   792   495   220    66    12     1
n 13 |     1    13    78   286   715  1287  1716  1716  1287   715   286    78    13     1
n 14 |     1    14    91   364  1001  2002  3003  3432  3003  2002  1001   364    91    14     1
n 15 |     1    15   105   455  1365  3003  5005  6435  6435  5005  3003  1365   455   105    15     1

So if we now go back to path length 8, we can also predict the first column and only the following end points in green remain to be calculated:

00001 00008 00028 00056 00070 00056 00028 00008 00001
00008 00042 00092 00118 00120 00118 00092 00042 00008
00028 00092 00126 00118 00112 00118 00126 00092 00028
00056 00118 00118 00092 00076 00092 00118 00118 00056
00070 00120 00112 00076 ***** 00076 00112 00120 00070
00056 00118 00118 00092 00076 00092 00118 00118 00056
00028 00092 00126 00118 00112 00118 00126 00092 00028
00008 00042 00092 00118 00120 00118 00092 00042 00008
00001 00008 00028 00056 00070 00056 00028 00008 00001
EndPointCount: 80
TotalWalkCount: 5916

In the next part, we’ll look at the patterns of the other columns and how to predict the patterns for “future” columns for paths of greater lengths. Lots more to come!

But I’ll give you a hint if you want to start working the patterns out on your own:

Mike.

We have smart, successful women on here now. I would consider them good examples. I don’t want to call anyone out specifically because of their sex parts, but it’s hard not to notice that out of 184 authors, we have something like 6 women posting.

It’s easy to say that #gamedev is a male-dominated industry (so don’t bother, we know.) And while the numbers industry-wide might be lopsided (especially on the programming side, unfortunately), it sure seems that the actual industry ratio is higher. Surely, there is something else going on. I haven’t done a survey or anything, but I wonder if the ratio of men to women #gamedevs blogging is this high.

Ideally, we would beat the industry ratio here. As it is part of the intention of this site to give voice to #gamedevs (and our friends in related work), it would stand to reason that we’d be able to provide a platform for those whose voices are often drowned out.

Anyone have any ideas? Anyone know any other women #gamedevs that might want to post with us?

Mike.

PS: I don’t know if lists like this are good or not, but here you go anyway. FragDolls’ GAME INDUSTRY WOMEN TO KNOW: 2010

If you’re just browsing, you can click on the monthly archives on the right panel. Those are still fresh and up to the minute!

I have just made this front page static temporarily to reduce the load on our server. And hopefully smooth things out a bit until I can work out a more permanent solution.

Thanks for sticking with us!

Mike.

Mike.

Game developers should know this isn’t a yes or no question. Unlike old school bankers stuck in the vainglorious days of million-dollar pool parties, or alarmist CEO’s who call for massive lay-off’s at the first sign of trouble, most game developers have had the privilege of seeing things from the underdog perspective. By their nature underdogs tend to challenge the status quo and eschew the easy answers. Rather than sink or swim we might make a sail, build a submarine, or find a hundred different ways to get out of the water. We’ve just never been as limited in our thinking as those other guys, right?

Then why is it that game developers are beginning to drown in a culture of fear, or more specifically, a fear of change? Is it because the gaming world has gone too corporate and is no longer exclusive to small teams of genius misfits and creative underdogs? Is it because the demographics of game players—once made up almost exclusively of teen boys—has widened to include nearly everyone from 5-50?

There are people who would deny that it’s fear of change that keeps them where they are. There are those that are content with the status quo because they believe that they have a formula “that works” and there’s no good reason to risk a major change when they already successful with what they’re doing. At best, they’ll take a “wait and see” approach, confident that they can learn from others’ mistakes and jump in if and when it becomes necessary. However, to those I say that the real risk is in waiting too long and letting the opportunity for change and grow pass you by.

“So there’s no question that they’re scared; they’re scared of screwing up a transition. Right now they have a model that they know works and they don’t know if other models will work for them. And, consequently, that’s why you see them moving so damned slowly.” – Paul Hyman, The Necessity Of Making Free-to-Play Moves (gamasutra.com)

Whatever the reasons for their fear and consequent sluggishness, game developers need to get back to their rebellious roots and do what they do best—being catalysts for innovation and evolution. They don’t need to merely embrace change; they need to create the products and ideals that change the gaming environment and keep it fresh. Game developers are, at their heart, futurists and this is what they need to do now—put themselves ahead of the times so that they can surpass the stale leadership and old models that are holding them back. Our collective destiny should not be held hostage to one-size-fits-all concepts or obsolete ideals.

Game Development Needs Giants—And A Bigger Vision

Nanos gigantium humeris insidentes. Or, as famously quoted by Isaac Newton, “If I have seen further, it is only because I have stood on the shoulders of giants.” While many game developers continue to improve on existing ideas and platforms, others think in more revolutionary terms. There is abundant room in our industry for both the giants and those who would stand on their shoulders. Before individual developers can know which position suits them best, they have to recognize their own goals. What does making a great game mean?

• An uncompromising expression of artistic vision?
• A fantastic diversion for a niche crowd?
• Reaching the widest audience and making the most money?
• Creating something transformative, that challenges the status quo?

The possibilities are wide open. We need only an honest appraisal of our authentic motivations. Is it our goal as game developers to leave our mark on the world? To teach something to others, affect some cultural change, or explore the depths of our own creativity? Knowing the answers to these questions won’t make you a great game developer, but they will give you a clearer focus and help you avoid the distracting maze of less important questions that tend to waste creative talents. Fundamental questions like—What are games? Who should they appeal to? What defining boxes do they fit into? Do we fit our games to an audience or create an audience for our games? Are social, mobile, F2P games, etc., the future?—have been asked hundreds of times before. The simple answer to all of them is that as developers, if we invent the scenario we also get to define (or break) the rules and create the audience and outcome and drive the platform. We don’t have to be bogged down by any particular paradigm except the one that recognizes that change is constant, and that we can either help create that change or merely find ourselves adjusting to it in second-party fashion.

“Social network models are disrupting the traditional gaming industry with superior pricing, business and economic models.” – Chris Carvalho, Hardcore Social Gaming Disrupting the Industry (industrygamers.com)

“We have not been this uncertain about what’s coming next in the games industry since Epic’s been around for 20 years.” – Mike Capps, Epic: 99-Cent Apps Are ‘Killing Us’ (industrygamers.com)

“The ripple effect is now that you *cannot* price a game correctly according to scope and effort, because so many games are *not* priced that way . . . – Jake Simpson, The Race to the Bottom (altdevblogaday.com)

Change is going to happen because it must. The most sought after game developers in the future will be those who not only “adjust, adapt, and overcome” but who also take the lead in revolutionary new schools of thought and opportunity.

Five Signs of the Old School Apocalypse

1. The independent game market is thriving. I would venture to guess that more indie games have been produced in the last three years than in the last 25 years combined. Or close to that anyway. Just a few short years ago, everyone was sure that the end of indie games was near. Instead, what we’ve seen is an absolute explosion of Indies. There is an ecosystem that can support independent game development, and right now it is on fire! iOS development is the obvious example.
2. Serious games are finally catching some momentum. Fundamentally, people now actually believe (rightly) that using games to teach and to learn about the world around us is one of the most effective methods we have at our disposal. We’ve just seen the beginning, but you can’t speak seriously about the future of education and training without considering how games will play a significant, if not the most significant, part in schools, learning centers, and independent studies.
3. Social and mobile games are rapidly growing in popularity. There’s been a tendency to look at the success of games in social and mobile spaces in a way that conflates the success of a particular type of game or genre of game with the space or platform. That’s completely backward in my opinion. The real transformation is not “social games” or “mobile games” (which are fairly meaningless descriptions), but rather the success of games in new spaces—the recognition of both a wider appeal beyond the traditional “core” audience and a reflection of the broader world. Games are simply and inevitably wherever people are.
4. Gamification. There is some debate over the word itself (much disliked among certain game developers) and the use of certain “techniques” like pointsification and friendsploitation (see also: exploitionware and alternatively, gameful design). But there is no question that whatever you call it, and whether or not you understand it fully, or use it appropriately, games have been recognized for their ability to make a difference in the way people see and interact with the world. Whether used for marketing a product, engaging people in activities they’d otherwise find boring, or simply adding a bit of fun to something, the lessons we’ve learned in developing games are powerful and useful tools.
5. A ‘change the world’ philosophy is edging its way into game development. If anything makes it obvious that games have leveled up, it’s the belief that games can affect culture and attitudes—and not just in a happy Pollyanna way, either. Savvy game developers are beginning to see how games can help give people insight into their world, and that games don’t have to make light or fun of big problems in order to educate people. We have started to see games take their rightful place among other socially meaningful and artistic media like writing, painting, and film and like those, it can be used as a tool to humanize issues. Interactively engaging and learning about subjects like war, violence, loss, tragedy, poverty, clean water, etc. can put issues into perspective and give people the incentive and knowledge to make real change.

Of course, the most significant change in games is their ongoing success. Video games have become an accepted and integral part of our larger culture, with applications that are continuously growing in both scope and potential.

It’s time for game developers to get out of their own way. To refuse to be boxed in by fear or creatively diminished by rigid, outdated schools of thought. We need to reclaim our genius, expand our visions, and get back to doing what we do best: Evolving our products and ourselves and taking the world along with us.

We need to aim higher.

Mike.

Thanks to Matt Yaney, Rob Crossley and Leigh Alexander for lending their valuable time, expertise and advice on clarifying my thoughts here. You rock.

I think it’s about time that I started regular updates to help keep not just our authors, but everyone, informed of what’s happening here at #AltDevBlogADay.

This last month, you may have noticed the theme changes that have been happening. Expect another major revision there soon. But the important thing to share is that part of the process of developing a new theme was for me to figure out what the vision for this site really was. What’s important for me here?

In particular, you may have noticed that on the home page I changed the preview images to be images of the authors as well as adding a featured author section to the top of the site. Some of you might not like these changes so far. I’ll share with you what I wrote on our mailing list at the time based on some of the internal feedback I was getting.

#AltDevBlogADay is focused on the authors.

It is important to me to focus on the voice and the individual. The world has changed. We are no longer a world of faceless masses hidden behind corporations or governments or other institutions. The world has become more personal. We want to know who is behind the curtain. That is important. You cannot separate the message from the voice. While that’s clearly my own view of our new collective culture, it is, I think, valid. And that’s what I want to reflect in the site. Now, I also think that honestly some of you underestimate considerably how interesting you actually are. And that is what is compelling for me. Lots of things are said in posts that I disagree with, sometimes technically or from a design pov, but always I’m fascinated by the stories behind those posts. In the more personal history
and context that lead to that view.

In addition, we learn and change and grow constantly. Our posts are not ever green. Nor should they be. They simply reflect what we accept and think now. In five or ten years so much of whatever we might say now will seem naive or even plainly wrong in retrospect. At least I hope so. I know that I hope that of myself, and it’s true to one degree or another of things I might’ve said or posted ten years ago. But to stand up and say with your own voice what you believe right now and put it out there, that’s the interesting part. Recording some small part of everyone’s personal journey, that’s fascinating. And being willing to do it regularly often in spite of not knowing what really to say, or how best to say it or even if there will be real value there is in equal parts a little bit scary, a little bit stupid and a little bit brave.

While I’m open to suggestions on the form of the site and I’ve been happy to get the feedback on it up to now, the fundamental focus is what it is. At least for me. As for the design appearing amateurish, I make no apologies for that. I’m learning and practicing and trying new things. That’s the nature of everything we do. And I don’t mind looking a little bit foolish in the process. The only way to learn is to do. And this is something I’d like to learn.

Mike.

In addition, my hope is that by helping to giving real developers a voice and put them in front of you naked and open, that we will all learn from each other.

Since E3 is this week, it reminds me that one of the things that inspires me most is during conferences or other meetups when I’m able to sit down with my peers and friends and share ideas and just talk and have a little fun. All of the really best moments (and ideas) in my career have been when I’ve just been able to sit down and talk and listen and share with others. And I think the real vision for #AltDevBlogADay is to bring that late-night-at-a-conference-sharing feeling to us as a group every damn day instead of just a couple times a year. While I don’t think we’re quite there yet, I know we’ll get there. And I can’t wait!

Today, I’d like you let you know that we’ve been thinking hard on #AltDevBlogADay Phase 2. We want to raise the bar for what we doing and really bring more value to both the authors here and you guys, the readers. News on that soon enough. :)

So I hope you like what we’re doing here and you can support us by (re)tweeting or sharing on facebook, sharing your thoughts in the comments, or posting and linking from other development sites (like from reddit – I know there are a lot of you out there!) that you think might be interested in our posts. And of course, I encourage you to join us here as a regular author!

And comment below if you have any thoughts on how we can improve things.

Mike.

Here at #AltDevBlogADay we’re going to celebrate by talking about a couple of the kids in our group to represent the many, many children loved and adored by parents who post on this site. And to remind ourselves that our kids probably teach us more than we could ever teach them.

Isabelle, next-gen hacker

#AltDevParent: Mattias Jansson

Since our daughter is only days old and I have still to wrap my head around the fact that I’m the father of the little gorgeoud creature above, I thought I’d just share some thoughts on paternal leave, and how it works here in Sweden. Parents get 480 days of paid paternal leave by the government, during which you get 80% (roughly) of your normal income as benefit. The days can be divided freely between the two parents, and if you split them equally the government give you some extra cash as equality bonus. You also get 10 extra days in connection with the birth, to allow you to stay at the hospital for a couple of days and get everything sorted at home. Oh, and of course all the care and services at the hospital is free.

The paternal leave is protected by law, the employer cannot deny you your days off. Not that I would have any issues with that, since Starbreeze is very parent-friendly. As an added perk, after the 10 days leave in connection with the birth I get one month where I can work only 80% but still get paid 100%. Yay!

All in all, I’m very happy with the Swedish way of doing things, and I’m really looking forward to taking care of my newborn daughter. I’m sure it will be a blast, and that I will actually end up with a healthy new way of looking at work and my passion for programming.

Dylan, Karl and Rose

#AltDevParent: Thaddaeus Frogley

I have 3 kids, pictured (attached) playing in my parents garden from left to right: Dylan (9), Karl (6) and Rose (2).

Dylan was born severely premature, and has been diagnosed with Dubowitz Syndrome.

Karl is a normal little boy. Rose was not premature, but has some developmental delays that suggest she may also have mild Dubowitz.

The boys are at school right now, and I’m looking after Rose (I have the day off work). My wife is some kind of saint/ miracle worker looking after them full time!

This email has taken me something like 30mins to write just looking after Rose, and I have no idea how working from home can be productive with kids in the house!

The boys love playing DSi, Wii, and web-games. The “Lego” games (Batman, Star Wars, etc) are their favourites on DS, and on Wii they like to play Ben10, Gormiti, Sonic Colours, and Wii Fit.

As a parent, gamer, and game developer, I feel strongly that game age ratings should work, and be respected by both the industry and consumers. Adult themed games have as much a place in society as equivalent movies, and that it is a parents responsibility to audit what their children are exposed too, on TV, games, and the internet.

Our kids

Now get to bed! Clean your room! Do your homework! :)

Mike.

PS: My own daughter says I should add: “Good dads would want to give their daughters rides early tomorrow morning. And would want to give them some spending money.”

If, like me, you haven’t had much time to check out WebGL yet, Savas Ziplies has been writing an introductory series here on #AltDevBlogADay you might want to check out:

• WebGL – Part 1: A new challenger appears…
• WebGL – Part 2: In the beginning there was…

The demo

For comparison, I’ve just rewritten Chromium teapot demo. Here’s the original WebGL version: shiny-teapot

Graphically there’s really no difference. (Click and drag teapot to rotate.)
See the source: demo.js

The jQuery plugins

In the process of working on many variations of the aforementioned lighting demo, there was a lot of WebGL housekeeping setup that I had to do over and over. Looking over the data in the source shader and model files, it seemed like all of that information was already there. I was just typing it in multiple times. And making multiple mistakes doing it! One of the first rules of usability is The Default Behavior should be The Right Behavior, most of the time. I didn’t find that to be true with the WebGL setup. It’s not a lot different from the typical OpenGL (or DirectX) interface in that regard.

However, since everything with WebGL is done in Javascript, and the shaders are compiled from text, I figured all the information is there to simplify the setup process and I wanted to try my hand at writing some jQuery plugins to do it. I’m no jQuery or javascript ninja, so this was also a good opportunity for me to play around a bit more there too.

I wrote three basic plugins:

• $.glProgram which handles loading and compiling of fragment and vertex shaders.
• $.glModel which handles loading of JSON model files.
• $.glTexture which handles loading images and building textures and cube maps from them.

You can find the source of the plugins here: macton-gl-utils.js

$.glProgram

Loading a program with the plugin is very straightforward. Just specify the vertex and fragment shaders. The plugin will load the shader source files (from external files) and compile them into a gl program. The plugin will also scan the source and find all the uniforms and attributes automatically. The uniform locations will be cached along with the types used for both the uniforms and attributes. Because the locations and type information is now available, it can be used (later) to simplify the binding process.

Here’s how the teapot program is loaded with the plugin:
You can also see the shader sources: bump_reflect.fs, bump_reflect.vs

1
2
3
4
5
6

  var bump_reflect_program_config = 
  {
    VertexProgramURL:   './shaders/bump_reflect.vs',
    FragmentProgramURL: './shaders/bump_reflect.fs',
  };
  bump_reflect_program = new $.glProgram( gl, bump_reflect_program_config, ProgramLoaded );

Below is how it was loaded in the original demo. Note:

• The vertex and fragment program sources were defined inline. (They’re much easier to work with as separate source files.)
• The uniforms locations and cached by name, even though that information is already available in the source
• The attributes are bound by name. Again that information is available in the source. And there’s not likely to be something else you’re going to want to do with attributes other than bind them.
• The source files and compiled and linked into a program manually. Even though (again), I’m not sure what else you’d want to do with them besides that.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114

var bumpReflectVertexSource = [
    "attribute vec3 g_Position;",
    "attribute vec3 g_TexCoord0;",
    "attribute vec3 g_Tangent;",
    "attribute vec3 g_Binormal;",
    "attribute vec3 g_Normal;",
    "",
    "uniform mat4 world;",
    "uniform mat4 worldInverseTranspose;",
    "uniform mat4 worldViewProj;",
    "uniform mat4 viewInverse;",
    "",
    "varying vec2 texCoord;",
    "varying vec3 worldEyeVec;",
    "varying vec3 worldNormal;",
    "varying vec3 worldTangent;",
    "varying vec3 worldBinorm;",
    "",
    "void main() {",
    "  gl_Position = worldViewProj * vec4(g_Position.xyz, 1.);",
    "  texCoord.xy = g_TexCoord0.xy;",
    "  worldNormal = (worldInverseTranspose * vec4(g_Normal, 1.)).xyz;",
    "  worldTangent = (worldInverseTranspose * vec4(g_Tangent, 1.)).xyz;",
    "  worldBinorm = (worldInverseTranspose * vec4(g_Binormal, 1.)).xyz;",
    "  vec3 worldPos = (world * vec4(g_Position, 1.)).xyz;",
    "  worldEyeVec = normalize(worldPos - viewInverse[3].xyz);",
    "}"
    ].join("\n");
 
var bumpReflectFragmentSource = [
    "#ifdef GL_ES\n",
    "precision highp float;\n",
    "#endif\n",
    "const float bumpHeight = 0.2;",
    "",
    "uniform sampler2D normalSampler;",
    "uniform samplerCube envSampler;",
    "",
    "varying vec2 texCoord;",
    "varying vec3 worldEyeVec;",
    "varying vec3 worldNormal;",
    "varying vec3 worldTangent;",
    "varying vec3 worldBinorm;",
    "",
    "void main() {",
    "  vec2 bump = (texture2D(normalSampler, texCoord.xy).xy * 2.0 - 1.0) * bumpHeight;",
    "  vec3 normal = normalize(worldNormal);",
    "  vec3 tangent = normalize(worldTangent);",
    "  vec3 binormal = normalize(worldBinorm);",
    "  vec3 nb = normal + bump.x * tangent + bump.y * binormal;",
    "  nb = normalize(nb);",
    "  vec3 worldEye = normalize(worldEyeVec);",
    "  vec3 lookup = reflect(worldEye, nb);",
    "  vec4 color = textureCube(envSampler, lookup);",
    "  gl_FragColor = color;",
    "}"
    ].join("\n");
 
function loadShader(type, shaderSrc) {
    var shader = gl.createShader(type);
    if (shader == null) {
        return null;
    }
    // Load the shader source
    gl.shaderSource(shader, shaderSrc);
    // Compile the shader
    gl.compileShader(shader);
    // Check the compile status
    if (!gl.getShaderParameter(shader, gl.COMPILE_STATUS)) {
        var infoLog = gl.getShaderInfoLog(shader);
        output("Error compiling shader:\n" + infoLog);
        gl.deleteShader(shader);
        return null;
    }
    return shader;
}
 
function initShaders() {
    var vertexShader = loadShader(gl.VERTEX_SHADER, bumpReflectVertexSource);
    var fragmentShader = loadShader(gl.FRAGMENT_SHADER, bumpReflectFragmentSource);
    // Create the program object
    var programObject = gl.createProgram();
    if (programObject == null) {
        output("Creating program failed");
        return;
    }
    gl.attachShader(programObject, vertexShader);
    gl.attachShader(programObject, fragmentShader);
    // Bind attributes
    gl.bindAttribLocation(programObject, 0, "g_Position");
    gl.bindAttribLocation(programObject, 1, "g_TexCoord0");
    gl.bindAttribLocation(programObject, 2, "g_Tangent");
    gl.bindAttribLocation(programObject, 3, "g_Binormal");
    gl.bindAttribLocation(programObject, 4, "g_Normal");
    // Link the program
    gl.linkProgram(programObject);
    // Check the link status
    var linked = gl.getProgramParameter(programObject, gl.LINK_STATUS);
    if (!linked) {
        var infoLog = gl.getProgramInfoLog(programObject);
        output("Error linking program:\n" + infoLog);
        gl.deleteProgram(programObject);
        return;
    }
    g_programObject = programObject;
    // Look up uniform locations
    g_worldLoc = gl.getUniformLocation(g_programObject, "world");
    g_worldInverseTransposeLoc = gl.getUniformLocation(g_programObject, "worldInverseTranspose");
    g_worldViewProjLoc = gl.getUniformLocation(g_programObject, "worldViewProj");
    g_viewInverseLoc = gl.getUniformLocation(g_programObject, "viewInverse");
    g_normalSamplerLoc = gl.getUniformLocation(g_programObject, "normalSampler");
    g_envSamplerLoc = gl.getUniformLocation(g_programObject, "envSampler");
    checkGLError();
}

$.glModel

Loading a model with the plugin is even easier than loading a program! Just specify the model JSON data. That’s it. The vertex streams in the JSON data are named, so the plugin can work out that those are attributes that need to (ultimately) be bound to a program and that information is cached. The types and strides are also specified in the JSON data, so the correct fixed array types (e.g. Float32Array) for the WebGL buffers are determined based on those types.

Here is how the teapot model is loaded with the plugin: (You can also see the json file for the teapot here: teapot.json)

1

teapot_model         = new $.glModel(   gl, './models/teapot.json',      ModelLoaded       );

Below is how it was loaded in the original demo. Note:

• The teapot model was stored inline as a javascript variable (much easier to work with as a separate json file). Not shown here for length.
• The buffer sizes and types need to be worked out and bound even though that’s easily worked out from the source data.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

function initTeapot() {
    g_vbo = gl.createBuffer();
    gl.bindBuffer(gl.ARRAY_BUFFER, g_vbo);
    gl.bufferData(gl.ARRAY_BUFFER,
                  teapotPositions.byteLength +
                  teapotNormals.byteLength +
                  teapotTangents.byteLength +
                  teapotBinormals.byteLength +
                  teapotTexCoords.byteLength,
                  gl.STATIC_DRAW);
    g_normalsOffset = teapotPositions.byteLength;
    g_tangentsOffset = g_normalsOffset + teapotNormals.byteLength;
    g_binormalsOffset = g_tangentsOffset + teapotTangents.byteLength;
    g_texCoordsOffset = g_binormalsOffset + teapotBinormals.byteLength;
    gl.bufferSubData(gl.ARRAY_BUFFER, 0, teapotPositions);
    gl.bufferSubData(gl.ARRAY_BUFFER, g_normalsOffset, teapotNormals);
    gl.bufferSubData(gl.ARRAY_BUFFER, g_tangentsOffset, teapotTangents);
    gl.bufferSubData(gl.ARRAY_BUFFER, g_binormalsOffset, teapotBinormals);
    gl.bufferSubData(gl.ARRAY_BUFFER, g_texCoordsOffset, teapotTexCoords);
 
    g_elementVbo = gl.createBuffer();
    gl.bindBuffer(gl.ELEMENT_ARRAY_BUFFER, g_elementVbo);
    gl.bufferData(gl.ELEMENT_ARRAY_BUFFER, teapotIndices, gl.STATIC_DRAW);
    g_numElements = teapotIndices.length;
}

$.glTexture

Textures are a bit more complicated since there are a lot of user settings per texture that can’t be worked out from the source. For this plugin, the user settings for each texture are just moved into a config object. The details of setting up TextureParameters and ImageStoreParameters based on those is worked out in the obvious way. The textures are automatically created and bound after the images have been loaded.

Here is how the teapot bump texture is loaded with the plugin:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

  var bump_texture_config =
  {
    Type:      'TEXTURE_2D',
    ImageURL:  './images/bump.jpg',
    TexParameters: 
    {
      TEXTURE_MIN_FILTER: 'LINEAR',
      TEXTURE_MAG_FILTER: 'LINEAR',
      TEXTURE_WRAP_S:     'REPEAT',
      TEXTURE_WRAP_T:     'REPEAT'
    },
    PixelStoreParameters:
    {
      UNPACK_FLIP_Y_WEBGL: true
    },
  };
  bump_texture         = new $.glTexture( gl, bump_texture_config,         bump_textureLoaded );

Here is how the teapot environment map is loaded with the plugin:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

  var env_texture_config =
  {
    Type: 'TEXTURE_CUBE_MAP',
    ImageURL: 
    [ 
      './images/skybox-posx.jpg',
      './images/skybox-negx.jpg',
      './images/skybox-posy.jpg',
      './images/skybox-negy.jpg',
      './images/skybox-posz.jpg',
      './images/skybox-negz.jpg' 
    ],
    ImageType: 
    [ 
      'TEXTURE_CUBE_MAP_POSITIVE_X',
      'TEXTURE_CUBE_MAP_NEGATIVE_X',
      'TEXTURE_CUBE_MAP_POSITIVE_Y',
      'TEXTURE_CUBE_MAP_NEGATIVE_Y',
      'TEXTURE_CUBE_MAP_POSITIVE_Z',
      'TEXTURE_CUBE_MAP_NEGATIVE_Z'
    ],
    TexParameters: 
    {
      TEXTURE_WRAP_S:     'CLAMP_TO_EDGE',
      TEXTURE_WRAP_T:     'CLAMP_TO_EDGE',
      TEXTURE_MIN_FILTER: 'LINEAR',
      TEXTURE_MAG_FILTER: 'LINEAR'
    },
    PixelStoreParameters:
    {
      UNPACK_FLIP_Y_WEBGL: false
    }
  };
  env_texture          = new $.glTexture( gl, env_texture_config,          env_textureLoaded  );

Binding Attributes

This is were things really start to get nice! Since the attributes and vertex streams are all cached by the $.glModel and the $.glProgram, all we need to do to bind them together is make one call and then pass the model to GL for drawing.

1
2

    bump_reflect_program.BindModel( teapot_model, TeapotBumpReflectAttributeBindings );
    bump_reflect_program.DrawModel();

In order to automatically bind the model to the program (as above) a mapping from the names used in one (stream names in model) to the other (attribute names in shader source) must be provided. It looks like this:

1
2
3
4
5
6
7
8

var TeapotBumpReflectAttributeBindings =
{ 
  Positions: 'g_Position', 
  Texcoords: 'g_TexCoord0', 
  Tangents:  'g_Tangent', 
  Binormals: 'g_Binormal',
  Normals:   'g_Normal'
};

However, one thing I noticed was that very often the names were close, but not exactly the same. I felt it shouldn’t be necessary to specify them when it’s obvious (as in the above example) what should be mapped to what. I wrote a quick utility that uses the Levenshtein Distance between the two pairs of strings to find the best matches and build the above binding object automatically.

It’s used like this in the teapot demo: (The mapping above is created automatically here.)

1

  TeapotBumpReflectAttributeBindings = bump_reflect_program.CreateBestVertexBindings( teapot_model );

Here is how the attributes were bound and the model drawn in the original demo. Note:

• The stream offsets are tracked manually.
• The attribute indices are supplied inline and correspond to the bindings in the program. Very easy to get out of sync if you’re changing around attributes a lot!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

    // Bind and set up vertex streams
    gl.bindBuffer(gl.ARRAY_BUFFER, g_vbo);
    gl.vertexAttribPointer(0, 3, gl.FLOAT, false, 0, 0);
    gl.enableVertexAttribArray(0);
    gl.vertexAttribPointer(1, 3, gl.FLOAT, false, 0, g_texCoordsOffset);
    gl.enableVertexAttribArray(1);
    gl.vertexAttribPointer(2, 3, gl.FLOAT, false, 0, g_tangentsOffset);
    gl.enableVertexAttribArray(2);
    gl.vertexAttribPointer(3, 3, gl.FLOAT, false, 0, g_binormalsOffset);
    gl.enableVertexAttribArray(3);
    gl.vertexAttribPointer(4, 3, gl.FLOAT, false, 0, g_normalsOffset);
    gl.enableVertexAttribArray(4);
    gl.bindBuffer(gl.ELEMENT_ARRAY_BUFFER, g_elementVbo);
    checkGLError();
    gl.drawElements(gl.TRIANGLES, g_numElements, gl.UNSIGNED_SHORT, 0);

Binding Uniforms

Like attributes, uniforms are made much simpler. The type of each uniform is known from the source files (e.g. mat4 or sample2D) so there is really only one correct way to bind it and only one correct type to bind it with. Texture slots are given to textures automatically as they are bound and don’t need to be specified.

Binding the uniforms for the teapot looks like this with the plugins:

1
2
3
4
5
6

    bump_reflect_program.BindUniform( 'world',                 model.elements );
    bump_reflect_program.BindUniform( 'worldInverseTranspose', worldInverseTranspose.elements );
    bump_reflect_program.BindUniform( 'worldViewProj',         mvp.elements );
    bump_reflect_program.BindUniform( 'viewInverse',           viewInverse.elements );
    bump_reflect_program.BindUniform( 'normalSampler',         bump_texture );
    bump_reflect_program.BindUniform( 'envSampler',            env_texture );

Here is how the uniforms were bound in the original demo. Note:

• Separate variables to cache the uniform locations had to be kept. Even though you would always want that to be done.
• The type of the fixed array had to be specified (e.g. Float32Array) even though there is only one likely acceptable type given the attribute type in the source file (e.g. mat4)
• Texture indices are bound manually. Easy to break if you’re changing texture and sampler setups a lot!

1
2
3
4
5
6
7
8
9
10
11

    // Set up uniforms
    gl.uniformMatrix4fv(g_worldLoc, gl.FALSE, new Float32Array(model.elements));
    gl.uniformMatrix4fv(g_worldInverseTransposeLoc, gl.FALSE, new Float32Array(worldInverseTranspose.elements));
    gl.uniformMatrix4fv(g_worldViewProjLoc, gl.FALSE, new Float32Array(mvp.elements));
    gl.uniformMatrix4fv(g_viewInverseLoc, gl.FALSE, new Float32Array(viewInverse.elements));
    gl.activeTexture(gl.TEXTURE0);
    gl.bindTexture(gl.TEXTURE_2D, g_bumpTexture);
    gl.uniform1i(g_normalSamplerLoc, 0);
    gl.activeTexture(gl.TEXTURE1);
    gl.bindTexture(gl.TEXTURE_CUBE_MAP, g_envTexture);
    gl.uniform1i(g_envSamplerLoc, 1);

End

You’re welcome to use the plugins if you like. For me, it was mostly an exercise to get to know WebGL for the first time and to learn a bit more about jQuery and javascipt. There are also some WebGL “frameworks” out there that also do manage this kind of setup for you, but there’s nothing like doing it yourself (at least once) to learn how it’s done.

Mike.

This post started last week as a conversation over beers with a good friend of mine. We wanted to figure out:

• What soft skills are important for game developers. In any position, from intern to CEO. Programmers and artists. Designers and animators. Everyone.
• How could we figure out the relative importance for those skills?
• How could someone use a self-evaluation to gain some insight into skills that are important for them to work on?
• How could we make that self-evaluation a less-random and totally arbitrary process?

After sharing his ideas and practices with me, I decided to make some adjustments and create my own.

Oh and since I was also thinking about how I could make a more interactive post as well, this is the result:

This time we take a look at two articles that we had both read recently and discussed some of our thoughts on them. And by that I mean that we largely ignore them and talk about what we want anyway. :)

Note: Sorry about the audio quality. Matt’s a little blown out in these recordings. We tried something different to make up for last time and we way over-compensated. Next time it’ll be perfect. Either that, or we’ll find a new and even more interesting way to screw it up. ;)

Article #1: Anti-Social Games Defined [gameproducer.net]

(Mike and Matt) Anti-Social Games

Article #2: FarmVille 2? Why Zynga needs to start making sequels, fast [venturebeat.com]

(Mike and Matt) Zynga Sequels

Thanks again for listening!

Mike.

PS: I know that some of you prefer the written posts. And there have been some requests for transcriptions so you can skim these faster. Which I’d be happy to provide if someone wanted to volunteer to write them up for us :) But really, for us these audio posts give the opportunity to speak our minds in a more natural way without the much more self-critical editing of the written word. Of course, we’re not abandoning our written posts – it’s just been fun to do these as well! And if you really don’t like it, I’ll refer you back to the image on the very first post on this blog:

The first #AltDevUnconference was in Burbank, CA and it was great fun. We met new people. We talked. We exchanged ideas. We drank an average of three beers each. (I can tell you that exactly, since the bar tab was included in attendance.)

Nothing ever goes as planned

We did have some problems with the venue. They accidentally double-booked our room! Luckily, we were able to work out something with the management and create a space for ourselves down on the main floor. It was a little bit noisy with the UFC fight going on at the same time (or as it was also referred to, “sweaty man wrestling”) but I think we made the best of the situation and still had a great time. We adapted the plan quickly and eventually settled on some smaller rotating groups that were able to talk and share.

We definitely earned the “un” in “unconference” – But when Rachel Blum and I imagined this event, we really had no idea how it was going to work or what we were doing. (And speaking for myself, I’m still pretty sure I have no idea what I’m doing when it comes to planning something like this – I have a much healthier respect now for the people who put on the big conferences and still get them to run smoothly!)

What went down?

It become clear really quickly that my original plan for some rapid-fire group presentations wasn’t going to work in our new space, so we adapted. For most of the night, we went through rounds of group discussions on various topics. I have been working with my own team at Insomniac on similar exercises, so I cribbed pretty heavily from those. Some examples of the topics we discussed:

• What will games look like in 10 years?
• What’s the difference between art and advertisement? Where do games fit in to that?
• What are you afraid of and how do you use it to drive the creative process?
• What’s the ‘ideal’ user interface for games?
• Gamification: Does it really make everything better?
• Feminism and games: Do you really want to define your audience primarily by their sex?

There were a lot of really great ideas generated. Which led to a ton of really interesting tangent conversations.

Who was there?

We had a pretty good mix of developers from different specialties and experience levels. We probably had more programmers than any other discipline, but that’s probably more to do being the group that Rachel and I interact with most often with, rather than specific to the content of the evening.

Dennis Crow was good enough to share some of his pictures from last night. (I’ll post more as we gather them up.)

The Budget and our Sponsor

The event went way over-budget. Largely due to the fact that we had to rent the space on the main floor on a fight-night. I ended up covering an extra few hundred dollars personally, but what really saved our asses was our sponsor. In retrospect, I can say that it simply would not have been possible without the sponsorship from Visceral Games. Thanks, guys! You really helped to make what could have been a disaster into a good night for everyone.

More?

I’m rushing out to catch my plane to San Francisco for GTC and GDC this week, but I wanted to get this quick update out before I took off. I’d like to gather up thoughts and stories from our attendees and share those with you later though! So stay tuned.

Mike.

One of my personal hobbies is developing random stuff on FPGAs. I find hardware development (as much as FPGA is that) a fun diversion from game development. I’m a strong believer that a huge number of software issues (especially related to concurrency) are well-solved problems in the hardware space and a huge variety of common hardware solutions can be applied to software. Not to mention that a better understanding of what software actually, ultimately does informs good software and data design choices in general.

But a while back I realized the same was true in reverse. While developing some more useless gadgetry, I noticed that I was constantly rebuilding and reloading the ROM when I was just updating a few tweak variables. It occurred to me (obvious in retrospect) that this is exactly the same problem we face every day in game engine development. So why can’t I solve it the same way? But then I didn’t really do anything about it for a long time.

Last year though, something changed. I was sitting on my couch with my iPad, playing with iCircuit (which is an awesome app, BTW – you should totally check it out) and I thought, “It would be really awesome if I could just update some of my variables while I’m lazing around here on the couch instead of walking way over there to my desk.” [Note: One can not over-value general laziness as a motivating factor. My desk was literally 5 feet from the couch.] Plus, you know, it would just be cool.

My first thought was that I could write a custom communication app for the iPad and add some kind of wifi module to the FPGA and get something like this:

But then I realized something:

• Apple makes it obnoxiously difficult to write an app “just for fun” on one of their devices. The hoops you need to jump through with certificates, etc. just to run something on your own device are ridiculous. I’ve written one complete iOS app previously and really, I don’t feel compelled to do it again.

Briefly I considered picking up one of those knock-off Android tablets (this was before the Galaxy came out) for like $150 bucks. That momentarily seemed like a good idea, but then I realized something else:

• More than 99% of the time, my FPGAs are directly hooked up to my PC when I’m working on them. Which is obvious, since I’m always pushing updates to the device.

So, I decided to go down a simpler path. (Well, technically way more complicated, but simpler to implement anyway.)

Which basically exactly mirrors the kind of practice we use in engine development for live editing data from the game tools. So it’s a pretty familiar setup. Here’s the plan:

• On the PC, create an HTTP server which provides a REST(-like) interface to talk the FPGA over USB and can specify values to update. (Registers, memory or whatever you like.)
• Create a web client (i.e. web page) that talks to the local server through the REST interface and can adjust variables as desired.
• Launch web browser on iPad, load up web page on the local server and make adjustments.

HTTP Server

The first thing I needed was for the PC to be able to speak to the FPGA over USB. This was a non-problem. In this case, I’m using a Digilent Nexys2 board and Digilent already provides an API to piggy-back on their USB interface – Adept SDK 2.

Next, I needed to set up an HTTP server and link to the USB communication functions. For a server, I chose to go with mongoose. For three reasons:

1. It’s very simple. Only a single file to build.
2. It’s totally hackable. I can do pretty much whatever I want and I don’t need to figure out a bunch of complex configuration to do something very simple.
3. I was already familiar with it.

I wrote I little project that linked in mongoose, linked in the Adept SDK library, and provided a couple of example REST methods that I could use to test. Here are the functions that I set up:

  mg_set_uri_callback( s_MongooseContext, "/SetDeviceRegister", &VGATestServer::HttpSetDeviceRegister, NULL);
  mg_set_uri_callback( s_MongooseContext, "/GetDeviceRegister", &VGATestServer::HttpGetDeviceRegister, NULL);
  mg_set_uri_callback( s_MongooseContext, "/Ping",              &VGATestServer::HttpPing,              NULL);
  mg_set_uri_callback( s_MongooseContext, "/Shutdown",          &VGATestServer::HttpShutdown,          NULL);
  mg_set_uri_callback( s_MongooseContext, "/Bin/*",             &VGATestServer::HttpBin,               NULL);
  mg_set_uri_callback( s_MongooseContext, "/EnumDevices",       &VGATestServer::HttpEnumDevices,       NULL);
  mg_set_uri_callback( s_MongooseContext, "/OpenDevice",        &VGATestServer::HttpOpenDevice,        NULL);
  mg_set_uri_callback( s_MongooseContext, "/CloseDevice",       &VGATestServer::HttpCloseDevice,       NULL);
  mg_set_uri_callback( s_MongooseContext, "/GetActiveDevice",   &VGATestServer::HttpGetActiveDevice,   NULL);

A few things to note:

• It’s not truly REST since I have to manage a certain amount of state with multiple devices connected. But who cares?
• There’s a Ping and a Shutdown method. Both I find invaluable for debugging purposes. To be able to test that the server is still running from the client page, and to shut it down remotely.
• The SetDeviceRegister and GetDeviceRegister map directly to a register file on the FPGA in a straightforward way. Registers are referenced by index. It’s up to the device to determine what they mean.

Web client

On the client-side, I knew I wanted to make a page that was kind of slick and iPad-like. I had previously seen the Sencha Touch javascript framework and I had been meaning to poke around with that, so this was a good opportunity. I hacked together a page to test the simple functions exposed by the server:

Other things I’m using here:

• jQuery – Initially I had a couple of headaches between Sencha Touch and jQuery. But overall it wasn’t too bad since I wasn’t trying to do anything spectacular here.
• jGrowl – A Growl-like plugin for jQuery. Super-handy for debugging and notifications.
• The control widget there (the boxes represent bits) is using HTML canvas. Something else I wanted to mess around with while I was in there anyway.
• And a really simple jQuery color picker by Lakshan Perera

Color picker:

One cool thing about Safari on the iPad is that I can add any webpage to the Home screen:

…and have it appear like a native app:

…and when viewed this way, the address bar is removed and it does look pretty native. At least enough for my purposes. Note: This is the reason I added the “Refresh” button on the bottom. I wanted to be able to run the app, but without the address bar there was no (obvious?) way to refresh the page.

As an added bonus, since the clients really just reflect the values that are stored on the device (and synchronize to any device changes) that means all clients stay in-sync in real-time. (Well, pretty quick, anyway.) So if I’m also running the web page on the PC, it will show the identical settings and if I change those settings from either client, the other will update immediately. Here’s the page running in Chrome on the PC:

That’s pretty much it.

Client talks to HTTP server. HTTP server talks to FPGA. I can now edit some register values in this sample app, see them updated live on the device and all the changes (even from the device itself) reflected live in the client views. Very handy.

In this test, the actual device isn’t doing much. It really just outputting a VGA signal and not much else. The background color is set to the specified color and there’s a test pattern that uses the bits set in the control. The batteries in my camera are dead or I’d take a picture for you. Maybe I’ll put one up later. (Not much to see though.)

Source code:

• VGATest.zip This is the VHDL source for the Digilent Nexys2. Project file included for Xilinx ISE 12.2
• VGATestServer.zip This is the source for the HTTP server and the client web code (found in the Distro sub-directory) Solution file included for Visual Studio 2008.

In some future posts I think I’ll talk about some of the even cooler fun things that you can do with this kind of setup and perhaps walk through the code in detail. For now, poke around. And have fun.

Mike.

Last week I was able to visit the Wilhelm Busch museum in Hannover, Germany. Something struck me as I walked around and admired the work. It was a catalyst for clarifying some of the ideas I’ve had floating around in my head for quite some time. As Andy (@greenfaery) will attest to, after that moment no one could shut me up about my thoughts on the matter. And now I will subject you to them as well. Somewhat haphazardly to be sure. I’m not trying to convince you. Nor myself. Just trying to get my thoughts down.

Form follows meaning

It may surprise some to find that artistically I don’t subscribe to the idea that “form follows function.” I believe That both form and function follow meaning. This means that foremost, games should have something to say. They should be expressing a belief or idea or feeling (or something else.) This is specifically very different from trying to *elicit* a feeling from the player in some purposeful way. Games, as any great art, should stop the player emotionally or personally and they have to discover how they feel. If we are just trying to get everyone to feel the same way, that’s still function and not meaning. The question to ask is: “What are you trying to say?”

Reflect what you believe in everything you do

Game development itself is the same way. For example (for me), I want an engine to reflect a fundamental optimism and hope about the world and development. I want it to reflect a true belief in the medium of games. This drives my choices on a very practical level. In order to know which techical choices are better, I must know what I believe are the most important elements in a game, and in *our* games in particular. As opposed to games in general, or movies, or other possible uses. That belief should also be reflected in the UI and UX of the tools. Is it hopeful? Does it reflect games as a medium in itself? i.e. How can it be more like a game?

And even in my job as Core Director, it’s the same. What am I trying to say with my work? Everything I do must reflect those beliefs. That I believe in games as a medium. That I fundamentally believe that change is both necessary and good. That I believe that each individual can make a difference. That I believe that the most important thing you can do is help others grow. That I believe in asking myself and others way too many questions. :)

Over-emphasizing the form

I believe that we concern ourselves with the form of games way too much. When we compare games, we discuss genre stereotypes and technical bullet points. When we talk about it as developers, we dicuss game mechanics or code techniques. All have their place. And are certainly valid discussions. But we don’t discuss meaning, or purpose, nearly enough. And worse yet, when we *only* concern ourselves with the form, the result is often empty and superficial.

Games, or our work in general, should invade a private space in the player. It should reach in and grab them and help them learn something about themselves. Tools are ultimately no different in this regard, either. Helping the users of our tools discover not just a better form (more details, polishing up the graphics on Level 3, whatever) but something about themselves in the process is important. The former serves the latter. Those that truly believe that form follows function will find this particular point very difficult to swallow of course.

Meaning requires understanding

In large part our work is not about finding a solution. That is dwarfed by the effort required to truly define the problem. Even in very technical implementations (or perhaps especially so), many reasonable solutions exist and can be applied to some degree. But it’s defining the problem specifically to our needs that changes all the constraints and guides the possible results. As a simple example, if you take our conferences (like GDC, for instance) – in large part we discuss ‘solutions’ meaning that we share a (hopefully) working answer to some problem we encountered. But have you ever noticed just how often those solutions are not applicable to your situation? Because the problem (for you) is different. But we de-emphasize that. In general, our presentations and results share the wrong thing. It’s the journey to finding that solution that was much more important. It’s the discovery of the *actual* problem that needed to be solved that is much more interesting.

Too often we look at problems superfically and try to apply fixed solutions to them. Jamming them in without much thought. In those cases we are not doing the work justice. Interestingly (at least for me), this is at the heart of what we’re calling data-oriented programming. More than anything, it’s about truly understanding what you’re working with and for. @nfalstein and @grumpygamer recently shared their memories of defining a “puzzle dependency chart” format for the old LucasArts games. Which seems to share a lot of similarities to how I view data design. I suspect that’s not a coincidence.

Viewpoints

As background on this topic, I suggest reading The Viewpoints Book by Anne Bogart and Tina Landuau.

I believe that we can extend these viewpoints to speak for the medium of games. Using space and time and voice to reflect our meaning in much the same way as theatre or dance. But in a way that’s uniquely ours. In games space and time and voice are much more flexible. They can be dynamic. Architecture, for example, does not need to be a fixed function as it does in life – we can change it dynamically, in real time. Something which can not truly be done in the same way in any other form. As well, the choices of the player should *change* space and time and voice in a way that’s impossible anywhere else. In the broadest terms, we often try to be too much like other media, film in particular, and forget the awesome potential of games. Thus doing them a great disservice.

Sketch

While I leave most of these thoughts here undeveloped, and I’m wanting to rewrite and rework this post entirely, I think it’s in the spirit of this itself for me not to over-concern myself with the form too much and just get this sketch out there. Plenty of time for revision in the future. Especially because this post is already two days late. ;)

I invite your thoughts and sure, criticisms too.

Mike.

@mike_acton