About Monkey 2 › Forums › Monkey 2 Development › Monkey 2 concerns
This topic contains 55 replies, has 15 voices, and was last updated by
Mark Sibly
1 year, 10 months ago.
-
AuthorPosts
-
May 25, 2017 at 9:52 pm #8257
UPDATE: Wow okay… this thread turned into something I want no part of.
Good call locking this thread Mark.I’m a bit concerned about the future of Monkey 2.
And I figured I would voice my concerns for the rest of the world.I’d like to start with saying that I love Monkey 2! (maybe not the name, but whatever heh)
It’s fast become my number 1 language.
And the only reason I’m spitting out all this negativity is because I want the best for the language.But with that said, I’m also worried about Monkey 2.
First of all.
The most basic application you can make, a simple console application, produces an almost 2mb big Exe.
Now, that might not sound like much…
But if you compare to something like BlitzMax, which I’ve used for many years, you’ll quickly see that 2mb is huge!
And It’s not like BlitzMax is especially optimized in that part either, I’ve used other languages that produces even smaller Exe files than BlitzMax.
I can make an entire game in BlitzMax, stick all the images into the Exe, and still get away with a smaller Exe.
If you want any kind of graphics in Monkey 2, you’ll have to use Mojo.
Mojo adds a bunch of DLL files that together are 7mb, and bloats your Exe to 4.5mb.
And then there’s the asset folder with fonts and shaders, which adds another 1mb.
So that’s over 12mb, without any of your game assets like images and sounds.
And let’s say you want some sweet Gui action, well that’s MojoX!
MojoX blows your Exe up to 6mb, plus the new theme assets.
So we’re talking 15mb for an empty Gui application heh.
The standard IDE for Monkey 2 is 22mb.
The standard IDE for BlitzMax is 850kb.Secondly!
In BlitzMax, you could pack stuff into your Exe.
And I really think Monkey 2 should do that.
Not only for the default shaders and fonts, which you could still replace if an assets folder was found or when compiling.
But also for the DLL’s needed, along with a default theme for MojoX.
I’ve just made a simple application for viewing some files, and it’s a bit sad having to include 4 DLL files and an assets folder for such a small application (small but still over 15mb! haha)
For iOS an Android, this might not be needed though.
Heck, even Mac might not need this feature.And finally…
The compile times are pretty bad.
Once again I have to drag BlitzMax into this, but BlitzMax just sorta blinks and it’s done.
But for a smaller application in Monkey 2, it takes 10-20 seconds.
And I’m the kind of person that tests every line of code I write, so there’s like 90% waiting time for me when using Monkey 2.Are these things known issues.
Will this improve over time?May 26, 2017 at 5:41 am #8258I have absolutely no concerns about binary sizes. This has changed over the years. Monkey still produces lightweight binaries, just do a comparison to Unity for instance and you know what bloatware is.
So to me it sounds your only concerns about the future of Monkey are compile times and binary sizes?
Oh I wish those were the only ones for me…
So here are my concerns:
1) Another split of the community made things worse.
2) No clear roadmap, no direction, lack of communication (well that’s nothing new I know)
3) What is the future, what is when Monkey 2 is considered to be finished? Will it be abandoned like Monkey 1? Will it be maintained?All I(!) want would be just a clear statement, either:
Yes, I will do my best to maintain Monkey (1,2,3,…) and keep it working. (This is especially important for the fast changing mobile SDK stuff!)
or
No, I won’t maintain Monkey (1,2,3,…) as soon as it’s finished.
That’s it. I just need clear communication. So can I use Monkey 2 for future mobile projects for the next 5-10 years or not. Look, I’m at a point where I moved from Hobby stuff to “real” business and that’s why I have to be able to plan ahead. And I only can plan ahead when there is a minimum level of communication.
I doubt I’ll get an official answer here, sorry for being that rude. But I never ever got a clear answer anyway.
May 26, 2017 at 5:58 am #8259I definitely agree about the final binary size. and compile time could be much better if possible.
May 26, 2017 at 9:04 am #8262Binary Sizes
I haven’t put on thought on binary sizes before. The most worthless mobile phone (where you can get for 80 bucks) can have 8GB of memory these days. On the other hand dedicated PC gamers or PC professionals could have 16GB of RAM. For example on Windows 8.1 I open the task manager and I see 74 processes and 904 threads running on idle, and I use only 3/12GB of memory. I could guess that I would be able to run 90 games at the same time of 100MB each, to reach up to 9000MB. But you get the idea, my point is that technically these are manabeable file sizes for the current computer systems.
Just for proof, “CrossCode” (a PC game) in my drive is about 178MB and an Unreal4 tech demo is 38MB (with the other binary libraries adds up to 78MB). Practically people already execute big executables without even noticing, chances are that if you don’t tell them they won’t know.
___
Packing Stuff
Perhaps Blitzmax doing so, was done as a design choice back then, I have never used Blitzmax though. However if you consider what other game engines do, is that actually they use a Virtual File System. The most obvious VFS is a protected zip file but it’s the easy and lazy approach. Other than that, there could be some C based VFSs that would be wrapped easily in Monkey, perhaps even someone could create a custom VFS for Monkey. My point here is that packing can be managed either with a VFS or a third party tool (binary merge if the size is reasonable).
___
Compile Times
Actually how Blitzmax worked was conceptually different than Monkey 1 and Monkey 2. I am not a compiler specialist, but having browsed the repos a bit, I noticed that Blitzmax, generated assembly code directly, which explains the small file sizes and the fast compile times. Monkey2 on the other hand generates actual C++ code that is later on compiled to a binary application with the help of the standard g++ compilers. If you really mention that g++ compilers suck and are awfully slow you are right, but this is something we can do nothing about, because that’s how the universe works.
___
No Clear Roadmap
Perhaps that would help for communication purposes and to be in tune with the project, a Trello board would be a good idea. Although some information are mentioned in the blog, perhaps they are not in plain sight and need to be searched. Now, if there’s a way that the community would be able to make wishlists and vote for the best features (uservoice.com) this would make sense as well for communication purposes, how to connect development and requirements.
May 26, 2017 at 10:23 am #8267Mine are more community related and support related, personally I dont mind the language changes those I can learn “IF” and when I decide to make the move and start projects in Mk2.
- The Name.
- The Second (Face Palm!) Community Split
The Name is stupid, plain and simple, it’s got near zero search ability, sorry but looking for monkey code I do not and am sick of seeing pictures of the little monkey riding the baby piglet, sure its cute but its not what I’m after, not to mention the fact that 90% of the people I talk to hear the name and you can actually see the light in the back of their eye’s switching off its really fkn frustrating .
The First community split should have been all the evidence that mark needed to show that a second one was insanity, what’s that old Einstein quote “Insanity is repeating the same thing and expecting different results”.
Bottom line I am not getting into mk2 because its name sucks, its community is freaking tiny, like stupidly so small its mostly the same people posting every day, that’s not a community that’s a club, and a small one at that, and I have lost all faith in Marks ability to make good decisions when it comes to monkey’s future or the communities future..
May 26, 2017 at 11:08 am #8269Devils’Advocate
1. about size: probably some better results (if any and if possible) should be gained in future if the ‘translator’ will analize what modules are not needed (don’t know if it does this already or not)
2. Included resource: this could be a very handy solution … and maybe a VFS or similar the perfect thing, as I suspect many will be worried about the risk of cloning 3d models etc
3. compiling time: a consequence of point @1.. and maybe some different compiler (in time) could improve this.
The only big problem is community: if MX2 community doesn’t get big it could rise a ‘lack of interest’ in Mark…
May 26, 2017 at 11:14 am #8270In summary then, areas of concern so are (in no order)
1) Roadmap of the product. Where is Mark taking it, what’s the milestones and what new features does he want to include/old features he wants to clean up? Is there a v3 planned? etc
2) Compile times speeded up.
3) Binary footprint size.
4) The brand name “Monkey”.
5) One central community hub, no more splits.and i will also add:
6) Better documentation.
anything else? certainly with regards to items 6 & 4 we can help as a community. for items 1 we can pitch ideas to Mark, and he can tell us if they are doable or what obstacles exist in getting them done. I love Mark (in a fraternal brotherly shao-lin monk way that is!) and i want his efforts to have a wider audience appeal, I want this to be the go-to product for producing working games/apps and prototyping stuff as a POC and also a way of learning coding. It shouldn’t just be about having a snazzy GUI based system (unity, godot etc) but also an academic interest in understanding O.O concepts and typing into an IDE. Thats’ my friday rant over. Thank you for indulging me! I’ll shut up now!
May 26, 2017 at 11:23 am #8271Unity and Unreal may produce bigger Exe’s but Monkey 2 certainly is no Unity nor Unreal heh.
The new DOOM game is over 70gb, so I guess it’s fine as long as Monkey 2 stays below that? hehe
I still get away with doing the same advanced (if not more) stuff in BlitzMax as I do in Monkey 2, and it still produces smaller Exe files.
Infact, even the new BlitzMax version that builds for iOS and Android produces smaller Exe files than Monkey 2!Things like this is what a lot of people, and especially my nerdy friends, look at.
They’re already laughing at me for making a file viewer that’s over 20mb big and full of loose files. >_>And don’t get me started on when I tell people I code in “Monkey 2”
I’ve certainly had a few times where I tell people about the language I use and they’re really excited, until I mention its name.
I usually try to just call it “M2” if I can get away with it.
That’s what the file extension should have been imo., either “.m2” or “.m2s”.
And I’ve suggested this before, but I think “Prime” would have been a good name.
Every module could have been called Prime* too, so like “PrimeUI”, “Prime2D” or “PrimeAL” for OpenAL.
The logo could have been a Prime knot:

Heck, even “Gorilla” would have been a better name heh.
..sick of seeing pictures of the little monkey riding the baby piglet, sure its cute but its not what I’m after..
That had me laughing heh.
About supporting Monkey 2 in the future…
I think that was the whole reason for going with this Patreon thing.
Mark can continue to work on Monkey 2 for as long as people support him on Patreon, he doesn’t need to worry about sales or anything like that.
So I believe the idea is to continue on Monkey 2 for as long as he can.But yes, Mark should very much say so himself, instead of us having to guess these kind of things.
Coders are mysterious creatures though, not very social and not very good with communications.
Mark needs some sort of PR/Community guy.
It doesn’t help that he spreads his tiny bits of information on Twitter and YouTube but never on the Monkey 2 blog.I would LOVE to fix up Monkey 2.
I’d gladly shape up the Monkey 2 hompage, set up a proper community etc.
I’ve tried to help before, but I’m not sure so sure it’s a high priority for Mark.There certainly are a lot of other issues with Monkey 2.
Like the documentation for example.
I still don’t know what image formats Image.Load and Pixmap.Load accepts!
And it shouldn’t be this hard to find stuff like that in the documentations.
That’s something people also look at when they find a new language – is the documentation any good?The community will probably grow as Monkey 2 grows.
If Mark manages to get this new 3D engine going on all platforms and with good performance, along with a forward renderer and VR, I think the community will grow quit a lot.
But at the moment, the community is very much lacking.First impressions are SUPER important, and Monkey 2 sadly doesn’t give a good one.
The name.
This web page alone isn’t super inviting.
Community forum is empty (or just me asking stupid questions heh)
Try to download Monkey 2 and you’re linked the most basic itch.io page ever.
Plus it comes with the standard IDE, which doesn’t give the best impressions either.
Look at documentations and they’re really lacking.
etc. etc.
I figured Mark (or someone) would polish things like that later though, after the 3D engine perhaps.
But I’m not so sure anymore.May 26, 2017 at 11:37 am #8272The Primary issue you have right now is that a) Mark likes the name and b) Mark does not give a toss what we want or think, he’s making this tool because he enjoy’s making it and he feels no pressure to bow down to peer or financial pressure so the chances of him taking any of this on board are slim to none.
May 26, 2017 at 12:10 pm #8274I know over the years I have been critical of some areas of BRL’s business model and products BUT to be honest some of us are still here.
For me the whole thing is a bit to early to speculate on, I would not actually say it’s v1 as all the features that are needed for the whole experience aren’t present yet. Once everything is in there then we can speculate on it :). I do agree that past languages do not do Mark any favours as there are loads of disgruntled coder there and to be honest does give a negative image as well.
I would really rename Monkey to Blitz so it’s BlitzX2 which does give a more BRL language thing and no more renames the next just becomes BlitzX3. Version control is just a . version so it would be BlitzX2.0.1 etc.
I really would like to see this one be a success it’s all down to Mark where it goes but jumping from core coding to 3d just because he needs the cash doesn’t help matters as there is still loads of the core that needs polish to make it shine.
May 26, 2017 at 12:45 pm #8275If you guys would like to talk more, I’ve got a room for Monkey 2 setup on IRC @ freenode.net #monkey2
Here’s a quick link: http://webchat.freenode.net?randomnick=1&channels=%23monkey2
I suggest using a proper IRC client of some sort, like XChat, mIRC or if you’re on Windows 10 – xoChatMay 26, 2017 at 1:45 pm #8278I’ve been checking back here for months in hopes of some miracle occurring, but the reality of it is that there isn’t. It’s impossible for one man to create a language that supports the number of platforms that Monkey 2 does in both 2D and 3D as well as maintain the docs, marketing, demos, etc. It’s an impossible task. The Greek god of Sisyphus comes to mind.
Worrying about silly things like the name and such are irrelevant, when the lack of documentation, community, examples, and a decent road-map are more pressing. And moving on to 3d before many of these essentials were completed is just poor management. Like many developers, myself included, Mark enjoys the coding over polishing and finishing a product. Documenting and creating examples is not fun. But you do it because it has to be done. It has to be done in order to attract new users which is what is desperately needed here.
Monkey 2 has more of a hobby feel to it, than a business. The main reason there’s any money coming in at all is due to many small small donations from people who have used his products from back in the day. I had Blitz Basic for my Amiga 500
But I can’t imagine too many new people donating when there is so much uncertainty and lack of direction. Rare blog posts and random tweets aren’t enough.
Mark has more serious programming skills, but I’m afraid that isn’t enough nowadays for such an ambitious project like Monkey 2.
gasmonso
May 26, 2017 at 6:38 pm #8279Valid points but look at AGK, it’s a one man show as well.
And Mark has shown that he can handle it.
May 26, 2017 at 8:17 pm #8280May 26, 2017 at 8:35 pm #8281Well i’m optimistic about monkey2
I’ll be writing TimelineFX 3D with it, go Mark!
Regarding the name, ever since I read Influence by Robert Cialdini (hint everyone should read this book!), I’ve been fascinated with cognitive science. Did you know that when you do someone a favour, they feel overwhelmingly obliged to return the favour. It triggers an instinctive reciprocation.
Whats that got to do with the name? Well, Marks attachment and unwillingness to let it go it is well known, and lot’s of people are every unattached to it. It’s become this big “issue”. So if Mark were to say: “hey personally I really like the name but as it doesn’t seem too popular I’d like to consider other ideas for the benefit of the community”? Everyone would want to reciprocate with ideas and support. I do think that the name is a beast that needs to be slane, a community re-branding project would be quite galvanising.
-
AuthorPosts
The topic ‘Monkey 2 concerns’ is closed to new replies.