Congratulations on developing this very fine game! I’m very impressed with your efforts.
I am also very grateful for your generosity in making this open source so people can learn from it. I am considering using the frogatto sources as the engine tech basis for a different 2d scroller game. I will gladly release my sources in keeping with the GPL, but I do plan to maintain copyrights on my game’s concept, art and sound assets. You all are okay with that approach, no?
I have been studying the sources and I have a few questions, and I’m sure I’ll have more as I go along. I apologize if these questions are answered somewhere else and I didn’t manage to find them. (Ed: I also apologize if this is the wrong forum section to ask these questions in!)
Assets. Am I reading things right, that you are generally scaling the art at load time? What is the source format of the art you are working from and how do you get it to look proper on PCs and iPhones (and iPads too?) It looks like you use alpha for some art and transparency for other art? I do see that you compile the art into monolithic images which I image gives you compression benefits. Can you detail your art process a little bit?
Streaming. It looks to me like you do streaming of objects and assets in loading threads. Do you have a system of setting live zones for physics? Do you turn off objects so they stop colliding outside of the active zone or do you size levels so that physics never bogs down?
Your two biggest source files seem to be level.cpp and custom_object.cpp. So these seem to be the crucial bits of game infrastructure, no? I see that most of the game logic and mechanics happens in the WML script which is very cool. It seems like the way things are set up, that a completely new game could be developed where the majority of the changes just occurred in the data/ area, just new assets and scripts. However, I think some of my game mechanic ideas will require changes in the c++. So, I’m considering what the best strategy will be for me to fork my project, but still be able to pick up changes from your ongoing development. Right now I am using mercurial and I have a plug-in that allows me to pull from your repository into a separate branch from my tinker tree. I’m imagining I’ll do as much work in subclasses in new files to avoid colliding with changes you make. Then I’ll be able to pull in changes and apply them where they seem useful or relevant. Any thoughts or suggestions?
Yup, that’s exactly what we’re hoping people will do. Also note, even if you did GPL your content, you would still retain copyright. We retain copyright on the code, and are therefore able to both license it as GPL, and sell it on the iPhone App Store. In any case, you’re free to do whatever you want with your own assets.
There is an incomplete “pretty scaling” algorithm that scales at load time, which we plan on using for the iPad once it’s fixed up. But normally scaling is done at display time by OpenGL. You can see the source format of the art in images/ - they’re PNGs. Those compiled images are for running in compiled mode (–compiled), which is mainly there for iPhone, because it improves performance a whole lot. I’m not an artist, but I think normally the special color for alpha gets used basically all the time, for convenience - the game supports real alpha fine as well. Maybe Jetrel will detail the art process more than that.
There was an implementation of loading levels in separate threads, but I’m fairly certain that at present we don’t multithread anything. We do load on-demand though; when a level is loaded, everything that level needs is loaded then, not at startup (and if a new object is introduced while the level is running, then that gets loaded at that time). And yes, in general objects are only active when they’re within a certain range of the viewable area. And it’s not just collisions, it’s all their processing (which includes Frogatto Formula Language for all the object’s behavior).
I can’t comment too much on that plan, but it sounds possibly reasonable. And yes, all object behavior is handled in FFL (Frogatto Formula Language) within FML (Frogatto Markup Language).
Thank you for your interest! Please find answers to your questions below.
Yes, absolutely! We completely endorse this approach.
On some devices (PC’s, iPad) the art is scaled to double its size, and on other devices (iPhone) it is not scaled up.
Having higher resolution art and then keeping it native on PC/iPad and scaling it down on the iPhone would of course be possible, but would be a huge amount of effort for our artists.
The game engine uses alpha channels for transparency, however when it loads art it converts a certain color (6f6d51) to full alpha. This is simply for the convenience of allowing artists to either use a transparent color or a full alpha channel.
The main game has two types of ‘entities’: tiles and objects. Art for tiles must be done on a tilesheet which is broken up into 16x16 blocks, and then a tilesheet specification written which specifies how tiles are fit together. We also have some scripts which auto-generate tilesheet specifications for our most common tilesheet layouts.
Objects can have their spritesheets fairly arbitrarily laid out, and then the object definition specifies where the animations are on the spritesheet. Entering the FML for where the animations are is a bit of a pain at the moment. We do have a graphical tool I have been working on to do this but it’s fairly rudimentary right now.
The game does support a process for ‘compiling’ art assets into a few texture atlases, for fast loading times. However this is optional – the game can run directly from the non-compiled assets. By default on the computer we do not run in compiled mode. Compiled mode disables the in-game editor and makes the game harder to edit in general. On the iPhone/iPad and other lower performance devices we use compiled mode. Compiled mode can be enabled using the --compiled option.
Objects are ‘active’ or ‘inactive’ based on their position relative to the player. There is certain flexibility in controlling how an object behaves – one can specify custom calculations to determine when an object is inactive, that an object is destroyed when it becomes inactive (useful for transient objects such as particles or projectiles) or that an object is always active, regardless of its position.
In general we try to make it so any reasonable level size is supported, and leave level sizing to gameplay aesthetics rather than performance concerns. Having a very large number of objects in a level can still create performance concerns, of course.
Yes, custom_object is the main class for ‘objects’ in game. Frogatto, breakable blocks, coins, enemies, etc are all examples of objects, so they are used everywhere and very flexible.
level of course represents a level in the game and is the main controlling class while a level is being played.
Yes, absolutely. This is our intention.
This is quite likely. In particular, the Frogatto engine doesn’t have great support for advanced physics right now (things like platforms which change their tilt while you’re standing on them, for instance). Also, many new ideas probably would technically be supported, but require optimizations to run with acceptable performance.
Well, perhaps the best strategy would be,
(1) Make generally useful changes and submit patches to us, hoping we think they are useful and well-written, and include them directly in the engine.
(2) Convince us you’re a good coder and we should make you a developer, so you can make changes to our engine directly.
Failing this, well, going for new subclasses would probably be best.
If you want to get to know us/chat further/etc, I suggest coming to #frogatto on irc.freenode.net to chat.
The game does support a process for 'compiling' art assets into a few texture atlases, for fast loading times.
Also, another huge benefit of "texture atlases" is locality-of-reference.
When the game is blitting stuff to the screen, it's much faster if successive operations all use the same texture.
As Dave noted; this really isn’t so important on computers; modern computers are fast enough to just bull-strength their way through this, and because of how awkward this “compiled” mode is WRT editing, we don’t turn it on on computers. (In order to take into account anything changed, we would have to compile after every change, and compiling is a several-minute process. Because it takes several minutes, we simply don’t do it on computers, and instead only compile before packing up a new release for mobiles.)
But on mobile devices, this is absolutely necessary to get a decent framerate; frogatto runs at a full frame rate (most of the time) on even the oldest-generation iPhones, to say nothing of newer hardware.
[quote author=townbully link=topic=112.msg703#msg703 date=1289047329]
However, I think some of my game mechanic ideas will require changes in the c++.
[/quote]
This is quite likely. In particular, the Frogatto engine doesn’t have great support for advanced physics right now (things like platforms which change their tilt while you’re standing on them, for instance). Also, many new ideas probably would technically be supported, but require optimizations to run with acceptable performance.
Indeed - we’d especially welcome adding stuff like this into frogatto’s core engine. A secondary goal of making frogatto was to produce a general-purpose 2d engine for game creation (Like MUGEN, or GameMaker, or whatever). We haven’t gotten to that stuff not because we don’t want it (we really do), but because we’re more concerned about getting frogatto itself done. I at least have noticed that, of the dozens/hundreds of “game engine” projects out there, many of them:
1] fail to get any publicity without a decent game showcasing them
2] miscalculate their design, making things that theoretically look nice, but in practical use are a mess. Or even outright omit useful or necessary components.
3] have great difficulty keeping momentum and progress on the project
So, I’d strongly reiterate dave’s suggestion about getting in touch with us on Internet Relay Chat. (I’ve linked to the wikipedia article in case you’re unfamiliar with it, as I was before my first involvement in an OSS project.) We’re in #frogatto on irc.freenode.net and we basically do practically all of our discussion of stuff in there.
You would hugely benefit from discussing stuff there, because we can and will dispense whatever help we can to get you going. We likely have ideas about how to implement features you’re interested in, and asking us if the engine can do X is far faster than trying to decipher the code. (and besides, 5-20 brains are always better than 1)
