Road to 1.0

[icefoxen]

For the purposes of fostering discussion.

When do we want to consider this 1.0?

Also, I'm intending to spend most of my time working on non-ggez things for 2018, so if there's features people seriously want added (mobile support, etc) I'm probably not going to be able to make them happen in the near future. (One thing I do want to concentrate on is wasm support, but I'm hoping to do that by getting more into gfx-rs and various wasm tools.)

I'll still fix bugs and merge PR's and stuff, but I need to take a break from pushing things ahead. ...on the other hand that's more or less what I did for half of 2017, so.

[Manghi]

Well since no one replied yet I though I would chime in.

• Resource management
• Physics/collision engine
• Particle system
• ECS
• Scripting support
• Controller support (I know we have some already, not sure if it still needs work)
• Networking support
• Screen Management/UI

The latter two are something we (myself and @AaronM04 ) are prioritizing so we have to roll our own. My goal is that anything we end up creating could be used by ggez, but to be frank I can't make any promises.

The other items are things I know game engines tend to support. Up to team ggez if they fall under 1.0, or if they would be slated towards a future release. Since you're querying on an event-oriented release (what last things do we want before 1.0), I'll play devils advocate.

Do you know when you all wanted 1.0 to be released?

[icefoxen]

Good to see your list! These are all things that are useful/necessary for a game but I also feel like are a layer above what I want to aim for with ggez. I sort of want ggez to remain the low-level and simple-as-possible library so people can start with it and tinker with it fairly easily... not having to understand ECS concepts or a physics system or such. There's also room for more than one solution to be built atop it; see OpenFL, which underlies both HaxePunk and HaxeFlixel. What I personally really want to do with ggez is make it run on web, not add more functionality.

That said, a lot of the things in your list are things I need for games myself, and some I've started implementing (very haphazardly) in the https://github.com/ggez/ggez-goodies repo. I also have a template for starting a new game that I'm working on, which pulls together some of those things: resources with warmy, ECS with specs, scenes and cameras with ggez-goodies... Physics and networking are the main gaps where I'm not able to write something high-quality myself (and don't have time to learn, alas), so we need 3rd party crates for them. I've contemplated turning that project template into an actual engine, but haven't really gotten to that point.

I also have some semi-hacky GUI code in an incomplete game project that I should refactor out into its own thing someday, if people want. It's not really designed to be general purpose though, and I, uh, don't actually know how to write GUI's...

When do we want 1.0 to be released? I dunno; it's not really connected to a date in my head, it's more the promise of API stability. In terms of functionality, I feel like 0.4 fulfills most of the goals I had for ggez but I still need to actually use it more and give it a good shakedown. If we eventually decide to get it working on WASM or kick SDL to the curb or stuff that will probably produce breaking API changes, but... No reason there can't just be a 2.0 release later if the API needs to be changed.

[termhn]

I would say one of the main things personally would be robust, though relatively simple sprite/animation support. One of the things I think Cocos2D got very right is the way they handled sprites... IMO one of the biggest pain points with ggez atm is having to basically write your own animation system once you move past the simple "draw a static image/mesh here and move it across the screen."

[itmuckel]

I also have a template for starting a new game that I'm working on, which pulls together some of those things: resources with warmy, ECS with specs, scenes and cameras with ggez-goodies...

Could you share that template? I'm trying to write my own game engine on top of ggez, but I'm struggling a bit, since all books on game programming patterns are focused on OO.

For me the most important thing for a library is stability. So I like icefoxen's idea of stabilizing ggez instead of introducing too many new features.

[icefoxen]

I'll share it as soon as it's in a state that anyone else can make sense of, totally.

edit: Oh, one more thing I forgot to communicate... My plan for a 0.5 release is basically to make ggez work on wasm, and on iOS/android if possible, while changing the actual API as little as possible.

[icefoxen]

If we want to start putting together a higher-level library, I've made a place to do so: https://github.com/ggez/sylvite

[itmuckel]

In my opinion a good idea. Keeping ggez "low-level" and as stable as possible, so people interested in writing their own engine have something to build upon and at the same time have a higher-level library.

[Manghi]

I agree, I think you've mostly met your initial goal with 0.4 by now. I would then align with @termhn and focus on stability and, my two cents, a bit of stabilization. If there are any existing features you want fleshed out (say audio, for example) this would be a good time. The only thing I can think of now, aside from audio, would be perhaps tunnelling SDL2 or gfx functionality through apis, but how thorough I'm suggesting is really up to the community. I haven't found myself needing to get to sdl context since 0.3, but I also haven't done much graphics as I too am focusing on other things.

I suppose my point deep down is, why the rush? (Devils advocate: 1.0 is the shining completion beacon that crate owners live for.)

[icefoxen]

why the rush?

That is a very good question! And upon some soul-searching the answer is "because it would be cool for Rust to have a 1.0 game framework". So... basically advertising for Rust, I guess. 😁

Also, argh, audio really is something that deserves more work. I wanted to learn more about sound programming and such this year, and it really didn't happen.

[Manghi]

Not a bad reason at all 😋 .

learn more about sound programming

For sound creation, how about something like this? Decent sound programming list on Wiki.

But if you're talking about when to play a sound, well I am also in that boat. "When an event happens" is about as far as I've gotten so far.

Right now ggez audio is essentially a pass-through to Rodio. In what ways were you hoping to expand upon that?

[icefoxen]

I don't know! That's part of the problem, I don't even know what it's missing. So, I need to write something that uses fancy sound features from another library.

[icefoxen]

@itmuckel Still massively incomplete, but, see https://github.com/ggez/game-template

[XAMPPRocky]

Personally for me a UI library is the thing I want the most. As trying to implement a UI by scratch takes so much work.

[itmuckel]

Is it feasible to drop SDL2 in favor of a rust-only-gfx library?
I wanted to show a game I made to a friend (on a fresh windows 10 install) and it took a bit of fiddling around to install sdl2. Also when you want to ship the game you need to pack SDL2 with it. So are there plans to get rid of it? :-)

[onelson]

@itmuckel as per #29 I think it's safe to say there is intent (if not a plan) to drop the SDL2 dependency.
The engine is written with gfx-rs, which has various backends it can use, however the biggest gaps between the SDL2 backend and glutin (for example) is the input support.

Last time I looked, SDL2 was the leader when it came to controller support, but looking at the glutin docs, it seems they have generic device events that could be used to fill the gap https://docs.rs/glutin/0.12.2/glutin/enum.DeviceEvent.html

Beyond that, I know there's been a bunch of shader work done in ggez since I was last watching closely. Not sure how much of that depends directly on the SDL2 backend.

[onelson]

I'm looking back through the comments so far, and I'd say less is a lot more for 1.0.

In my mind, sprite animation, tilemap support, a UI framework, ECS, all of that can happen as contrib or in other crates. Love2D doesn't offer any of this out of the box - it's all in separate packages.

I do think pushing for pure rust, and in doing so polishing the build and release story would be worthwhile. Developing easily, then building and distributing easily are core to the Love2D experience. We don't have it yet. #274 might open up some opportunities for this.

[cessen]

@icefoxen Re: audio

I'm playing around with ggez right now to make a simple rhythm game, and an issue I ran into is that there's no way to determine how much of an audio clip has played so far. In general, you can't actually depend on the audio hardware's clock and the system's clock to progress at exactly the same rate, and in this case that led to drift between the beat events the player was supposed to hit and the song's audio. At the beginning of the song, everything was in sync, but by the end of the song it was off by 250ms or so.

I fixed this by directly using rodio and its PeriodicAccess type to keep an audio-based timer up to date, but it's rather inconvenient to go all the way out of ggez's library for that, since e.g. I lose access to the convenient resource-based loading for audio.

Maybe I should make a feature request issue for this? It would be really useful for any games where events are triggered based on audio rather than the other way around (which is probably mostly rhythm games, but there might be others).

[icefoxen]

@cessen Please, if you have a good idea of how to extend rodio's API further into ggez then by all means, make a PR or at least some discussion of what the API should look like. When I started ggez rodio didn't have this sort of capability, but it's become much more powerful of late and ggez has neglected to keep up to date.

[cessen]

Will do! Thanks!

[icefoxen]

After figuring out my giant blog post and playing around more, my tentative plan is to do all the "easy" stuff that ggez still needs doing and call it 1.0, if nobody has any objections. Then work on a much more experimental 2.0 can proceed on the basis that it will be able to be run on wasm32-unknown-browser or some equivalent, and I can happily spend the rest of the year yak-shaving my way into making that equivalent exist.

List of "easy stuff":

[ ] Fix outright bugs: #302, #304, #301, #300, #294
[x] gfx_glyph integration (#132) and pixel size fonts (#268, #259)
[x] sRGB toggling (#299)
[ ] Better audio stuff in general: #245, #75, #208,
[x] Refactor inconsistencies, esp filesystem API: #234
...

List of "maybe" stuff:

• Automatic sprite batching #346
• Custom cursors: #265

Things that will happen afterwards, if at all:

• Port to winit #29
• Context-less API #295

Current plan:

• Release 0.4.3 with lots of bug fixes
• Release 0.5.0 with API breaking fixes
• Release 1.0 with a Good API based on existing work
• Work on a 2.0 with wasm support using pure rust.

[Ratysz]

Additional things worth a look for 1.0:

• #346
• #295 - not the issue itself, but relevant to it: context-less API.
• #353

Other than that, this looks like a very sound roadmap; hopefully I'll be able to lend a hand within the week.

[XAMPPRocky]

@icefoxen I read through your post and I'm not really seeing the justification for 2.0? Do you see wasm support requiring breaking changes? It seems like wasm is support is the real 1.0. Why wouldn't wasm be a 1.x release or the 1.0 release? What promise of stability is there with 1.0 if there's already breakage planned?

[icefoxen]

Thanks for the input. My view right now is that good wasm support basically requires moving to winit, which will require breakage. Winit is not quite feature-complete either, so my thought was to make 1.0 do the best we can with the existing compromises (SDL2), then 2.0 will have different compromises, at least until we can make winit better.

I'm not married to this path, it just seemed logical.

[nico-abram]

Is the current, updated, road to 1.0 available anywhere? Are the lists of stuff with ticks in the comments above updated?

Is it ok if i ask a few unrelated things like, what's the state of wasm support, audio, usage of winit and the dependency on sdl2?

[icefoxen]

@nico-abram The state as of January 2019 is summarized here: https://wiki.alopex.li/TheStateOfGGEZ2019

• The state of wasm support: Still not very good, it's intended to be the focus for 0.6
• Audio: Much better
• winit: Works in the 0.5 release candidate, but there's some frustrating bugs. SDL2 is no longer necessary.

Feel free to ask if there's anything else you want to know!