Why Piston?

[bvssvni]

This idea came up from discussion https://github.com/gfx-rs/gfx-rs/issues/346

http://www.ted.com/talks/simon_sinek_how_great_leaders_inspire_action

• How to inspire actions by telling people what you believe

Looking at our website and the README, it does not tell you why Piston exists.

[Denommus]

Well, I think each of member of the team has a different dream about Piston.

Personally, I dream about a game engine with an almost declarative level of abstraction, while keeping efficiency and power.

[bvssvni]

What about this:

When writing a game, an interactive application or something you really wish you could do with computers that you can't do now, you are going to need lots of lots of code which will take tons of work to maintain, will be hard to debug, and require superhuman brain power to expand without falling into design traps. We believe working together and sharing best practices leads to lower risk of failure, higher quality in code, less burden on the programmer, better dependency structure and seamless integration between frameworks.

[bvssvni]

Or, we could just say it's a user friendly game engine! ;P

[Denommus]

A big part of why piston exists is because of Rust. What do we value in Rust that makes us use it?

For one, I think safety, concurrency, performance and abstractions are strong points.

[erlend-sh]

I think you'll have a lot of ammo for this if you grab all the positives out of the Jonathan Blow about a new programming language for games debate.

Until you're on critical-feature parity with the big dawgs, your users are going to be

1. Rust programmers looking for the best Rust game development tools.
2. Newcomers to Rust, looking to master the language through game development.

Of course you should sell your users on "a user friendly game engine". But your message will be both clearer and more effective if you sell them "a user friendly game engine BECAUSE RUST".

[bpicolo]

For what it's worth, I'm not actually convinced that, as it stands, Piston is particularly user-friendly. It seems mostly like a set of disjoint components right now, and while I get that the aim is modularity, modularity without some core to work around is, in my opinion, a HUGE blow to usability.

What I'm suggesting, I suppose, is that we should work a bit more on a great thing -using- the modular components. Interfaces/Traits in Rust, used properly, are what allow us to be able to get that modularity, but I think it's important that one core accepts them in a common way, and allows us to build games.

I think that's what all the descriptions / project goal suggest happens right now, but it doesn't seem to me like that's actually the stage it's at.

I.e. It would be very, very powerful to be able to write a game one time on some common core and then swap opengl/directx backends via a dependency change, for example. I don't think the explicit modularity right now provides for that in a friendly way.

[bpicolo]

As an explicit example, piston-examples doesn't actually have piston as a dependency for any of the examples, and that was done recently, on purpose. Seems like the opposite direction of what should occur. That seems super awkward.

[bvssvni]

@erlend-sh Read http://www.reddit.com/r/programming/comments/27kd4c/piston_a_prototype_video_game_engine_written_in/ci1zh4a This is the first response we, the first time we went official, and it is not mentioned in a positive tone.

[erlend-sh]

Not quite following. Are you saying you don't think selling the engine as a "Rust Engine" is a good idea?

[bvssvni]

@erlend-sh It might be that I misunderstood you, but I thought your point was emphasize using Rust. Of course Rust is a good language, but Piston is trying to build constructively on the strengths of language, which is has not been a straightforward thing to do. There are many patterns we tried that did not worked well, so we had to change our design over and over until we got it right. This is a process we are still going through. There are some downsides to marketing a language together with a game engine, which is 1) the perception that the language is the main reason you should choose the game engine, and that 2) Piston was only possible or easily achieved because the way Rust works. This gives the wrong first impression by my opinion.

I think it is more appropriate to put more weight on 1) the smart people working on Piston and 2) our participating in the Rust community. I don't think we need to market Rust as a language, because our focus is showing what "real stuff" Rust can do and how we can work together. People interested in Piston are perhaps more interested in what they can build with Rust than the details and qualities of the language. In a way we are promoting the language, but the focus is not that much about Rust itself, but about the applications.

I think Piston should be promoted as a game engine, but the fact it is written in Rust is a material aspect and not the functionality we want to sell.

[dobkeratops]

I'd say synergy between language and engine is interesting.. talking about Rust as a 'feature' is good, IMO. languages & software bounce off eachother. (big example: ObjectiveC & NeXT/Apple application frameworks,culminating in Swift as a 'reskin' for the same interfaces)

So with Rust/Piston:-

• It might make development with a decentralised team easier (due to safety/stability/communicating more in types, and the superior composability/decoupling of traits vs classes).
• or it might suit writing huge amounts of generic code better, making it easier to customise?
• many C++ projects have to bolt on reflection (e.g. Qt MOC) , but rusts macros/syntax-extentions can do it out of the box.

And I personally think there is still room in the world for a language designed even more closely for the gamedev process, r.e. games' unique blend of creative rapid-iteration & technical high performance needs - traditionally seen as opposite ends of the language spectrum e.g. Lua & C. There is one historical example of this being done in a single language with a customised Lisp variant, on the PS2 ( at the time, it gave unique hot swapping of level scripting/AI code simultaneously with fine control over that platforms unusual architecture in rendering code). Contrasted to this we've had things like unreal/unrealscript/kismet on top of C++, and unity revolving around C# + C++ .

This is far from the stated goals of the Rust team, as far as I know, but who knows: the language is still evolving, and a project like Piston has a chance to shape the language with feedback... perhaps there's scope to get hot swapping of trait based code, maybe generics could be compiled in a rapid iteration mode where they take vtables instead of being monomorphised, taking advantage again of how Rust bases both forms of polymorphism on traits.

[bvssvni]

@dobkeratops I have some ideas about a scripting language, which I will write up when I get around to it.

[UberLambda]

A Rust/C++ and Lua/Python hybrid would be awesome. A lang that could in someway be compiled to be very performant and still be able to be interpreted easily.

[bvssvni]

Here is the write up about the scripting language https://github.com/PistonDevelopers/piston/issues/672

[erlend-sh]

@bvssvni My point is that for the next year, while Piston is still in its infancy, you won't be getting any of the casuals and lightweights.

Unity3D doesn't have to sell itself on its foundation because:

• The game development itself is so abstracted from the (closed) game engine that it doesn't matter to the average game developer what makes their game run, as long as it runs well.
• It has multiple scripting languages.
• It has already established itself as the most popular cross-platform engine there is, so developers choose it because, even though it might not be a perfect fit for them, it's unlikely to be a bad fit.

While it's young, Piston is going to appeal to those developers who dig a little further. Unity3D and UDK doesn't quite do it for them, because they have an itch to scratch.

What itch does Piston scratch?

[bvssvni]

@erlend-sh I see your point. Exploring game development in Rust has been a research goal for Piston, and that is perhaps the major reason why casual game developers are interested in it.

Rust removes a many error classes that makes it hard to maintain large code bases. This, and that it is complete open source with a great community. There is nothing that stops you from doing whatever you want. The only problem is that Rust and the ecosystem is in the early stages, but this will be fixed over time. As things stabilizes, we won't be working that hard to maintain stuff and the investment will start to pay off.

The itch that Piston scratches is reducing time cost and increase the quality of how you spend the time. Working on libraries to get them right is hard and it costs a lot. Our main focus is solving this through collaboration, so the thing we sell is not just what you can get from using the libraries, but what you get from collaborating on Piston.

For example, a goal could be to solve particular problems, such as generic event programming, faster 2D graphics or such. This would not be possible without a way to reduce the time it takes to maintain code. "Why Piston" is not just about solving particular problems, but freeing up time such that these problems can be solved. Therefore, it is important to market the way we work to solve such problems, because that is what the biggest problem developers have: Time. People might be more or less interested in the particular solutions, but what they are very interested in, is collaborating such that they can solve their problems easier, faster and get a higher quality solution.

Piston might have something to offer now, like an environment to dig deeper in game development, but that is not the main philosophy behind the project. No matter how far we go, it will always be freeing up time to do research and building new things that is the thing Piston optimize for, because that is what we really want. You can take out a stop watch, try to do something with a Piston library and then try to repeat it doing it all yourself, and then see how long time it takes to do and how good the result gets. It is quite obvious that saving time is very important, but the result also matters. It is also clear that Piston does not save time on every task for game development. Yet, we can't just say that people should pick Piston because they want to dig deeper in game development. That might be true or not true. This is not the message I want to communicate.

I want to show that by participating in the Piston project, you can pursue your personal goals, whatever that might be, and the person that knows best what those goals are you, not me. The tools you make to achieve it might be useful for other people and by sharing the cost of building them and helping each other, we get to the goals faster while spending time in a better way. Piston has solutions for some things, but that is not the point. We make cool stuff, but that is not the point. The whole point, the whole "why Piston?" is because of the way we work, which makes it possible.

Well, you could say "that is not a goal" or that is not the right way of thinking of a game engine. What is a game engine then? It is a set of libraries to save time! This is what Piston is! All games are different, so we can't say you should use library A or library B without understanding what kind of game you want to make. We are just trying 1) free up time and 2) solve problems. It is not the world's most advanced philosophy, but has worked pretty well so far.

[bvssvni]

I'm cleaning up the issue tracker and will close this to give room for more concrete discussions.