Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases
October 31, 2014
PR Newswire
View All
View All     Submit Event





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


 
Why I Made a Game Engine
by Zac Zidik on 07/25/14 07:48:00 am   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

Here are some reasons I created an HTML5 game engine called FLAG . I have given several presentations about it lately. Many in the audience seem disappointed that it there is no button to push that spits out a completed game. Sorry to disappoint but, even with a game engine, programming and a great deal of effort is still required to make games!

FLAG was originally developed with two main goals in mind. The first goal was to create a system that contain reusable objects, process and code for creating educational games. Prior to FLAG’s conception, each game that ETS (Education Technology Services) and the EGC (Educational Gaming Commons) was producing was essentially a one off. When a new game project came along, we always had to start from scratch. FLAG established a formal structure and process that provides a big head start on any new project, which ultimately shortens development time.

The second goal was to create an HTML5 game engine. The most common development environment for web based games, at the time of FLAG’s conception, was Flash. However, Flash had several inherit problems that prevented it from being an ideal option going forward. The first problem was that it required a plug-in that was not being supported by emerging mobile devices. The second problem was that Flash did not meet our accessibility requirements. It was these problems that encouraged us to be early adopters and to experiment with some of the new features of HTML5. Judging by the amount of HTML5 game engines that have emerged over the past few years, of which there are many, and the fact that large well establish game engine companies like Unreal and Unity are now promising native HTML5 support in future releases of their engines, we definitely made the right decision in our choice of technology.

FLAG was designed to be software that ETS and the EGC could use to give structure and process to the games being produced here. FLAG was never meant to be a commercial product instead, it was always intended to be open source, which it continues to be. However, open source can mean a lot of things as far as support goes. All of the code for the FLAG Game Engine is available on github, a popular code-sharing repository. Documentation for the code along with some tutorials and working examples can be found on the FLAG website.

A foundation of basic programming, experience with JavaScript, HTML and CSS are prerequisites for being able to use FLAG. Additional skills, such as game design, UI and UX design, graphic design, animation and sound editing may be required depending on the desired outcome.

Educational gaming continues to gain traction everyday. Technology to produce games continues to become more available and more affordable. With the advent of mobile devices, people carry around, what is essentially a gaming console, in their pockets everyday. Universities like MIT, NYU, CMU, USC and the University of Wisconsin all have well know experts and programs that work in the educational gaming space. Educational games are being produced not only by ETS and the EGC but also by many other individual colleges here at Penn State. Due to our small staff, we are unable to accommodate every request to produce full-fledged games but we do always make time to consult with any faculty or students that might be interested in the topic.

Game design and development, when done well, is an extremely intensive process. In addition to containing many forms of media including programming, graphics, UI and UX design, animation, video and sound, educational games must also contain instructional content. In commercial game production studios, you would have teams of people dedicated to each one of these facets. In ETS and the ECG, we of course, do not have nearly that volume of resources. That is what makes having an established process and system, like FLAG, so helpful.

A typical game project, for us, begins with consultations that would include an instructor and or an instructional designer, the EGC’s project manager and the developer. The goal of the initial meetings is to determine what the learning objectives are for the project. Once that is determined, we begin to discuss possible metrics we can use to assess the players. The metrics must be tangible and quantifiable numbers that relate back to the learning objective. With out them, it would be hard to justify the viability of the game project going forward.

Games come in a variety of size and complexity so there is no hard-set timeline for producing one. A typical design, development and deployment cycle lasts somewhere between 3 months to a year.

The most important collaboration between instructor and developer happens in the initial meetings. Clearly defined learning objectives with metrics and methods of measuring players’ progress are the most important elements in an educational game. This is what the game designer and developer need before coming up with a presentation method.

Once game development begins, student play testing ideally drives iteration. We prefer to get our design in front of the target audience early and often to insure we are on the right track. We take that feedback back to the instructor and refine the design until we all feel it is providing the desired outcomes.

Both instructors and instructional designers who have been involved with FLAG based game projects have been pleased with the results. Proof of their satisfaction can be found in presentations they have given at conferences and in the fact they the games continue to be used in several concurrent semesters. In addition, we continue to meet with stakeholders to discuss the updating and enhancing of their games.

Students also seem pleased with the games. The first game built with the FLAG, Econ U, has been used for 5 semesters. During that time, 3,700 unique students have participated in the game. The most striking statistic is that 3,700 students played the game over 10,000 times! This means that students are not just playing once but multiple times.

In addition to replays, there is also evidence of student satisfaction in survey and social media forms. Several social media discussions have emerged during game play sessions. These discussions included everything from methods of strategy to boasts of achievement.

To date, FLAG has been used to develop two games. The first game is called Econ U, which is a city builder style game where players must use foundational economic concepts to build and grow a university. You can find more information on Econ U here:
play.gaming.psu.edu/econu.shtml

The second game developed with FLAG is called Time and Patients and is a management game where players must turn a struggling health clinic into a profitable business. You can find more information on Time and Patients here:play.gaming.psu.edu/time_and_patients.shtml

Currently, there is no way of tracking usage of FLAG. Again, it was never intended to be a commercial product. The code is open source and there is no requirement to report usage. I have been and I am happy to continue to respond to any technical support questions that I receive via email or through other forms of social media that have been set up for FLAG including a Twitter, Facebook and Game Sprout.

I have been a multimedia developer for 15 years. My skill set includes programming, graphic design, UI and UX design, 3D modeling, animation, video and audio production. I have also been a gamer my whole life. Games are perfect culmination of the primary hobby of my youth and the skill set of current profession.

I was never a very good student in school however I am a very good self-learner. I like designing games for people like me in mind. Educational games can provide things that book learning or classroom instruction can’t including an environment for experimentation, the opportunity to use and formulate abstract thought and the insurance that it is ok to fail and try again.

I was most excited about creating my own game engine because I wanted to know everything that was going on under the hood. Having used many different types of software during my career, including several different game development platforms, I know that with those platforms comes both a learning curve and baggage. By developing my own platform I was able to remove the prescribed methods and baggage that may not have fit my needs, or the needs of ETS and the EGC, in our quest to develop quality educational games.

More information on FLAG can be found at:
www.flagamengine.com


Related Jobs

Activision Publishing
Activision Publishing — Santa Monica, California, United States
[10.31.14]

Tools Programmer-Central Team
Amazon
Amazon — Seattle, Washington, United States
[10.30.14]

Sr. Software Development Engineer - Game Publishing
Intel
Intel — Folsom, California, United States
[10.30.14]

Senior Graphics Software Engineer
Pocket Gems
Pocket Gems — San Francisco, California, United States
[10.30.14]

Software Engineer - Mobile, Backend & Tools






Comments


Jeremy Alessi
profile image
This is really cool!

Maciej Sawitus
profile image
Nice!

And I totally understand that desire to create your own game engine. It's fun and it's great way to learn things. And sometimes, even though there's high quality engines available, it's hard to find one that matches your requirements well enough.

Zac Zidik
profile image
I agree with you guys. Templatizing games is a bad thing in general. When I give presentations about my engine, people are always surprise that it still takes programming knowledge (among many other skills) to make games. Unfortunately, the easier an engine is to make games with, the closer it gets to producing games that all look and behave the same because the people using it never acquired the knowledge of what makes games work in the first place.

Jeremy Alessi
profile image
I don't think all Unity games look the same by a long shot. But, I can't use my iPad to make a Unity game. That's what's neat about the Pole editor. Also, HTML 5 is just really useful. I have a project up right now that still requires the Unity plugin but it would be much better without it.

I wouldn't look at Unity as competition. It's a necessary parallel development tool. What would be really nice is some interoperability so I could load a Unity2D scene into Pole.

Jane Castle
profile image
"For me Unity and similar solutions makes programmers redundant ( which isn't something I like ;) )."

That is until Unity doesn't give you the performance your game requires and\or does not support a feature
needed by your game.

Zac Zidik
profile image
Good point! All the more reason to really know how things work.

Jeremy Alessi
profile image
"For me Unity and similar solutions makes programmers redundant ( which isn't something I like ;) )."

It's a bit off topic but I'd be weary of holding a mindset like this. I'm sure the horse and buggy guys felt the same way about Ford. That said, there's still lots to be done for programmers with Unity (the Asset Store is a great source of revenue for a good programmer) or any other tool. It's just that Unity's barrier is more of a ramp than a wall.

Zac, again it looks like you did a great job on FLAG. I would see how you can align with Unity and other tools (much like Unity aligned with Adobe on Flash a few years back). A way to HTML5-ify my pre-existing stuff (especially running in a mobile browser) would be clutch. Eventually, I'm sure we'll ditch the dedicated editors as well.

Kevin Fishburne
profile image
I've never used a 3rd party engine for anything serious, but always coded from scratch or reused bits and pieces from my earlier works to accelerate development. That being said, I think the availability and accessibility of modern game engines is fantastic for AAA studios and indies alike, as it allows more time to be spent on the "guts" of a game (gameplay mechanics, play control, story, etc.) and less on tediously reinventing the wheel of things like parsing 3D model files, building display lists, sorting items for Z depth, etc.

Now that THAT's out of the way, my fear in examining the current state of the industry is that we are heading not so much for another bursting bubble but a market so saturated with mediocre and sub-par games facilitated by the use of these engines that the price point of the average game will become near zero and hand-crafted gems will be even more difficult for the market to discover. I argue that the industry won't crash again simply because the market has shown that it does want to play these games, just not at what we as developers would consider a reasonable price point.

As it stands most employees at AAA studios make a modest living but are nevertheless shuffled around like a deck of cards and worked to the bone during crunch. Recent surveys have pointed to indie devs largely making earnings below the US poverty level. I think as the number of available games and the rate of release continue to increase so will the sale price and dev salary continue to decrease. This will in turn encourage studios to further reduce their overhead by overworking employees and using 3rd party engines. Wash, rinse, repeat, and at some point no one in their right mind will be willing to work in the industry anymore, perhaps other than those in underdeveloped nations whose workforce will do anything for a paycheck. I sincerely hope this is not our future, but that's what the writing on the wall reads like to me right now.

Adam Bialogonski
profile image
I worked with few people who changed the job ( even industry in some cases ) only because the company decided not to invest any more money and resources into developing own tech, but switch to the thirdparty solution. It works both ways. I am not standing against 3rd party engines because not every game creator is a programmer. There are plenty of specialities who do work on games but not necessarily do program. Look at "The Room". Game made using Unity only by artists and designers as far as I know. And still they managed to pull good and very atmospheric puzzle game out to the market.

Not to be so much offtopic, I see lot of good job done on FLAG. One thing which is very often ignored, especially during earlu development stage, are tools. From what I see, FLAG provides some helper tools ( like POLE ). Couple of years ago I worked on the tech for mobiles devices ( Unity wasn't such a big tool yet, and there was no goor "ready-made" solution in the area of 3D game development ). Since there weren't many developers involved ( only me and later a contractor we hired ), we needed make a decision about tools. So it was either spending extra time and developing own tools, or adapt something already existing to meet our needs. We decided to adapt Blender to be our scene editor and resources exporter ( including packaging etc. it was actually running whole content processing pipeline in the end ). Later we even implemented scripts to build collider meshes and partition the scene offline to be easier chewable by the scenegraph.

I mention it to point that tools are equally important to the rest of the engine. Heck, tools are part of engine in some way! When I opened FLAG website, tools were one of the first things I started to look for ;) Another thing was a product. Tech doesn't have much purpose without product. FLAG has all of it. Nice done.

Thirdparty engines aren't bad in general. They allow to focus on the actual game, not on the "guts" of the game. And this is good considering dev teams being short on resources and time during development. The problem I see is rather being blinded and believing that the thirdparty engine is a cure for every disease of the world. Very often it turns off thinking, makes developers rely to much on what it provides and when things go wrong suddenly nobody knows how to fix it. Then, instead of speeding up the whole development process, it produces delays at the very end when it comes to optimising and bugfixing. That's why I like when tech forces developer to do at least a little bit of technical thinking from time to time ;)


none
 
Comment: