Collecting Wishlists For A 2d Game Development System

[White Flame]

Hi, I'm a professional software developer, and for quite a while I've been wanting to create my own 2d game development system as a side project. I've played around with things like RPG/adventure makers and various graphics/game engines, but they're either too simplified & incapable, or too low-level requiring you to build everything from scratch given basic drawing primitives.

I have come up with my own large documents of design ideas, but I would very much enjoy the input of others before starting actual implementation. There are some great graphicians here, and some great ideas that seem to be stifled by the difficulty of sitting down with just C/SDL/OpenGL or even basic engines with a blank slate and trying to connect a path to the visualized game. I think something like this could be a great complement to the Pandora, and expand to other (reasonably powerful) platforms.

I would like to realize a system with a free capable version, and a $20 full quality, all bells and whistles included, super-optimized system with nice complementary editors and tools that you have free reign to do whatever you want with the generated output. (The initial versions will be totally free of charge until it's something truly commercial quality and worth the $20)

So, to the actual design of this thing.

This system should support everything from platformers like Cave Story and Metal Slug, to 2d Final Fantasy style games, to R-Type, to Civilization, to RTSes, to puzzle games. The problem is that systems either optimize themselves to 1 style, or make you program it all, which both suck. In mine, you can program from scratch, but different genre-specialized modules would be included to piece together into a game as well. Plus, the source to those modules would be available for modification, and we're not just talking about code modules, but various editors and specifications, declarations, and rules you can change to affect the game as a whole.

The types of stuff I would love to hear from YOU is how you want to be able to express your ideas into an ideal 2d game system. Stuff like:

- How you'd like to define the walkable ground in a sidescroller vs the display graphics
- Ideas for different menu/dialog systems and mixing graphics/text in them
- How to define random enemy placement and movement
- Organizational strategies for linking levels and areas together
- How you'd like to express game events that change over time (like revisiting NPC after key events in RPGs)
- What ideal editors would do for you automatically
- Level design features and special cases
- Your ideal graphical & animation pipeline
- AI capabilities (yes, I am an AI programmer)
- How you'd like to declare the behavior of your character & NPCs in terms of both control & automated behavior
- Problems that you've experienced in other systems where you just couldn't do what you wanted to
- etc

Basically, not getting lost in the technical details but the actual higher level components of creating and specifying the game. Though I don't mind receiving technical ideas, they tend to grow into huge discussions that really don't have much to do with game design so keep that part brief.

Feel free to dump & ramble on about your own ideas. In the goal of keeping this thread sane, don't bother dissecting other people's replies unless you would like added features on top of theirs!

Obviously, I'm sure once the initial version gets released that tons of more ideas will surface, but I'd like to start with at least a framework that is open to future inclusion of stuff listed here.

Simple practical ideas and pie-in-the-sky "if only!" features are equally welcomed.

 

[cb88]

Do you mean more like a Free Game Player / Commercial Dev environment split?

I know you mentioned the "super optimised pay version" ... just wondering

personally I would prefer an open source engine since development always has a chance of moving foward... perhaps a license similar to the mozilla license (requires a rebrand for forks) or a no fork license?

A physics engine is a must....
Turret defense games

perhaps you could integrate with a 3D toolkit to get some neat effects like with clutter or qtopia?

how about writing the development environment in FLTK? its really portable and lightweight not to mention the only GUI toolkit that i have made any sence of to date

well thats my .02 .... waiting on a gentoo install atm

 

[White Flame]

Do you mean more like a Free Game Player / Commercial Dev environment split?

No, free dev environment / commercial super dev environment, both which are capable of generating playable games.

QUOTE
personally I would prefer an open source engine since development always has a chance of moving foward... perhaps a license similar to the mozilla license (requires a rebrand for forks) or a no fork license?

The genre components and libraries that sit on top of the engine will definitely be open sourced. Also, the engine source code will be generated from Lisp DSLs and a bunch of "interesting" custom code tools that won't be readily picked up by most programmers anyway. (and might be commercially owned)

QUOTE
A physics engine is a must....

Very true. And 2d physics engines are very easy.

QUOTE
perhaps you could integrate with a 3D toolkit to get some neat effects like with clutter or qtopia?

Yes, I'd like for it at least to be hardware accelerated using 3d hardware, but I'd like everything done in this to require no 3d modeling for ease of content creation. This should mean that there'd be effectively unlimited parallax planes, sprites and transparency available, and stuff like the floor in Street Fighter 2 and Mode7 effects should be dirt simple.

QUOTE
how about writing the development environment in FLTK? its really portable and lightweight

I'm almost done hooking one of my AI environments to wxWidgets. The dev environment will most likely be PC-based and assume the possibility of any heavyweight feature when applicable, but we'll see what the Pandora is capable of. Remember the adage about premature optimization, and that the dev environment should focus more on functionality than speed.

 

[dekutree64]

First, let me say that the only easy game maker I've used is RPG Maker 95. I'm a professional DS programmer now though, and have worked on a bunch of games of different types, written a lot of code that interacts with scripting, and done some scripting myself.

So without further ado, some thoughts on an intuitive but powerful game maker...


Collision:
I actually prefer collision/graphics to be directly linked for most 2D games. Just tag each tile with a collision type, and all maps you build automatically have collision. Bare minimum is solid/non-solid, but directional is nice to have (e.g. platforms you can jump up through), and slopes.
Maybe an optional "collision override" layer to tweak specific areas where the automatic collision isn't what you want.


Dialog:
I'd just go with a simple text box, with optional portrait filename, and a checkbox for top or bottom of the screen. For branching dialog, a box that can take up to maybe 10 options, each with a string and an event to run if it is selected.


Enemy placement:
Enemies, NPCs, treasure boxes, pickups, etc. can generally all just be generic entities with some behavior options. A couple other entity types that can be handy are trigger boxes that call an event when stepped in, and boxes for constraining random wandering. For wander boxes, have characters reference them by an ID value rather than selecting a specific box. That way, multiple boxes can have the same ID to create more complex shapes to wander in.

It's very useful to be able to make groups of entities rather than all independent, even if just to show/hide groups while working so the map isn't too cluttered. But it's also handy to spawn lots of things at once, and simplifies the problem of what to do if you want multiple entities on one tile.


Linking levels:
Simple heirarchy, like RPG95. Maps can have child maps so you can expand/collapse groups in the window, but there's no real link aside from that. Allow duplicate map names.


Change over time:
Boolean switches, and integer variables. Just global things that you can name, and use commands to modify however you like (set/toggle for bools, set/add/subtract for integers). Need complex conditionals for when to execute events. RPG95 was a huge pain if you wanted to check 2 switches.


Character behavior:
For a platformer, you really need to be able to code this yourself, in C or something. I haven't used Lua, but it may be a good option. There's a chance you could make a reasonable generic system with a ton of variables to tweak for velocity/acceleration/jump velocity/etc, but that deserves a separate discussion.

For top-down games, just select from 4-directional tile-based, 8-directional tile-based, or 8-directional with floating point positions/speeds.

For scripted path following, define paths as a string of nodes with lines drawn between them. Make it optional to snap nodes to the center of tiles, or be free positioned for the unconstrained movement style.
For more advanced, you could add A* pathfinding, with networks of nodes that can have multiple links. But that can get complicated.


Weaknesses in other systems:
RPG95 couldn't have entities larger than one tile. Giant sprites are cool. Collision can make this more difficult, since you'd need to be able to define a collision box and hotspot, but even just non-colliding sprites would be nice.

Need (mostly) infinite layers. RPG95 only has one BG layer. I think RPG2000 had two, but why not let you make as many as the computer can deal with? Maybe specify a depth value for every layer and sprite, so you can control things accurately. Maybe allow turning on and off collision with any map layer, to make overpasses easy (use triggers to switch collision on and off as you walk around).

 

[White Flame]

Collision: Yeah, that sounds about right. Either tiles, freely-positioned objects, or large singular background objects with intrinsic default collisions, yet per-instance overridable collision behavior for stuff like hidden rooms, walk-through-walls special items/powers, and differentiating where bullets and people can go.

Dialog: I do want more than just the simple case supported. Internationalization of course is one big issue here, as is putting predicates on options depending on the game state. In general, I understand that sometimes in commercial development you pick something easy to implement and design everything around that; I want to go for the ideal and see what's implementable from that. I'm putting together a small list of existing games with "nice to have" menu features, can you think of any such games that stand out?

Change over time: Are there any tools you've used to track such things, as opposed to just putting manual tests everywhere and hoping playtesting will catch any inconsistencies?

Character behavior: I think there are a few common classes of behavior that can be done, plus special moves or environment-based reactions added on top. Even if each is written in a programming language instead of just configuration, having those abstractions would be very handy to have.

Maybe specify a depth value for every layer and sprite, so you can control things accurately. Maybe allow turning on and off collision with any map layer, to make overpasses easy (use triggers to switch collision on and off as you walk around).
See, this is some of the stuff I really want to get away from: The user manually fiddling bits in order to simulate the effect, instead stating the effect directly. Depth would ideally be defined in groups with infront/behind relations and walkable connections between them. Instead of adding triggers and flipping collision bits for overpasses, there should be connected layers of the level that contain independent information instead of limiting the level to a single screen of global collision info. Then let the machine figure out how to represent it with flags and numeric depths.

Just trying to break out into an open-minded "game definition" standpoint instead of defining the game from technical limits and basic bits. After the ideas for functionality and options are defined, creating a number of easy UIs and configs for different subsets of them should make it very easy to work with instead of facing a wall of super-general stuff (even if that's what it is underneath).

The major goals are for the user to easily:

• Tell a story
• Describe the basic mechanics of the world
• Keep design documentation and implementation in sync

 

[SiegfriedCroes]

This sounds great! You do mean a game engine like gamemaker or something, right? (one with no/less scripting and more clicking together the game)? I like gamemaker because you can make any game with it you can imagine, but ofcourse you need to program a lot yourself if you want for example a 2D platform game. It would be cool if you could choose what kind of game you want to make (RPG, 2D platform, RTS,...) and then you get all the options you need for that game. in a 2D platform you get settings for gravity and collision and in an RPG you get a customisable inventory system,...

I'm glad someone is wanting to make something like this, for years I have been interested in Game Design and I tried a lot with different game engines, some of them were nice, others were too complex. I became interested in the Pandora because of homebrew for the DS, I wanted to have a handheld device were I could make my own games for, but because I'm not a programmer (although I am learning C++, I'm more of a graphics artist), I forgot about it, but with this, I could really do some cool things and focus on the visual quality without the need of all SDL/C/OpenGL knowledge. Thanks for wanting to make this engine, I will be posting some ideas later!

 

[Squidge]

Don't forget the 2D engine built by Skeezix - maybe you can get some ideas and stuff from there?

http://www.google.co.uk/search?q=skeezix+zot

 

[hessiess]

Resolution independent: the game will run the same regardless of the resolution it is rendered at, or the aspect rasio of the screen. scale graphics on the fly to the screen res, and letterbox the output if nesoserry.

 

[Eniko]

Don't really have much to add besides that if this does make it out there's a few simple games I might make using it that I would never have the time to code myself from scratch.

Also +1 on resolution independent. Right now my MMO client still misbehaves in fullscreen mode because I can't be bothered yet coding letterboxing for both widescreen and normal PC monitors using the Pandora 800x480 resolution.

 

[frozenflame108]

It would be neat if it was like Adventure Game Studio except less genre-specific. You could make a drop-down box interaction editor for different objects and also have an area to write code for more advanced things.

To define walkable areas/collision points you could import another bitmap (same resolution) with certain colors representing the points.

Some basic 3d model support would be nice for Castlevania SOTN-like effects.

Also, might be neat if you made a version to run on the pandora - since it has enough input methods to make development easy (keyboard, touchscreen).

Sounds good and I'm very excited to use the development system.

 

[Prometheus]

Ooh, I would love this - it's something I'd gladly purchase if it works well. (I am not of a coding mind, as some say. But I sometimes have ideas that I would like to try to realise.)

To define walkable areas/collision points you could import another bitmap (same resolution) with certain colors representing the points.

Whilst I have little to add that hasn't been said already, I'd like to add a "+1" to this. This sort of reminds me of the way a person had to deal with setting solid and non-solid objects for custom tilesets in Jazz Jackrabbit 2's level editor; You would take one image with the tileset for the level, and another of the same tileset, and colour plain black where things should be solid, and paint the background colour over things that shouldn't be solid.

 

[kagato]

I'd be interested in an engine that was object-oriented and event driven.
I don't necessarily mean from a programming language point of view as such, but that behaviour is defined for each game object rather than in a central script. Making objects event driven would simplify end-user development and allow complex behaviours to be built up easily.

Some game engines to take ideas from:

• ZZT (don't mind the ASCII graphics)
• OmniLudiCon - simple & small, but surprisingly flexible given its basic toolset.

 

[Pseudonym]

hmm... 2d sidescroller...

how about using a simple rendering status bar that could be configured using possibilities like time, a map, etc. with customizable graphics...

...and how about a way that more adept users can program their own parts...

and at least 3 variable scrolling backgrounds.

EDIT: disregard the non-technicalness and demanding-ness of my post.

 

[White Flame]

I'd be interested in an engine that was object-oriented and event driven.

To a point that's useful, but there are many, many issues that don't neatly fall into that sort of model. Things like being able to state "When it's night time, these differences are in effect", or even more complex things that aren't predicated on just a single test, or have various exceptions to the normal behavior that you add in later. This is where declarative style and rules come in very, very handy. It's simply impossible to do just the "building blocks" approach and get the "blocks" exactly right the first time without having to tear everything apart again. I've done OO for over 15 years and there are some things that it simply does not do well, especially with emergent design. :wacko:

I do agree that event/object modeling does work great for simple behavior, but that shouldn't be the ONLY way to express things to an engine. I'll take a look at the engines you posted, thanks for the links.


Re: Resolution independence

This is a good one, and I haven't tackled it yet, actually. :unsure: Let me list out some possibilities and see if I have them all covered:

• None - Pixel-for-pixel display of images, larger screens will see more of the play area, but it'll be sharp.
• Aspect ratio - like None, but leave black bars to enforce the aspect. I don't see this as being too useful for 2d games, though. Constrained + pre-scale would probably be the effect you'd want.
• Constrained - Specify how many pixels in either or both of the x/y directions that are visible, scale to fit to the screen
• Post-scaling - For a constrained 320x200 game, it could draw on a 320x200 plane and stretch that onto the screen (more consistent look, pixel-based positioning)...
• Pre-scaling - ... or else draw the stretched sprites directly on the hires display (sharper when scaling down, floating-point positions are more precise).

As for how any scaling is done, I think the option to do smoothing, TV scanlines, whether to only do integer scaling (ie, 320x200 on a 800x480 screen would do exactly 2x scaling), and the ability to disable zooming at all, should be left up to the user, with the game developer just giving defaults.

Again, a number of choices, but 1) they should be easy to fiddle with and see in real-time what their effect is, and 2) it would really suck to need an option that the engine doesn't support.


Pseudonym: Good call with the status bar; I had just been thinking along the lines of throwing independent display items on the screen for status stuff, but the resolution independence really would want something like that. The others have already been incorporated if you read through the thread.


Good suggestions, keep them coming. Especially with features you like/dislike/are missing from other gamedev systems, or examples of game features that should definitely be supported (keeping in mind the human workload for generating the content). And non-technicalness is just as important as the technical bits!

 

[SiegfriedCroes]

Whilst I have little to add that hasn't been said already, I'd like to add a "+1" to this. This sort of reminds me of the way a person had to deal with setting solid and non-solid objects for custom tilesets in Jazz Jackrabbit 2's level editor; You would take one image with the tileset for the level, and another of the same tileset, and colour plain black where things should be solid, and paint the background colour over things that shouldn't be solid.

I used to make my own tiles sets for Jazz 2 too I liked the way of using a mask for the collision, as you said. Also the way you had 8 different layers to work on ( I thought there were 3 foreground, Layer 4 was the layer you would walk on, and then another 4 layers for the background). You could then choose what each layer had to do, so if you want to make a level were you are on a train, you can let them scroll automatically with different speed for each layer (the last being the slowest, of course). Or you can let them scroll with the player. That would be cool to have, although I would never need 8 layers, you could start with just 3 (foreground, "playerground" and background) and then add to them later, maybe even an option how much layers you want, with 8 being the maximum.

 

[fusion_power]

None - Pixel-for-pixel display of images, larger screens will see more of the play area, but it'll be sharp.

I like this option. So onto 4:3 screen we have the same sharpess like onto the widescreen display and we see more onto widescreen. So a 320x240 game for GP2X could be look like a 400x240 game onto the Pandora (Pixel Doubling for the same Pixel Dense like onto the GP2X of course)

 

[White Flame]

I like this option. So onto 4:3 screen we have the same sharpess like onto the widescreen display and we see more onto widescreen. So a 320x240 game for GP2X could be look like a 400x240 game onto the Pandora (Pixel Doubling for the same Pixel Dense like onto the GP2X of course)

Actually, no. With that "None" option as described, it'd be a 800x480 game with tons more visible than on the GP2X. The "Constrained" option with y=240 would do what you want, allowing it to go widescreen without changing the height.

I'm not exactly sure how to handle DPI. I'm of the opinion that how much of the playfield is onscreen should based on the game design. There are displays with a whole range of densities; it's not like there are just 1x and 2x pixel size devices.

 

[Ethan]

I can give you a good example for a professional 3d game engine, which is REALLY user friendly:
take a look at the trial version of unity3d (www.unity3d.com), if you have a mac (win version istn available yet)

you can build the whole game in one mighty editor (well, except the graphical content), and just drag and drop scripts and items and stuff.
if you want to script some behaviour, you create a script (in the editor!) and just script ahead. then you put this script (drag and drop) on the gameobject
in the editor, you want to give behaviour to - and done! these scripts can also communicate with each other - its just simple and clever. (internally they are handled as derived classes)
i made a similar system in c++ for irrlicht, to just derive all behaviour code from one interface to keep up communication and modularization, so this system combined with a good editor is half the rent imo.


the company i work for and me were using this engine (unity) to create our first full-price game. we only needed two programmers (one was me) for the whole game.

 

[echisketch]

I can give you a good example for a professional 3d game engine, which is REALLY user friendly:
take a look at the trial version of unity3d (www.unity3d.com), if you have a mac (win version istn available yet)

you can build the whole game in one mighty editor (well, except the graphical content), and just drag and drop scripts and items and stuff.
if you want to script some behaviour, you create a script (in the editor!) and just script ahead. then you put this script (drag and drop) on the gameobject
in the editor, you want to give behaviour to - and done! these scripts can also communicate with each other - its just simple and clever. (internally they are handled as derived classes)
i made a similar system in c++ for irrlicht, to just derive all behaviour code from one interface to keep up communication and modularization, so this system combined with a good editor is half the rent imo.


the company i work for and me were using this engine (unity) to create our first full-price game. we only needed two programmers (one was me) for the whole game.



Wow wow wow - look at the web demos, streaming graphics with great optimization and texture resolution (on a crap computer mind you).
Unity has a highly optimized graphics pipeline for both DirectX and OpenGL

So it can run on an opengl base, but no word on a linux port - and from the sounds of it they either a) never going to make one or B) not for a long long time.

Boggles my mind that they chose OSX as the primary platform though.

 

[CyruzDraxs]

Boggles my mind that they chose OSX as the primary platform though.

If I recall correctly, the starting team consisted mainly of ex-Quicktime web plugin devs. That would explain why they made a web plugin and why they started on OSX. There has also been a large following of graphics artists on Macs, so I think they were trying to target it at graphics artists and hoping to skip the programmer side of things. It seems like a rather impressive engine, but I don't think it will be very successful until they open it up a bit more for more complex uses and fix some of the bugs. It's just too simple of an engine for anyone but indie devs to seriously consider using it.