Back before the release of development tools of Windows Phone 7, my background for my personal game projects was XNA, followed by Silverlight. I took one of my games originally written in XNA and ported it to Silverlight. Well it wasn’t much of a port, it was more of a complete rewrite. At the time I thought there had to be a better way, and so while I was creating my first game for Windows Phone, I started working on a game framework that was oblivious to the rendering technology, hoping that it would be easier to weather any future changes in graphics frameworks. The idea was that you would write straight C# code and a rendering plugin would do the right thing. This was the start of the Frolic Game Framework, and it was a good attempt, but I had a lot to learn, and there were some things that changed under me. Some big things.
The biggest thing that changed under me was the advent of Windows 8, and the fact that we weren’t just dealing with a single phone screen resolution, but any number of resolutions that could be portrait or landscape and could change based on turning the device. I added capabilities for this, but they were bolted on as an afterthought. It was a big architectural change.
Portable Class Libraries (PCLs) have evolved tremendously since I started this effort. They fit so well into the core tenets of my game framework and it makes so much sense that the core functionality of Frolic be available as PCLs and the game itself can be written as a PCL to make it more portable across platforms.
I also did a lot of thinking about animations, and a lot of iterations around this. As I worked on this I thought this might be the killer feature. I made it easy to string animations together, either one after the other or in parallel, so you could create a complex animation for a bunch of related animations, and kick them off all at once. These animations were loosely based on XAML Storyboards, but ones that could be used no matter what the underlying renderer was. I also feel that the animation engine might be useful even if you don’t want to use the rest of the framework so it will be in a separate PCL assembly you can use without pulling in the rest of the framework.
Because of some of these core architectural decisions that shifted under me in the past couple of years, I have decided that the best option is to start over, learning from the past and embracing the needs of the present and the future.
So goodbye to the Frolic Game Framework and welcome the Frolic2D Game Framework. The Frolic2D name is better for web search for and is a clean break from the old code. It also better describes the goals of the framework. Nobody but me (that I know of) was using classic Frolic so I don’t think I’m leaving anyone behind. I will be blogging about the progress of this framework, and the first posts will have to do with animation.
I wanted to spend a moment talking about the Frolic name. Shawn Hargreaves is someone who I respect very highly. He is currently a lead developer on Win2D for Microsoft but previously was a lead developer on XNA, was a game developer on the MotoGP series of games, and created the very popular Allegro Game Framework. Frolic riffs on the Allegro name. If you translate Allegro to German you can get Froehlich, which can be converted to an English Frolic. Frolic is not a derivative or successor to Allegro, but is a kindred spirit, and a tribute to Shawn’s work. Win2D will be the first graphics framework targeted by Frolic2D and the early samples will leverage Win2D.
Some things haven’t changed. Frolic2D is:
- Graphics independent, the games are written as simple C# code and anyone (including me) can make them work on game engine “X”. Hope to make it easier than it was in the past to plug in other rendering engines.
- Focused on reduction of code and increased efficiency through fluent APIs and functionality that is focused on game development.
- High performance whenever possible, but convenience may trump performance in some instances. Ideally the high performance option will still be available if the convenient option isn’t acceptable. (for example, a particle engine will be more efficient if it doesn’t leverage the general purpose and easy to use animation engine).
- Will always be open source and free. I may do paid extensions based on demand but anything I release as free will never become paid later.
- Support for varying resolutions, through automatic scaling but also through support for multiple graphics resources to get the best experience based on the target display.