Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
March 28, 2017
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Can OhMyGame! Democratize Game Development Through The Browser?
Can OhMyGame! Democratize Game Development Through The Browser?
March 17, 2011 | By Simon Parkin

March 17, 2011 | By Simon Parkin
More: Console/PC

[Gamasutra's Simon Parkin speaks to Erlend Grefsrud, co-founder of, just as the site -- a web-based Flash toolkit that allows game designers to borrow art and code with which to create 2D games -- enters Beta testing.]

Strongman Games announced this week the launch of the OhMyGame closed beta. OhMyGame aims to be the most efficient, user-friendly game development toolset for use in a web browser.

The platform will focus heavily on the social aspects of game development, allowing users to share their code, assets and levels with other OhMyGame users.

In this Gamasutra interview, co-founder Erlend Grefsrud discusses OhMyGame's goal of providing game development tools that are accessible to anyone, not just coders.

What's your pitch with

In brief, OhMyGame lets you make games in your browser, share all your code, assets and levels across a social network and output for a number of platforms.

It is a web-based, fully integrated game development suite with heavy emphasis on sharing. It’s all the tools you need to make 2D games, such as a visual code editor, level editor, UI tools, sound tools and testing facilities. The goal is to make sure absolutely every single thing authored in OhMyGame can be reused and shared, to reward experimentation and collaboration.

The overall goal is to make game development – or rather game design – accessible to way more people than is the case today. Our visual programming is not your traditional UML-based spaghettigeddon, nor is it quite as formalistic as Scratch.

Instead, it’s based on a simple cause-effect model. We present a library of logic blocks, divided into causes and effects. Causes perform checks, such as collision testing or distances between objects, which then trigger effects that handle movement, calculations, spawning objects and so on.

Everything you need to make games has been encapsulated in these blocks and we will add more and more over time. You arrange your game logic by dragging and dropping these logic blocks to form behaviors. These behaviors can then be shared or reused across projects, making gameplay code into something really malleable and generalized without oversimplification. The idea is to turn programming into design.

Of course, we’ve got level editing tools that will eventually feature a very novel approach to procedural generation and an integrated synthesizer that handles sound. We’re working on robust UI tools as well, but they’re sidelined in favor of launching a beta with basic functionality.

It isn’t about the browser-native game development environment or the multiplatform export or any of that, it’s really about allowing people to design rather than program games. We want to let anyone make games. Not just engineers or designers who program, but anyone should be able to construct their own game systems.

Mike Acton, engine director at Insomniac, tweeted that he didn’t look for the Citizen Kane of video games, he wants the Kim Kardashian of games: an opportunity for everyone, no matter how talentless, to make games. We also want that: way greater diversity.

It’s pretty obvious to me that no medium or artform can really diversify, both in terms of reaching a broad audience and cultivating a broad range of practitioners, until it has developed a vernacular. Until the instruments of creation are widely available, their application will be transfixed by formalists. In the case of video games, those formalists are coders.

I totally agree that code is the literacy of the 21st century and that programming computers is a vitally important skill, but I also believe that concessions must be made if a broader segment of the population is to learn how to program. We need domain-specific programming languages, like Don Norman argued that we need domain-specific computers. That ultimately means developing programming models that reflect the task at hand rather than the working of the computer performing the task.

We’re trying to do that for games. We’ve only taken baby steps, but I’m designing entire games using OhMyGame and I’m an awful programmer.

Ultimately, we see it as making a camera or a synthesizer – it’s a tool made specifically for the needs of the task at hand. It’s not an engineering environment with a level editor or a level editor with some scripting utilities; it’s a game development environment anyone can use.

Where did the idea for originate?

From a hundred different places, as these things usually do. I started speccing a game development tool back in 2005, when I was still a games journalist, based on a behavior-driven model not entirely dissimilar to the one OhMyGame features. I wanted to integrate that environment with a digital distribution platform where people could sell, trade or give away both their games and the resources used to create them. That never happened, of course, but I kept it in mind.

Our technical lead, Rohan, also had ideas like this from a long time back. He got into programming through game development tools like Multimedia Fusion and later DarkBASIC, and really admired the way these frameworks made game development accessible to a wider audience and also saw them as excellent ways to learn maths and programming. Incidentally, he also thought they were pretty terrible and could be improved vastly.

We met doing a game design course at London Southbank University in 2006, where we found that we were the only people in the course who had any idea of how to code a game. There were 25 people in our year who wanted to make games, but they couldn’t because they didn’t have the slightest idea of how to do it. That opened our eyes to just how hard it is for creative individuals to actually get to the making games bit.

We saw similar things when we participated in Dare to be Digital 2008. Even at that stage, after numerous screening processes and – in some cases – post-grad degrees in game development, people still screwed up basic implementation. They spent ages getting their technology running, or they had communication problems, or they simply couldn’t formalize their ideas. There are too many barriers to entry.

We decided we need to break those down. We had that idea when we started the company, and it was always our overall technology strategy.

What were you doing before working on this project?

I used to be a games journalist and also did some web and graphics design on the side, and wanted to get into games. Turns out writing several game reviews a week was an excellent way to learn how video games work, I would really recommend that trial by fire to aspiring game designers.

This coincided brilliantly with Kalli, our third co-founder, who had just gotten tired of the film and advertising industries and saw games as a much more interesting prospect. We met while relaunching a Norwegian games site in 2004, and moved to London in 2006 to go to university together.

That’s where we met Rohan, were accepted into Dare to be Digital and realized that we made a pretty good team. Rohan spent most of his youth in France, where he made games, movies and music – a bit of a creative powerhouse that eventually ended up loving code.

Once we graduated from London South Bank University, we were accepted into the university’s start-up incubator, the EAS, who has graciously been funding and supporting us for the last 18 months.

How confident are you that there's an audience for the site?

Judging by the activity in the Flash game market as well as the surge of indie developers, I think there’s a huge interest. I stayed in a hostel with a whole bunch of indie developers at GDC this year, and a lot of them regarded themselves as game designers rather than programmers, even when they had computer science degrees. What was really interesting was that they didn’t particularly want to program: they wanted to make games.

They didn’t see programming as the aesthetic of game development; instead they seemed to consider it a necessary evil. Several of them already used Game Maker or Multimedia Fusion, not because they couldn’t program but because they wanted to use tools suited for the task at hand.

I also think OhMyGame is attractive because it outputs to Flash. There’s a huge existing ecosystem around the sales, marketing and distribution of Flash games, meaning it’s easy to get your games in front of an audience. It’s hard to get rich, sure, but it’s hard to get rich anywhere. If you’re a small, dedicated and hungry team of developers, surviving on Flash games is far from impossible.

Some of the major sites do pretty good licensing deals and they commission work – look at Adult Swim, for instance. They do an excellent job commissioning content, paying well and giving developers lots of control. I’m sure they’re not going to be the last Flash portal focused on quality content.

What sorts of games do the tools facilitate?

Any 2D game you can imagine, really. At the moment, and through the early stages of beta, we will focus on arcade-style games emphasizing system-driven gameplay. We haven’t finished the UI tools yet, so RPG-alikes and point’n’clickers will be a bit awkward (but by no means impossible), but we’ve noticed that most developers tend to stick with brawlers, shoot’em-ups and platformers anyway, and our tools certainly facilitate them.

However, we’ve got pretty sophisticated level editing tools that support absolutely enormous maps, so Zelda-style adventure games are a definite possibility. You can make continent-sized maps, and as many of them as you like. In addition, a modern physics engine sits right at the heart of our game object handling, meaning physics-based gameplay is a given.

Once the UI tools are in, we want to focus on network tools that facilitate RPGs and social games. I’m a little bit wary of talking about a certain three-letter abbreviation for online games, but of course we’re considering those as well.

We’re watching Molehill, the new 3D acceleration API for Flash, with immeasurable interest. We think that’s really going to change things, since that means most internet users will suddenly have access to console-quality games in the browser.

Obviously, we’ll support that. At first, we’ll just port our 2D tools to 3D, but being tactical chaps we assumed that Adobe would do something like this, and planned the architecture of the engine so we could expand to 3D if necessary. It just happened a little sooner than we expected.

What are the strengths and weaknesses of the platform?

The strengths are undoubtedly the ease of use and the massive emphasis on sharing. We want our users to at least consider sharing everything. They can share code, graphical assets, levels, sounds, and music – absolutely everything.

The true strength of this is the democratization of game development. We’re not about being biggest, most high-tech, most feature-rich. We’re about lowering the barrier of entry and letting the masses in.

The weakness of the platform is primarily the confused jumble of technologies that make out the web nowadays. We would love to do HTML5 and WebGL, but it’s simply not viable right now. Everyone’s talking about it, sure, but we’re not seeing that market congeal for a long time.

That means we’re stuck with Flash, which has its flaws, but interestingly it’s the most standardized way to display media on the web right now. Standards advocates will likely froth at the mouth when they read this, but Flash is the single most reliable way to ensure that your content displays across platforms the way you intended.

Of course, the ultimate weakness of the system is that we are three guys working on a shoestring budget. We’re going to need all the help we can get, whether it comes from users, from other game developers or from multinationals or investors who take an interest. We’ve got this thing up and working, but where it goes from here, how it expands and develops – that depends as much on circumstance as our efforts.

Do you not think it's better for budding game designers to learn some Action Script than lean on tools?

Sure, if you like coding. But if you like coding, maybe you should do a computer science degree instead, and maybe you shouldn’t call yourself a designer but a coder. Pays better, too.

I would recommend everyone learn how to code. It’s easier than you think, really, since it’s just a few syntactic and semantic rules tightly coupled with mathematics and a model governing structure. It’s just another language, but one that’s built for expressing logic in terms a computer can process. It’s a chore, it’s not intuitive, but it’s not all that difficult until you start getting down to hardware specifics, manually managing memory and so forth.

But will you love coding? If you doubt for a minute that you’ll love coding, I’d suggest avoiding the problem altogether. In fact, if you’re a budding game designer and you’re not coding, then that most likely means you’re not very interested in code. If you’re not very interested in code, you’re most likely not going to love it. If you don’t love it, why would you want to sit up to your ears in code all day, working out the idiosyncrasies of various libraries, APIs, frameworks and compilers?

If you want to code, go get a computer science degree. If you want to make games, leave code to the coders and start actually making games. There are tools available for this purpose and newer, better tools constantly emerge – why not use them and actually build games instead of struggling with code in the hopes of eventually reaching the point where you can program a game?

Where are you up to with the idea thus far?

We have developed our first game internally using the toolset, a shoot’em-up called Heidegger, and we’re using it actively for prototyping. We’re scheduled to start developing our first commissioned game using the tools in the near future, so while they’re not quite beta-ready yet (mostly because the interface is gobbledegook to anyone who didn’t build it, which will definitely be improved for the closed beta), OhMyGame works and it spits out highly playable Flash games.

We’re really just working to wrap it up nicely, hook it up to a cloud solution and chuck it onto a website for general perusal. We hope to start our closed beta very soon.

Have you had much interest from investors?

We came through to the final rounds of Seedcamp in London earlier this year, which we were quite happy about. While we didn’t get any money, we got to meet a lot of people and Strongman Games probably appeared on quite a few radars. There have been interested parties, but we have yet to find a deal that makes everyone happy.

Besides, Strongman Games doesn’t desperately need funding at the moment. We’ve had 18 months worth of funding via London South Bank University, who also host our offices, and we’re most likely going to break even this year. That doesn’t mean we’re not looking for investment, it simply means we’re looking to do it on our terms rather than because we need money to keep the company alive.

Where do you hope to be in 12 months time?

In twelve months, we’d like to have released several games built on OhMyGame, completed our beta program and opened the service to the great unwashed. We’d like to have enough users that OhMyGame in itself is a profitable business – and hopefully notice an ever so slight difference in the way people make games.

OhMyGame should be out of beta and open for business. We have deployed our procedural level generation technology and all the sharing functionality, enabling users to buy, sell, trade or share absolutely everything they make. We would love to export to several platforms, but our emphasis will be on the web tools at the moment.

We hope to have amassed a few thousand regular users, enough to make OhMyGame either a break-even business or a compelling investment opportunity. That’s the business concerns, of course – on a more idealistic note, we’d love to see more games!

Related Jobs

Vicarious Visions / Activision
Vicarious Visions / Activision — Albany, New York, United States

Lighting Artist – Destiny (Environment)
Vicarious Visions / Activision
Vicarious Visions / Activision — Albany, New York, United States

Tools Engineer-Destiny
Magnopus — Los Angeles, California, United States

Unreal Programmer
Insomniac Games
Insomniac Games — Burbank, California, United States

Senior Designer

Loading Comments

loader image