Game and Killer Language Features?
Community Forums/Monkey2 Talk/Game and Killer Language Features?
| ||
| In the other thread we mostly talked about features that any good language should have. I'd like to see if anybody has anything that could really draw attention to the language from other languages and from game programming point of view. Obviously, as a language that Mark is producing it will have a graphics library... and hopefully a good collision library built in. but early on I'm more interested in talking about things that can help facilitate and speed the writing of those type of modules. some of these are might totally theoretical and may not be useful at all but I'd like not discussing them means we may lose an opportunity to incorporate something great. - direct access to c libraries without having to first build the sometimes complex interfaces like had to be done in bmx. (this might have been talked about a little already.) this would speed the development up very quickly. - would it make sense if 2 and 3d vectors were built in? - compiler support for complex numbers helps with robust prediction for collision detection and penetration... does this make sense to build in or is a type sufficient? - what about AI, having a virtual compiler for the language that can included in the executable for scripting? why use Lua or something when we could just use this language for both? (or make it super easy to include and interface any language like Lua or Prolog). - I still think we need either extension methods or some ability to split class design up into separate files( I guess might be more general than game oriented) - closures.. but it sounds like Mark got these in already(?) any ideas? especially really out of the box ideas? |
| ||
| - I mention this before but I think adding dynamic composition would allow very clean componentization. and as ziggy mentioned in the other thread, many prefer composition over inheritance and with this how could you not :) What I mean by this is: Class Transform Field position:vector2 Field rotation:vector2 Field scale:vector2 End Class Class Collider Field transform:Transform End Class Class Entity Field transform:Transform End Class Local e := New Entity e.collider := New Collider(e.transform)then have a quick way to query and process dynamically added fields. is this too performance poor? if there is a way for keep performance great then this would be killer. something like For Local e := Eachin entities For Local m := Eachin e.members m.update Next Next |
| ||
| My top suggestion would be to deliver proper interfaces for core components such as collections. Having a common interface for most common usages of collections (enumerator generators, count, and Empty boolean method and any other extension method built on top of enumeration, such as ToList or ToArray). And also, similar functionality where it makes sense, such as being Sortable (an interface for comparison methods), etc. Also, if there are very core parts such as Vector2D and Vector3D structures, provide an interface for them too, so people can pluin their own implementations of vectors when mixing libraries such as Box2D or similar into the party. Making an extensible language should come with an extensible framework. I hope dependencies are towards interfaces as much as possible, instead of being towards fixed classes, which would disallow for a higher level of extensibility and integration of thirdparty APIs. An example, a common interface for fonts where you expose just a DrawText(text:String, Pos:IVector2D) and a MeasureText:IVector2D(text:String) would be great so people using different font engine's system could be using the built-in mojo-like font system as long as they implement the provided interface, etc. |
| ||
| I agree with stepping up the use interfaces for the core modules. That right there I think will allow quicker adoption and updates to the language as a whole. Here's another, I was thinking about performance in tight lists and ran across this paper http://people.mpi-inf.mpg.de/~strzodka/papers/public/St11ASX_CUDA.pdf and then saw Blow's implementation of it here https://www.youtube.com/watch?v=ZHqFrNyLlpA. worth a watch I think though Blow is trying to make his own 'game' language. in some case talking about features that bmx or monkey already have. he also makes a great case for powerful 'using' or 'with' namespace modifier. |
| ||
| Other from the very specific feature requests that have already been made, my 'high level' wishes would be: * Create a language that keeps the simplicity of monkey1 / BMax * Fast compile times (like BMax fast) * Decently fast execution as games are the main focus * Deterministic GC (https://en.wikipedia.org/wiki/Deterministic_garbage_collector) so you are not surprised when it suddenly stops your game. That means we have to have some control over it. * Have a standard way to extend the language * Docs @dmaz: That's a great video explaining performance problems with the classical inheritance approach. @ 16:42 in the linked video: The dogma of high level languages for decades has been: the programmer shouldn't have to care about the representation, they should only care about the abstract ideas of their data structures, they shouldn't have to care about the low level implementation details. What we have learned is that's not really true. At least for games, this is very true. You can't program just ignoring the cache. |
| ||
| +1 to ziggy's suggestion of more usage of Interfaces in the core classes. I imagine that the only reason this wasn't done originally was because they came later and were fiddly when the core containers were designed. Generic interfaces weren't even allowed until years into Monkey's development, so that would've made incorporation into the base classes impossible, kinda annoying for things like Comparables / Comparators. Some consistency for container syntax was a thing early on, too, before some of the old methods were depreciated. Here's a good interface to emulate for all future Monkey containers to implement: https://msdn.microsoft.com/en-us/library/92t2ye13%28v=vs.110%29.aspx That being said, I don't know if there's a way to enumerate collections in a way that can translate to no "hidden" overhead when using EachIn syntax as it does currently. This is a problem, because the current GC can halt the render thread (resulting in an unsmooth experience, very very bad for games running 60fps!) and eventually, it will. I think what I'd want mx2 to have most of all is better multithreading support. Background workers (for loading screens that don't choke), functions that can Yield values (ie: a way to code multithreaded apps in a way that "appears" procedural to the amateur programmer), and a generational garbage collector, either concurrent or (if possible!) in the background and non-blocking. Hell, we could even possibly steal the GC straight from .NET, now that it's MIT-licensed. That does preclude putting parts of mx2 in the public domain, but MIT is an extremely permissive license, particularly coming from Microsoft. We get the above, and we basically make it so all games designed by amateurs are still gonna look silky smooth 99% of the time even if their implementation is kinda poor on the memory management front. That's kinda a big deal when it comes to making a language package newb-friendly! We don't want new users to end up having to hit the nuts and bolts of computer programming right out the gate when making their first game, if possible. If they're able to have a semi-guided end-to-end experience the first time around while still feeling the pulse of "real programming", they will want to dive into the nuts and bolts themselves, and again, mx2 should totally give 'em all the tools they need to do that. That, in turn, will boost adoption rates on both the gamedev and general-purpose fronts. This "guided experience" is part of the reason why Unity is so popular.... even without all the extra bells and whistles their IDE and their specific runtime provide, MonoGame itself is taking care of many fine implementation details without hobbyist coders any the wiser. |
| ||
| A standardized and documented way to access the AST (Abstract Syntax Tree) would be nice for plugins. In a really modular system the - front-end (lexing, parsing) - middle-end (semantic analysis, certain optimizations, generating intermediate representation) - back-end (output-code generation, target-specific optimizations) would be separated and allow replacements/plugins at certain positions, for adding new targets/optimizations/pre-processor stuff (macros), etc... Mark could concentrate on C++ target, while other guys add Java, JavaScript, TypeScript, Google Go, ... targets. Also, I would like a mode where the compiler checks the whole code. Maybe an option "-syntaxcheck"? MX1 compiles codes that contains errors, when the code part is not actually used. That's nice for compile speed optimization, but really sucks when writing a library or import. Errors in code should be shown immediately, not weeks later, when a certain class gets used first time. When pressing F5 I would like to know immediately if everything in my code is OK, even when I did not actually use every class and method I just wrote. I want to know that everything I just wrote is completely good and error-free - a complete syntax and semantics check, so to say. Actually, every compiler I ever used does always do those syntax and semantics checks, exept MonkeyX. MX1 is the only compiler that does no syntax/semantics checks for un-used codes. That is really weird, because codes compile fine - and later errors pop up, when actually using that code parts. Errors pop up when I try using a specific class, while they should be shown as errors in the class definition directly. In my personal opinion, case-sensitivity is just annoying. To differentiate between "onUpdate", "OnUpdate", and "onupdate" does not make sense for a BASIC-like language. It just leads to errors that the compiler actually does not catch, if you accidentally write "onUpdate" instead "OnUpdate", when you want to override a method. In MX1 this are two completely different methods, because of case-sensivity. It sucks. A simple typo compiles correctly in this mode. For example: "OmUpdate" instead "OnUpdate". The only part where case-sensivity is really important, is when importing stuff from libs and external codes, because some target languages are case-sensitive, so the function/class/method names need to be exact. MX2 should internally not differentiate between "If a = x" / "if A = x", and "x.doit()" / "x.DoIt()". While importing three.js, I got the problem that Monkey1 keywords can't be variable names. I consider it a minor issue, but I still want to mention it here: When importing a lib from any language, field names like "THREE.Texture.repeat" may be possible. "repeat" is of type Vector2, so "texture.repeat.set(x,y)" is allowed/valid. In MX1 keywords are not allowed as variable/function/method/class names, so one workaround is to use 'Field repeat_:Vector2 = "repeat"' or 'Field repeet:Vector2 = "repeat"' in those situations. "repeat" is not allowed as a variable/function/method/class name. |
| ||
| I was looking at dmaz's link with regard to 'structure of arrays' vs. 'array of structures'. The funny thing is, the structure the author used as an example was four floats. I bet you could get better performance than either with an explicit 1D array! |
| ||
| @Danilo I grew to love case-sensitivity. A proper IDE can catch these and give a hint when compile errors happen, and I'm pretty sure even trans gives you a hint. Plus, case-sensitivity makes for better class design patterns; in a way, it enforces more consistent casing in variable naming by making life more difficult for people who don't adopt some sorta system. That being said, negative reinforcement in a language is often frowned-upon, but in this case I think the versatility outweighs the disadvantages. The only thing that shouldn't be case-sensitive are reserved keywords. |
| ||
| Case-sensitivity is just a lost of time, when you type and when you read a source code. Define a language 'modern' just because YOU need to write keywords/vars etc in a specif way it's far far away from my concept of 'modernity'. But I know MX2 will be case-sensitive... and my hopes are lost! :P ps: Personal rant, I like some things in MonkeyX1 Local mine:MyClass = New MyClass 'same as Local mine:= New MyClass 'handy But I still find very 'type-confusing' the generic-classes Class Pointer<T> Maybe if it is possible to change in another form Class Pointer--T Class Pointer::T Class Pointer:T (I think this is quite understandable, as tells to the compiler there is 'something more' than a simple class Ok, I go back to my things! |
| ||
| In my personal opinion, case-sensitivity is just annoying. To differentiate between This is usually solved in other languages by explicitly requiring a deriving method to be marked as such, so typos can be detected. Something like:"onUpdate", "OnUpdate", and "onupdate" does not make sense for a BASIC-like language. It just leads to errors that the compiler actually does not catch, if you accidentally write "onUpdate" instead "OnUpdate", when you want to override a method. In MX1 this are two completely different methods, because of case-sensivity. It sucks. A simple typo compiles correctly in this mode. For example: "OmUpdate" instead "OnUpdate". @Overrides method OnUpdate() ... end If you miss the @overrides mark, compiler should throw en error (or warning) indicating that you're hiding an inherited method, then, if you set the Overrides but misspells the method name, it'll throw an error in the lines of "Method onUpdate" can't be declared overrides as it does not override any base method. |
| ||
| I grew to love case-sensitivity Yeah, I sometimes work in BlitzMax and I really mis having case-sensitivity there! Can't imagine without anymore... |
| ||
| I like case-sensitivity but with solid auto-completion. |
| ||
| Same here! Used to hate it, but now, thanks to Monkey, really like it, but would definitely prefer auto-capitalisation for keywords and imported module functions, etc. |
| ||
| I like case too but back to the original topic... anybody, killer ideas for the language? |
| ||
| I like case too but back to the original topic... anybody, killer ideas for the language? Async and Await keywords: https://msdn.microsoft.com/en-us/library/hh191443.aspx |
   |