-
-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Define some broad goals/use cases #13
Comments
The primary domain I had in mind was game scripting. However, I did not have some large idea or vision when starting on it. It was just fun to work on. Here are some other thoughts I've had:
OrdinaryI tried to think of language ideas where I had the feeling "oh, this was nice" but not be overwhelmed by new ideas. It should look familiar if you have used Rust, Go and Javascript. For example, Lua tables are nice but I like the distinction between arrays and objects in Javascript. Ordinary is also another way of looking at features that are comfortable in other languages. A language for doing stuff, not proving theorems. Rust is a good language, but it is a bit heavy. I want something that integrates well with Rust, without being Rust. Dynamical types is very nice for reflection, where you can write code that operates on any object. For example, sending data across the network, or a property editor widget. The lifetime checker is a separated step requiring some extra syntax, so if this idea gets in the way later we could try garbage collection instead. Maybe type checking also could be made this way. Tooling
We need a way to organize the built-in functions so you can customize it for various game engines. One idea I've had: A kind of browser, but with a game loop instead of HTML. Large standard library with game related features. Hyperlinks and ways to share and connect what other people make. You could open up stuff made with another syntax by sending the meta syntax with the code. However, the browser idea might take a lot of work, so my goal now is to write a few small games with it. Don't excuse the languageIt seems very easy to try to find the easiest way to change a language in order to get a new feature. This could lead to some problems where you figure out a simple but flexible way of covering a lot of features. Then the language ends up with a meta language on top. I do not want a super flexible language, but practical and convenient for most common tasks (ordinary). There are probably some tradeoffs to make, but I don't want to excuse the language and try to convince other people that some idea is the right way. It is either in the language or not, and if it is not then I don't want to take shortcuts. |
Hmm, that helps. I have some ideas I'll write up in separate issues. I don't think allowing the syntax to be drastically altered is a good idea though. While it sounds appealing, I can't see it being anything but trouble. A language's syntax is an important aspect of the language, features can live or die depending on the syntax used to express them. I also don't think it's worth supporting, I can't see how it really adds anything except confusion. The last part confuses me. I'm not sure what you're trying to say. I think you mean that you want the language to be focused, and that you don't want to add in features that don't support the language as a whole. |
Hmm... good points. An added feature in one syntax might conflict with another. You got the last part right. |
Closing for now. |
Given it's place in the Piston project, I've been assuming that dynamo is intended to be used for game scripting. However, that's not explicitly mentioned anywhere and I don't want to spend time writing a proposal that turns out to be inappropriate for your vision of the language.
If it is game scripting, what kind of level are you expecting it to be best at (keeping in mind that people will contort any language into any situation with enough effort)? Is it intended to be mainly used for large amounts of game logic, or for small bits of custom behaviour?
I'd like to help with the language, but I don't really know anything about the language to do so.
The text was updated successfully, but these errors were encountered: