High-level Framework Goals Discussion

[xmclark]

Let's discuss some high level concepts that will help us move forward with development.

Target Audience
As of now, we can easily target 2D games. That might be a good place to keep our focus.

Current Status
We currently can collect simple user input events (arrow keys, mouse) and do simple drawing. We have a concept of a "game object". These are only primitives though.

Resources available:
We have the existing SDL events system which includes an tried-and-tested event queue and allows for custom events.

We also have a handful of other features cooked into SDL like threads, timers, haptic feedback, etc.

Open Questions
What is the developer experience? How much hand-holding should Falcon do? What other assumptions should Falcon make about target games?

With those questions in mind, what should the high level architecture look like?
What paradigms should we adopt? Event/data driven? Object oriented? Functional?

[xmclark]

I like the idea of making a general purpose 2D game framework with a few standard components that are typical for 2D games like full screen menus, in-game overlay menus (esc menu), and a flexible main-game view.

I think we could apply the ideal programming paradigm to each major component of the game framework. Standalone menus seem very declarative. But the main game view seems like a mixture of object oriented and imperative.

There is also going to be a fair amount of state logic in the main game, which would suggest state machine or behavior tree patterns.

Utilizing events seems natural because we have SDL. I'm open to writing our own events system, or piggy-backing SDL.

[technetos]

Writing our own event system would probably let us be far more flexible in what we use it for. As an example use case not directly related to SDL and possible separate discussion about falcon, what kind of network support are we envisioning?

[DannyPeck]

I am on board for making this a 2D game engine. I think that while SDL does provide an event system it is pretty low level and may eventually limit us. I think that we should build our own Event System and SDL events can get pushed into our Event System. This will allow us to still process SDL events but it will also allow us to expand our Event support in a system that we control. It is also a good separation of concerns since the SDL event queue is dedicated to SDL events where custom user events don't really fit in my opinion.

[DannyPeck]

I think that we should aim to provide out of the box solutions for common problems in 2D game development (collision detection, input handling, key bindings, etc). I think that Falcon should follow a Harness architecture where there is a main Falcon Engine and the user defined Game sits within the Engines harness and the engine drives the Game.

[xmclark]

@technetos : networking. This is a good point. I was assuming no network capabilities because SDL offers nothing in this category. Do you have some ideas for networking features?

@DannyPeck : So Falcon would provide a wrapper around SDL input events. I'm trying to wrap my head around how it would do more. Collision detection features would require assumptions about a game world. It might have to have some configuration. Do you think 2D implies platform style games?

[technetos]

@xmclark Well since SDL supplies no support for networking, I think its a good opportunity for falcon to pick up the slack.

[xmclark]

@technetos what kinds of networking capabilities do you think would be valuable? Are you thinking of MMO capabilities? Local networking? Simple http requests?

[xmclark]

I think local networking could be a good start. It means we have to factor serialization and deserialization into the framwork.

[technetos]

The capability to connect 2 instances of falcon over a socket of any kind.

[xmclark]

I think that is fair. I don't think I'm too interested in solving a low-latency event serialization/unserialization problem unless we were to adopt a web sockets library. Simple passing global game state on a fixed interval seems like a manageable task though. It wouldn't be real time, but it could solve a lot of problems. There are other hurdles like consensus that have to be taken into consideration too.

[technetos]

Im not envisioning realtime gameplay over sockets. I just want 2 instances of falcon running on the same lan to have a channel between them with which to send information.

[xmclark]

So a requirement might be we can send global or limited game state over a socket. Seems good enough. May not want to limit that too much though. Leave room for growth.