Progress report...
Community Forums/Monkey2 Talk/Progress report...
| ||
| Hi, Apologies there is no release as yet, but things are getting close! I have around 80% of monkey1 language implemented, with a few cool improvements in such as enums, generic functions, function values and namespaces. There are several major features missing which I am hoping to get more feedback on after V.01 is released before getting stuck into, including the preprocessor (although I'll probably have to mung something temporary in soon), eachin iterators (for loops are currently 'C style' only, which might stay as an option), whitespace in expressions and more. The compiler is also much stricter than monkey1 (eg: you must have statement separators), although this will probably relaxed over time - esp. if people want 'private method...' to work! But I think it's better to start strict and relax where it's worth it, as opposed to my usual approach of start relaxed and leave it at that... There is also no module system in yet, and wont be for V0.1. This is something I really want to think about carefully before attempting. I did have something 'sort of' going, but I wasn't happy with it as, like monkey1, it was too 'source code' oriented. We need a way to package stuff the way c# does with assemblies, or darwin does with bundles etc. There are lots of details to consider here, so it's on the 'later' list. But bmx style import is in and can be used to add source files to a project, so you can import "blah.monkey2". This will in fact likely be the standard way to 'pull in' monkey files (you'll probably also be able to specify them on cmd line) when building a project. Like bmx, you can also import .c, .cpp etc files, ie: import basically just adds files to a project. I've also pinched the <blah> syntax from C to allow importing stuff in system locations, eg: import "<Cocoa.framework>" will link your app with the cocoa framework, import "<opengl32.a>" will link with libopengl32a etc. You can even import "<stdlib.h>", which will make stblib.h available to all files. I'm currently spending most of my time working on this side of things, ie: the build/extern system, and am in the processing of getting SDL2 (a 'game framework' library) up and running. I have chosen SDL2 because it offers a useful set of base features, works everywhere, and is a relatively challenging stress test for the build/extern system. I'm not sure whether SDL2 will be used as the base for future modules like mojo2, but at least it'll be there for people to use for their own stuff if they want. Which brings me to a bit of good news - monkey2 WILL target html5 via 'emscripten'! There are 2 main factors that have changed my mind on html5 support - the fact that the emscripten tools are so damned good, and the recent announcement of 'wasm' - more info here: https://brendaneich.com/2015/06/from-asm-js-to-webassembly/ Basically, wasm looks like being the 'abstract byte code that works everywhere' that coders having been dreaming about for decades, and I don't want to miss out! It also convinces me that this asm.js stuff has a real future, and that it's not just a passing novelty, something I've been a bit worried about when deciding whether or not to commit to html5/emscripten etc. What this does mean, though, is that monkey2 wont have thread features 'in the language'. This is a bit of a shame as I had some pretty interesting ideas for 'async methods' and the like, but I think it's worth the sacrifice. Also, I still plan to provide threading support for targets that support threads, much the way bmx does. Anyway, my goal for V0.1 is really just to clean up what's already there (if I were to release now, the forum would just clog up with bug reports!) and get SDL2 working to the point where you can actually do something with it. [edit]sounds like the emscripten/browser guys ARE working on thread support anyway - good news![/edit] How long will this take? Hopefully a week or so - I'll give it a shot anyway! But I do want to wait until I've got something both relatively bug free and relatively useful before releasing. |
| ||
| Mind blown. I have to re-read this and reaserch part of it, but,...wow! |
| ||
| This sounds great. |
| ||
| Awesome! [edit]sounds like the emscripten/browser guys ARE working on thread support anyway - good news![/edit] that means you can put the thread features back in the language... right... :) |
| ||
| Awesome! SDL2 is good stuff too. I use it a ton for my C++ projects. I was actually shocked how easy it was to get a native C++ app running on Android with it. |
| ||
| ...and almost forgot, multidimensional arrays are back, eg: local map:=new Map:Tile[ W,H ] A minor thing, but I use them seldom enough that I always find the 'array of arrays' approach confusing whenever I need them. |
| ||
| BlitzMax's use of a centralized directory for library imports was a good design decision. Importing libraries in C++ from various paths, on different machines, is one of the major pains of working with that language. I don't know how Import in Monkey works, but I would encourage you to again side with simplicity over options when it comes to this feature. BMX-style use of threads sounds great to me. I am curious how garbage collection and debugging work with C++. I hope to port the entire Leadwerks Editor to this so we can make a 64-bit build. Thanks for the update. |
| ||
| Awesome everything! I love the SDL idea, I *did* tried to get SDL working on Monkey X, but it was too time consuming to me, so I'm gald it's sort of coming for Monkey 2. Just, if you ask me, are you sure you want the < and > identifiers to do even more things than compare elements and define templates? They're already doing 2 separated unrelated things, Are you sure we need to add another one to the party? (I honestly don't like it) I prefer operators to be meaningful at the tokenizing phase instead of being meaningful at a later "semanting" phase, as it makes the language a lot easier to parse and much more context-agnostic, which I think would make the language more solid. That said, if the < and > is being kept inside a literal const, as your post seems to suggest, then I think it would be much better, and I could be very happy with this approach. All in all, very exciting good news. |
| ||
| > That said, if the < and > is being kept inside a literal const Yes, it's just a filename thang. Import takes a literal string and simply passes it on to the 'builder' (sort of like BMK) which decides what to do with it, eg: Import "<SDL.h>" 'now all code can see/use SDL |
| ||
| Wow, sounds great and really glad you are going to support html5 via emscripten :) |
| ||
| > BlitzMax's use of a centralized directory for library imports was a good design decision. I will definitely keep this approach once it's decided how modules/libraries work, but things will work kind of differently from bmx due to monkey2 being a 'transpiler' (love that term!). For instance, header files in modules will need to be made publicly available more than they did in blitzmax. But I think the key thing is to keep modules self contained. As long a module dir/package contains *everything* (apart from extern module dependancies) required to make it work - ie: headers, libs, interface files whatever - all should be good. |
| ||
| > that means you can put the thread features back in the language... right... :) I'll see what they come up with first! |
| ||
| But I think the key thing is to keep modules self contained. As long a module dir/package contains *everything* (apart from extern module dependancies) required to make it work - ie: headers, libs, interface files whatever - all should be good. That would be very nice.One thing I found to be very nice in BlitzMax, and miss in Monkey, is that, as BlitzMax allows code at the root level (this is not nice), it allowed for modules to have initialization code that was run when the module was imported, and this is very nice. It would be great to have some sort of Function Main() (name it as you wish) for imported modules, to have the same functionality as we have in BlitzMax, but with better organized code. |
| ||
| Exciting times! |
| ||
| +1 for html5. Makes it easier to create online showcases. So we are actually not losing any interesting targets! |
| ||
| Exciting times! I just ordered a new video card and I am upgrading to a quad core CPU. Getting ready.:) I'm digging the 'transpilier' (sounds like what Scotty might say) omnipresence concept (Voodoo Magic!). Nice game play on the video at link. Importing whole frameworks, so sweet. SDL2, yes please. Just really impressive. Will mojo2 use Drect3D someday with SDL? Maybe? |
| ||
| dmaz said: that means you can put the thread features back in the language... right... :) I hope so too. That's a lovely thing I'm seeing in modern languages, all that stuff with Async method patterns, yielding, etc |
| ||
| Thank you very much for the report on progress! One question, though: marksibly wrote: Which brings me to a bit of good news - monkey2 WILL target html5 via 'emscripten'! Will this still allow Imports and interfacing to JavaScript libs? There are thousands of interesting libs out there (three.js, dojo/dijit, ..), and if we are still able to import/use such libs into/with MX2, everything would be absolutely perfect. Many developer's dreams becoming true... Desktop + Mobile + Web development using an advanced object-oriented, non-brackets, and non-indention-depending, native, super-cross-platform language. Everything in one open-source package -> w0w! |
| ||
| Looking forward to playing with this :) |
| ||
| Wow - massive thumbs up for SDL2 and HTML5/WebAssembly support. Can't wait to see it :) |
| ||
| Hmm, i've seen so many browser technologies come and go. They tend to not stay around for very long, need testing resources and often are connected to unpleasant dependencies/surprises. That's good for agencies as there is always work available but if you want to create something which also is around a few years later, it's not the platform you want to rely on. I prefer if Mark would first concentrate on the best possible support for existing, more mature, platforms. Anyway, good news on the progress (apart from da html5 stuff). |
| ||
| Is MX2's transpiler going to essentially lex, regex, rewrite, parse and compile as Coffescript does (as I understand it). Essentially transforming code to a target language/compiler? Does it also use a PolyFill approach like wasm? Just trying grasp MX2's approach. |
| ||
| Can I say that monkey2 is a wrapper on top of SDL2. Its something like this. - [OS] -- [openGL,DirectX] (can contain bug's and upgrades) --- [SDL2] (can contain bug's and upgrades + openGL,Directx upgrades) ---- [Monkey2] What is oke, but I hope that we are able to use/update to the latest [SDL2] version, without upgrade [Monkey2] For example what can happen now and in the future. openGL or DirectX have some bugs, and or is upgrading to a higher version. Then [SDL2] is upgrading their software to support this, and maybe they have fixed some older bugs in [SDL2]. At that point we want to download the latest [SDL2] version and say to monkey where it SDL2 PATH is and ready to run ;) BTW for other people, this is what SDL support at the moment: http://wiki.libsdl.org/Introduction |
| ||
| GC-Martijn wrote: Can I say that monkey2 is a wrapper on top of SDL2. No, it's not. MX2 is a general programming language, and SDL2 is just one test for importing an external library. If the Import test would be Qt, it wouldn't automatically mean MX2 is just a wrapper around Qt. MX2 is much more powerful. This is just one example, and stress-test. MX2 (the language) itself can be used for all kinds of programming. From my understanding, it would be (additionally) a pretty good application programmer's language, and maybe even suited for web games + apps. The language is one part, and the compiler for it. The other thing is the libs that come with it, and that libs may still be game-oriented (like Mojo2). MX2 has the chance to get much more bigger and wide-spread. The game developer's libraries are okay, no problem. I just wouldn't concentrate too much on it, especially with announcements and advertisements, because it may frighten apps programmers, although MX2 could be also a very good choice for those guys. MX2 can be used for super-cross-platform apps & games development. What MX2 community needs is app programmers and lib programmers. While Mark takes care of the core language and general project, we also need app-coders for tools, and cross-platform GUI libs, etc. |
| ||
| @danilo ow ok, its hard to understand, if you can't see it yet :) At the moment there are several cross-platform IDE'S, I did use RealBasic several years ago and python. A difference with MX2 is then: language + community + preset 'game monkey sdk' (using SDL2 at the moment) + the possibility to include other library's if needed One thing I really dislike when I started with monkey (and python) was the poor documentation. For example the PHP language was in the beginning bad, but the documentation was very good, so many people could write things (and learn). If MX2 want's te be a success, than good documentation with small examples (inside the documentation) are the start. |
| ||
| If MX2 want's te be a success, than good documentation with small examples (inside the documentation) are the start. I agree and it is Very important to have Very good Documentation ! |
| ||
| I agree with Danilo about Monkey not being just for games, I have been writing commercial cross-platform applications in Monkey for the last two years. |
| ||
| @GC-Martijn: Writing detailed documentation and writing libs takes time. I guess the more people jump in and help with this tasks, the faster it gets enhanced over time. |
| ||
| @Danilo, Yep, but then a first step is to open the documentation online to add user comments below (with [code tag)) That way everyone can add some comments below the documentation. In my monkey language learning i'm using the online documentation which is available but not always. Then i don't use the forum search because it gives me to much or to less. I use google with this keyword site:monkey-x.com pointinpoly But that is not the thing I want to say here now haha. Give people the option to write/read extra documentation/comments about every function (like php does) For example: http://www.monkey-x.com/docs/html/Modules_mojo.graphics.html#SetMatrix - [marks official info first] - then a button [add extra info (or something)] and if extra_user_info>0 then show a button [show extra info] that is a simple div toggle below that function with all the comments from other users. OR using the actual forum database, this give multiple extra options. 1.) Create a new forum category: Documentation and create only once all new topics for each function. 2.) people are not able to start new topics inside that Documentation category So now you have this [Forum] -> Documentation -> SetMatrix 3.) Everyone can place extra comments and extra help about that function. 4.) At the actual help page about that function, show a link or a toggle box if there is extra info about that function. (because I don't want to click for nothing, if there is no extra info in the topic) <?php http://www.monkey-x.com/docs/html/Modules_mojo.graphics.html#SetMatrix Below the official documentation something like this $function_name = SetMatrix; // the function_name its already there because the # says it is. // this is 1:1 with the topic name, so in the database you can do this if(SELECT COUNT(*) FROM forum_topics WHERE topicName=$function_name AND cat=Documentation)>0){ // hey people are saying something about this function, show a link to the forum // or show it here inside a toggle box } |
| ||
| Yep, there are several options (monkey-wiki, github, forum...) |
| ||
| Thanks for the update. Multidimensional arrays sounds good. |
| ||
| Thanks for the update. Multidimensional arrays sounds good. Not to sound sarcastic, but, erm, yeah... Great! :/ I'm actually a bit depressed with the "update"... Shite with the syntax sugar and all that bollocks, I get that with Vala... I want to know the real deal... First off, what are we looking at here, I see SDL2 in there, which is great, yeah, but, erm, dont bite me or nothing but I can use that with anything, importing libs via <>, erm, great! :/ The whole context of the "update" was regarding html5, which is nice an all... But here's the thing... I want to make games... Why is this better then, and I will say it... Over "Unity"? IMO, and I'm sorry, but the news update was neither mind blowing or technically even a tickle Dabz |
| ||
| I don't think Monkey2 will be replacing my use of Monkey in next 6 to 12 months because the collection of .monkey I have written in last few years is already perfect and in my limited opinion original monkey can not be improved. However, I do encourage Mark to try, and it does seem a bit piss poor for you to be raining on the parade? |
| ||
| > I'm actually a bit depressed with the "update"... It sounds like you might have the wrong idea about monkey2 - it's a programming language/environment, not a game creator. As such, a lot of its features are indeed related to 'syntactic sugar and all that bollocks'. It's stuff a lot of programmers care about. It will have features that will be useful for game creation (such as mojo1/mojo2 ports to start with) but if you want a more 'pure' game creator then by all means use Unity of Unreal or Godot or whatever. I'm not trying to compete with what they do. |
| ||
| As a fan of many languages (C++, Python, Swift, Java [sorta], Lua, JS, and these parts) I look forward to taking what you are cooking up for a test drive. I don't think people realize how fundamental and symbiotic a language and engine can be, but at the same time divisible from each other. I think we have a handle on the engine part with mojo1/2. It's good to see the approach of looking at MX2 as a pure programming language, there should be tons of outside the box benefits that can cross over from other languages. Hopefully as people get comfortable with it, try out the new language tools at hand they sort out the benefit to themselves, or take a step back and realize it's there if you want to use it, but no one is forcing you into using new feature you choose not to. |
| ||
| Why is this better then, and I will say it... Over "Unity"? Uh oh...here we go. |
| ||
| It's good to see the approach of looking at MX2 as a pure programming language Exactly. The thing I think a lot of people are taking for granted is that a solid core language, that tries to hit the sweet spot of performance, expressiveness(via it's syntax), and diversity(what it can be used for) will continue to grow in popularity. The libraries that we all want to use will come organically. It's a side effect of popularity. Blitzmax took a few years to fully mature as Monkey did. Monkey2 is gonna be awesome, and being a systems programming language first will help in the long run. I'd be interested if Mark would expound on why the Blitzmax way of modules wouldn't work for monkey2. 'Import' for modules, 'Include' for source files. I think it works well, but maybe I've never stressed the system the way others have.(i,e Brucey) |
| ||
| > I'd be interested if Mark would expound on why the Blitzmax way of modules wouldn't work for monkey2. It's not so much that it doesn't work, but that it will be different - and I think we can do better. Creating wrapper modules in bmx is pretty painful, as you have to describe class/struct member layout *exactly* (ie: in a binary compatible way) since bmx only works with object/assembly code. But in monkey2, we can make use of the fact that we (usually) have access to the actual .h file, and can compile using it. This means we only have to get name/type right when describing extern class members. We can ignore members we're not interested in (such as funky Q_OBJECT metadata info), order of members etc. It's a whole lot more flexible and should make it possible to wrap a greater range of libraries without having to resort to glue code. But it does mean the idea of a 'module' is a bit more complicated - in addition to a blah.a file, there may also be .h files involved etc. In addition, a module may include inline and generic code we want other modules to be able to access, perhaps via a .p (parser output) file. So my current thinking (and that's all it is!) is that we should maybe move towards a system where modules are not just 'nodes in the source tree', but separate, standalone things, more like bsd frameworks. But again, I'm just considering options right now, a lot of this is 'internals' stuff. > 'Import' for modules, 'Include' for source files. It'll more or less work like this from the users POV... |
| ||
| Got back to check on Money and I'm so happy what I found! The testing of this new economic model that actually seems to be working out, so happy for Mark and love the symbolic hearts! What I have read about monkey 2 sounds fantastic and the wisdom behind the new direction. I was only missing html 5 as a target and now even that is on the horizon. Looking forward to be a part of the Monkey 2 adventure and community, exciting times! |
| ||
| Will Android 3 be in there I presume Android 10 will (monkey naming) I recently got a samsung galaxy fame (4.1.2) given to me and having monkey compile to that is brilliant but doesnt work with Android 10 even when modifying the manifest. |
| ||
| Dabz: "Why is this better then, and I will say it... Over "Unity"?" Gamasutra are doing a few tutorials on Unity at the moment, using 2D puzzles as examples. Take a look at http://gamasutra.com/view/news/247099/Sponsored_Creating_a_simple_puzzle_game_in_Unity.php and see the ugly methodologies and the horrible, limited results compared to what you'd do with Monkey. (My picpuzzle banana may not be the most elegant, but it does a lot more.) Then bear in mind that the download size will be 10 Mb instead of 0.5. Can I ask: if you think this is better, why aren't you using Unity? Not knocking Unity, it can do things that Monkey can't - but for this type of puzzle it is clearly *terrible*. It's the difference between a true language, and a game creator with a built-in language. |
| ||
| Sometimes I think, maybe I'll have more success in Unity than I realize that It will take a while before they at Unity realize am an ass too so it passes and I stick with Monkey where I have already worked to achieve that goal. I realize a language will not make me successful but my talent and the ability to use resources given to me will. I have been with BRL almost since day one. I know how to manipulate BRL programming code better than any other computer language. So for me to think that I could go to another computer language and make something more successful is unrealistic. I applaud Mark for trying and not giving up. I know he will keep on making successful products and I will be here as long as he doesn't try to duplicate Python. ;) |
| ||
| But in monkey2, we can make use of the fact that we (usually) have access to the actual .h file, and can compile using it. This means we only have to get name/type right when describing extern class members. We can ignore members we're not interested in (such as funky Q_OBJECT metadata info), order of members etc. It's a whole lot more flexible and should make it possible to wrap a greater range of libraries without having to resort to glue code. YES! I look forward to this awesomeness! No point having import AND include. Why not just take the correct action based on the file extension you are importing instead? |
| ||
| The whole context of the "update" was regarding html5, which is nice an all... But here's the thing... I want to make games... Why is this better then, and I will say it... Over "Unity"? Why are you even on this forum? |
| ||
| Which brings me to a bit of good news - monkey2 WILL target html5 via 'emscripten'! Good stuff and good move, thanks Mark! |
| ||
| @Jesse: I realize a language will not make me successful but my talent and the ability to use resources given to me will Well-spoken! The truth is, making a game from start to finish is just hard work. No magical tool is going to do that for you. It's really not the tool, It's how you use It. |
| ||
| I think the truth is more like this, from Start to Finish: Case A: S---X-X---X-----X-------X---X------F Case B: S---X-------X-----X---F Case C: S--X--X--X-X Case D: S---X----- The determination of the time it needs to finish a project involves more parameters like your talent, endurance, motivation, the tools (they are important), luck, ... |
| ||
| I think what Dabz is saying here ( correct me if I'm wrong? ), is that Blitz / BRL products have always been about game creation for hobby coders who love the BASIC language ( Blitz BASIC, Blitz3D, Blitz Plus, BlitzMax ). Language gymnastics are of zero appeal. Features to aid in game creation are far greater. Mark, think back to the income from Blitz3D and BlitzMax. Both were for game creation in a BASIC language. Now move on to Monkey.. Yeah, you get the idea. From a person who actually makes real money from game creation and for others that do so I would say your Patreon donations would be a lot lot more if Monkey 2 was aimed in that direction. There are too many forum users that spout out so loudly about zippy x,y,z features which do absolutely nothing apart from sound good. I guarantee you that those donations will dwindle once the novelty has faded away. Those that make money from a product will keep paying for that product to stay up to date. If you think I'm alone in this, set up a separate Patreon page to aim more at game creation / features and see how the donations go. Great talent has already left the Blitzverse due to the current direction of things. Mark, you are an excellent language creator but please, for the love of God, remember the roots that made BRL great. This post is not for flame bait or hatred but from one single user who's bought Blitz products for game creation for over 15 years. |
| ||
| ^I don't think Mark has strayed to far from Monkey's current syntax and structure (see first post here): http://www.monkey-x.com/Community/posts.php?topic=9711&page=first I am more then willing to trade off any amount of so called "basic" conventions to gain importing a framework. In my case this makes all the difference in the world. Now if I want to include RakNet as a framework I can, import<blah> and go to it. Awesome.This in my mind is what MX2 needs to accomplish.The language is no longer handcuffed by what is developed locally (here in Monkey land) and is now is freed with access to a much wider resource base.If you are going to go large scale (say an MMO for eaxample) in your development path access to standardized frameworks is a must. This means some tweaking to Monkey's 'basic' like syntax and structure to accommodate professional coding techniques. I think anxiety over straying from a basic root is unnecessary. Monkey X2 is still Monkey only better with perhaps a small learning curve when migrating from BltzMax or the Current version of Monkey X. I have been here (BRL users/supporter) since Blitz2D and MX2 is not so far off from it roots. |
| ||
| I agree with Qube. I also agree with Richard that M2 is not that far away from M1. Problem with M1 was not the language but too many targets holding it back. I found the lack of basic and essential (in my opinion) 2d functionality(image collisions for instance) telling of this problem... That's why I am keeping an eye of the development of M2 and have not donated anything yet. I think Qube is right: I would have donated if I had known for sure that the game development parts of the language will be well taken care of. Right now, I don't, sorry. Perhaps the early version that Mark will provide will convince me. I hope so!! |
| ||
| Yeah I would like to know where we are heading with MX2 is it gonna be aimed all over the place or is it gonna be a game making language. From the cryptic posts I can see it as a be all end all language where you can hook anything in as required. |
| ||
| I'm no language guru but it sounds like the changes being made for Monkey2 will allow it to have more easy connections to 3rd party libraries/modules. Skn3 and others like them are happy because of this, which means we will start seeing more modules that support more game-related features. All the new stuff added to Mojo2 was a step in the right direction. I really think this is going in the right direction. I just hope once Monkey2 pops out on the scene, the Patreon giving will follow to a level someone can survive on. :/ |
| ||
| Edzup, like Mark has stated, it will be a general purpose language. Game specific features will have to be provided by the community. |
| ||
| I'm no language guru but it sounds like the changes being made for Monkey2 will allow it to have more easy connections to 3rd party libraries/modules. Skn3 and others like them are happy because of this, which means we will start seeing more modules that support more game-related features. All the new stuff added to Mojo2 was a step in the right direction. I really think this is going in the right direction. I just hope once Monkey2 pops out on the scene, the Patreon giving will follow to a level someone can survive on. :/ This. At the moment I have very limited time to do cool stuff like port modules. My projects folder is littered with half starts of wrapping things. With a more robust system in place, it will hopefully reduce the work load and mean more modules can be added without getting bogged down with a shit storm of glue code. |
| ||
| I think it makes sense to differentiate a little bit more between: - the language (basically the syntax features) - the compiler/transpiler (parser, syntax and semantics checker, optimizer, output code generator (translator to target language(s))) - build system (compiles the generated project/sources, link in libs/frameworks, bundle everything together - calls external tools at specific stages) - libraries (function/class collections, basically the system/framework that comes bundled with the whole package) - tools that come with the package (Editor/IDE, Debugger, Documentation Maker) If new features (for example new basic data types, function values/First-class functions, new syntax for multi-dimensional arrays, ...) are added to the language, it does not automatically have an (negative) impact in the sense that a graphics or gaming library gets removed - it's different things. Everybody uses the syntax, and I think everybody will benefit from the enhancements and additions to the core language. For the libraries, I think it will at least include everything from MX1 to start with (system libs like containers (map, stack, etc.), networking, math, ...and the Mojo/Mojo2 system). Probably adding more over time... Wouldn't it make sense to assemble a list by categories, with specific libs that are required, feature requests, etc.? Graphics, Audio, Input/Output, Sensors, GUI, Database; working with data (XML,JSON), memory, and files , etc. Last but not least, the required/included tools, and addon-tools/helpers. What are the specific requirements and expectations here, and what must be included minimum, what could be additional tools? For example an IDE, level editors, GUI designer, full RAD Studio, database designer, whatever...? The language features were already discussed at the specific topics. Maybe it would make sense to do the same at separate topics for libraries and tools. Just to discuss and collect the requirements, ideas, feature requests. To get an idea, basically. Getting an overview is not so easy, with this system. ;) |
| ||
| @Mike: ah ok so its a general purpose language :) As long as it has the same speed as C++ then I'm there :) |
| ||
| MikeHart wrote: Game specific features will have to be provided by the community. That's not what Mark said, so how do you come to that conclusion? |
| ||
| Somewhere i have read something. But maybe i am wrong. So which game related features did he confirm? Mojo2 is just a graphics and audio module. |
| ||
| I'm very pleased that HTML5 might make the cut. Also, I vote for user generated documentation and examples (possibly curated/edited by Mark or others). |
| ||
| MikeHart wrote: So which game related features did he confirm? Mojo2 is just a graphics and audio module. That is what I am asking you, and everybody else, in my next-to-last posting. What do you expect, what do you want? What is a "game related feature" to you? It may mean something completely different for every person. Do you mean a visual game maker like Unity3D, with underlying MX2-language scripting capabilities? A command like MakeGame("Tetris")? I see only spongy requests / statements / complaints / reminiscence of the past. Let's get concrete and precise! Just say what you want and expect, what you are missing - make positive + realistic statements and feature requests for the game-coder related libraries and/or tools. :) |
| ||
| I am not missing anything as I can create it myself. Game related features to me are several collision detection methods, path finding, support for different types of tile maps, bitmap fonts, maybe a buildin gui system, different types of input methods, etc etc. And most of these things i believe we will get from 3rd party libs/frameworks/etc. |
| ||
| I always saw all of Mark's products as programming languages with its own specific target base. However, each of Mark's products have also been geared to towards game development in general also. |
| ||
| @Skn3: ...without getting bogged down with a shit storm of glue code. This is common glue code for structs that I'd love to get rid of: Extern Class Foo Method Hello:Int() Property Method Hello:Void(value:Int) Property End Function CreateFoo:Foo(arg:String) // foo_t = an imported struct from another library
class Foo : public Object {
public:
foo_t _val;
Foo(const foo_t &val) : _val(val) {}
int Hello() { return _val.hello; }
void Hello(int value) { _val.hello = value; }
};
Foo *CreateFoo(String arg) {
foo_t test;
something_from_the_wrapped_library(arg->ToCString<char>(), &test);
return new Foo(test);
}Local f:Foo = CreateFoo("bar")
Print f.Hello
f.Hello = 5 |
| ||
| Thanks Mike! Being open-source, possibly many people could contribute such code parts and the lib system could grow quickly. But that also depends on Mark, what he wants to include into the core package or leave it to external libs. There also must be an agreement / consensus about the used license for the open-source project, to allow use of the libs in closed-source projects. When it comes to external libraries, many coders here have github accounts, but it's not easy to find everything. I think something like haxelib would be nice to list, install, and update external libs. 'mmm' - Monkey Module Manager. Would require a website where developers can register new libs/packages and updates for it. Or, maybe better, you can package/upload new packages directly using the module manager. With an additional GUI, users could just browse and search what addon-libs are available, read the description (maybe with optional pictures like AppStores), and install / un-install libs with a click of a button or checking checkboxes for the libs they want. Basically like some modern, visual Linux package managers, or VisualStudio addon-browser / code examples downloader. Would be much better in my opinion, instead of browsing hundreds of websites and external repositories, when using the BlitzMax module list. mmm list available mmm list installed mmm install monkeyflixel mmm install all mmm update fantomengine Could probably also be used to update MX2 itself, or at least the MX2 system libs/framework. Would save some ten-thousand users much time and make it a better experience for everyone. At the same time, it's the most easy access to new libs/functions/classes, or new example codes, addon-tools, tutorial packages, etc. |
| ||
| @Danilo I've used a few tools deployed like that. Hit and miss. Some work flawless and are entirely self contained. Download, one cmd, good to go! Others required this tool and this tool and oh yeah this tool. And then I gave up and rolled my own solution in Python. Another consideration is not everyone is command line savvy. Yes, even some coders. Especially first timer or hobby game devs who want a magic box to play with that is easy to understand. And Win is a mixed bag of what cmds are built in. Even Mac/Linux can be hit miss for differ by GNU tool dependencies. Can Monkey have a small installer hub GUI like the Android SDK manager? |
| ||
| nullterm wrote: Some work flawless and are entirely self contained. Download, one cmd, good to go! Of course that's what I meant. Forgot to say that explicitely, sorry. nullterm wrote: Another consideration is not everyone is command line savvy. I was talking about an additional GUI. I think command-line interface is nice for automation, and GUI better for browsing and accessing it as an external IDE tool. |
   |