What does Monkey actually do?

Community Forums/Monkey Talk/What does Monkey actually do?

N(Posted 2011) [#1]
I decided to take a look at the Monkey website earlier, and there's a problem I have with it.. I have no idea what Monkey lets me do. Yes, I know it's essentially a cross-compiler to other languages/platforms, and that's loud and clear. What else does it do?

So, let's take a quick look at a few of the pages I would check for information, starting with the front page:

The special compiler feature is made apparent in six different places, but I'm not really clear on what else I can do with Monkey. Maybe it's explained elsewhere..

Let's try the 'about' page, surely I'll figure out what Monkey actually does there. Behold:

Nope. Same deal here, I know what I can compile to, but still not clear what Monkey lets me do aside from target different platforms, which is cool, but what can I make that targets those platforms?

Alright, third time's the charm. Let's try the store page. Surely if I was interested in buying this, they'd let me know what I can do with it by then, right?

Wrong. Same spiel as before, target a number of different platforms to make stuff. What stuff can I make? Apps, but what kind of apps? It's obviously for games, so what kind of games can I make? Not really clear on that or the capabilities of Monkey's core libraries are (presumably that's what 'Mojo' is, which isn't telling me a whole lot).

Now, I want to make something clear, I've been around Blitz long enough to know that about the only thing these languages are useful for is games and middleware for games. The problem here is what happens when some random new person comes along and sees these pages looking for info? Well, she probably sees a lot about how it targets different platforms and.. isn't really sure what else it does. Is Monkey just a generic compiler and I have to roll my own everything? Probably not, but I'll be damned if I'd know that looking at the site.

However, I have to admit that even though I know Monkey is probably for games, I haven't got a single bloody clue about what I can do with it. I don't really have time to download the demo and fiddle around with it and try to read what I'm assuming is the traditionally lacking documentation, so what am I supposed to do here? What does the random person do?

So, the whole point of this topic was pretty simple: I think the Monkey pages need to be cleaned up and it needs to be clear what Monkey does, can do, and promises to make easier for me/you/her/him. All of the things it does, not just the compiling-for-multiple-platforms thing, though obviously leave that front and center because it's really important. Improve the about page, throw up some code examples, explain all the awesome features of Mojo, link to some example documentation in there, do something that helps explain what Monkey does for me other than compile stuff.

Last edited 2011


Jesse(Posted 2011) [#2]
it's another BlitzMax but with more complements and more deficiencies.

with a windows PC you can compile the same program "Monkey code" for GLFW, Flash, XNA(xbox and mobile Windows), android and HTML5.

with a Mac PC you can compile for GLFW, Flash, Iphone & Ipad, android and HTML5.
it uses a lot of the syntax from BlitzMax but it also include interfaces. uses a lot of the same modules from BlitzMax but a bit stripped down.

once the code is written the code is first translated to its corresponding language(for iphone & ipad it is converted to xcode c++ etc) then compiled to run under it's corresponding platform.

the language is some what limited because so far all of the commands have to work on all platforms. in that case, stuff that is specific to a certain platform or something is not stablished than its specific code is not implemented. the good thing about it, like Blitzmax, it's modular. you can add whatever you want for what ever platform as a module in it's specific computer language. the bad part is that it will only be available for that specific platform.

there are already programmers that have games on the android market and Istore. it is doable.

the language itself has a lot of potential but I feel it will be another BltzBasic, Blitz3d and BlitzMax and you know what that means.

Last edited 2011


skidracer(Posted 2011) [#3]
It's a compiler. It compiles stuff.


N(Posted 2011) [#4]
It's not just a compiler, skid. It's a package with a bunch of thingies in it that are not explained to people who would be looking to use Monkey.


.rIKmAN.(Posted 2011) [#5]
I agree with Nilium, I'm getting an iPod Touch soon with a view to developing for it and have to say there is a lot more info about GLBasic that appeals to me over Monkey (via the respective websites)


degac(Posted 2011) [#6]

Monkey games can then be run on potentially


I dont' see any 'bad or cloudy comunication' in the home-page of Monkey.

Consider that Monkey has its own website, contrary to other BRL products.

Monkey IS a new language: behind the curtain it translates/compiles the apps (mainly games, but you can see this in the left & right side of the main page the gallery's thumbnail) for the platforms mentioned.
To work you need other 'sdk-tools' (maybe this is not well explained in the store/home page, but in the help coming with the IDE there are the required info & links).

In this case an 'all-in-one' tool to download/install/setup everything should be very handy; maybe once Monkey is a little more stable a such tool will be available.

About documentation: compared to BlitzMax (and considering the continuos development factor) Monkey documentation seems very well written. Of course the perfection is not of this world.
For me I like more the BlitzMax way of documentation (the in-source is way better than the current one) - but this is subjective: the content is more important.

A little point: in the store page is not clear that you could 'change' the Monkey code writing yourself component/modules/commands. This is a feature very important that add an extra-value to the product.


So, the whole point of this topic was pretty simple: I think the Monkey pages need to be cleaned up and it needs to be clear what Monkey does, can do, and promises to make easier for me/you/her/him. All of the things it does, not just the compiling-for-multiple-platforms thing, though obviously leave that front and center because it's really important. Improve the about page, throw up some code examples, explain all the awesome features of Mojo, link to some example documentation in there, do something that helps explain what Monkey does for me other than compile stuff.


Yes, some 'links to Apps' (in the main bar there is a direct link, but for the people that dont' know what really is, this is maybe not clear).
And now there are quite very interesting app-games on the Monkey's web site. Maybe a horizontal-thumnail gallery in the store page could do the work.

Or the classic Youtube video, with some basic example and the 'output': but this is a little hard work to do (nothing impossible, just a little of time...)

Cheers

Last edited 2011


slenkar(Posted 2011) [#7]
at first i was like "oh noo nilium is being over-critical again",
but he has a point,
the website doesnt talk about what mojo IS and ISNT capable of

(i would highly recommend monkey btw)

another thing that is unfriendly to noobs is that the IDe saves code as bmx STILL, unless you choose 'all files' then it saves it as a monkey file.

Its a tiny inconvience to someone who knows what they are doing but something that will likely turn off noobs.

Also the games on the website shouldnt be called apps because that is not what they are.


MGE(Posted 2011) [#8]
yah..it's the same thing with Blitzmax really. I would certainly not call monkey or blitzmax a "game programming language". They're both capable of pretty much anything really.

But there does need to be specific modules ready to go from the start like tile engines, particles, physics, etc, etc. Sure.....like any language you can roll your own, 3rd party, etc, etc, but when it's all packaged nicely into the app from the get go, it just gives a more "complete" feeling especially for noobs who have never worked with a blitz product before.


N(Posted 2011) [#9]
I'm not trying to be overly critical, I was genuinely trying to figure out what Monkey is like at a glance and came away with just that it's for games and it compiles to different platforms. I still don't know what else it lets me do right off the bat. I don't really have enough time to sit down and give the demo a proper run, so at best I have to go off what BRL will share, which isn't much.


SLotman(Posted 2011) [#10]
A feature list of what Mojo can or can't do would be nice. I myself was surprised the other day by the 'no graphics command thread'.

I'm too (maybe) getting a 3rd gen iPod - it's on a repair shop right now - so I'm now looking for things to develop stuff for it.

Monkey would be on top of my list, but there is too few things describing it, and as pointed out, the demo on the page is not up to date with the full version.

One of the questions that pops right into my head: would iMiniB3D work with Monkey? If yes, that would be a big plus :)


slenkar(Posted 2011) [#11]
I actually agreed with your first post nilly.

If you want to know what monkey is like....its basically crossplatform blitzmax but with some things removed, and some language features added.

it has a nice fairly complete 2D crossplatform graphics and sound engine

saving and loading is limited to strings only

it has no reflection,

but otherwise its a great games programming language

it has some extra language features that dont (in my opinion) add much to the overall product like interfaces.

There are no native gui commands.

Last edited 2011


degac(Posted 2011) [#12]

saving and loading is limited to strings only


This is true only for HTML5 (and Flash? I dont'know...) - due to the browsers limitation/different approach on managing HTML5 'local session': once the standard is defined, this 'limit' should be resolved.
On the other platforms save & load should be based on filesystem(*)


(*) = I had not time these weeks to play with Monkey and with the latest release


AdamRedwoods(Posted 2011) [#13]
Monkey lacks on so many levels, but the core is robust.

Like any programming language, it is only as good as the hand that types the code.


Neuro(Posted 2011) [#14]
It's a compiler. It compiles stuff.

Actually...isn't it more of a translator since it doesn't actually compile the code but translates and exports it into different languages which can then be compiled for their respective platforms?


N(Posted 2011) [#15]
No, it's a compiler. Its target is mostly irrelevant, be it machine code, assembly, or another language, as it's compiling the source into something else (as compared to something like preprocessing, which should take the source language and spit out something in the same language). If the output is an intermediate format, it's still been compiled into that form.

Going by your logic would make almost all existing compilers into "translators" (ignoring that they're pretty much the same thing). Most C compilers preprocess and spit out assembly for another tool in the chain, for example. Does that make them something other than a compiler? BlitzMax does the same thing, but nobody has trouble calling it a compiler either.


SLotman(Posted 2011) [#16]
In order for it to be a compiler, it must generate (after everything is processed) a binary in byte-code, or at least, change the code into a low level language.

Monkey is a language translator, not a compiler. For clarifications, read this.


N(Posted 2011) [#17]
it must generate (after everything is processed) a binary in byte-code
Incorrect, the Wikipedia article you've provided also backs up what I'm saying in its first line:
A compiler is a computer program (or set of programs) that transforms source code written in a programming language (the source language) into another computer language (the target language, often having a binary form known as object code).



Matty(Posted 2011) [#18]
saving and loading is limited to strings only


This is not such an issue really...since all a file is really is a string of bytes...you just have to know how to read it back in....


Yasha(Posted 2011) [#19]
In order for it to be a compiler, it must generate (after everything is processed) a binary in byte-code, or at least, change the code into a low level language.


This is absolutely 100% wrong.

The difference is incredibly vague, but it's mostly based around the amount and manner of transformation: if the original code is transformed in a text-based way, it's a translator; if it's converted into an AST and then human-readable-source is reconstituted from that AST, it's a compiler.

The idea that a compiler has to output low-level assembly is intellectually offensive, and if Wikipedia says otherwise, change it: it is wrong. (The Mighty Wiki actually just says "usually called", which implies terms of convenience, which is perfectly OK.)

There is no logical reason at all why the nature of the output should determine whether something is a compiler or not. Compilation is the process that took you to that output.

/rant

Last edited 2011


MikeHart(Posted 2011) [#20]
Who the feck cares if it is a compiler or a translator. It does it's job (what ever it is) damn well.


EOF(Posted 2011) [#21]
I prefer to think of Monkey as a multi-language development tool. Monkey itself 'only translates' code. For compiling it needs the help of "separate tools". In summary, Monkey is a multi-language translator.
Case closed.


*(Posted 2011) [#22]
Its more of a translator that translates your code to the relevant platform for compilation with the desired tools


ziggy(Posted 2011) [#23]
Well, technically, it is a multi-target compiler, as it tokenizes the source code, builds a complete AST representation of the source (that's the compilation) and then produces the output document(s). In this particular case, the output document is readable, and we could considere this a way of translation but... what if I add an assembler target? and additionally, what if the assembler target targets a VM? or even worse, what if it targets a high-level virtual machine like Jazzmin or the net IL assembler?

The fact that it is a compiler depends on what the tool does. The trans tool compiles the source code (it has an intermediate representation of it) and, additionally, produces readable output. I would call this a compiler that has readable output targets, so it can translate source code as the result of the compilation process. It's done in the same way other compilers produce assembler source code or vm bytecode (like the java compilers).

Last edited 2011


Azathoth(Posted 2011) [#24]
Monkey reminds me of haXe

Last edited 2011


JKP(Posted 2011) [#25]
I kind of agree with Nilium - I am left wondering what the real capabilities of Monkey are. The Zombie Trailer Park app is the only Monkey game I have seen that I have been genuinely impressed by. But as far as I am aware, the source code is not available which kind of defeats its purpose as a demo.
What's more, I haven't been able to find any demos of native PC/Mac apps. I think that Monkey is probably a good product but BRL need to do more to demonstrate its abilities.

[Edit]It seems that the example apps have improved recently. After searching for some time I found a game called 'WitchBlaster' that has multiple versions available including a PC version. I'll have to try it later.[/Edit]

[Edit]I think the single biggest question I had after I went through the site for the first time was 'Can it do 3D on the PC/Mac/iOS platforms?'. I gather that the answer is no, even though it is using OpenGL. But it took me quite a while to find out.[/Edit]

Last edited 2011


GfK(Posted 2011) [#26]
The Zombie Trailer Park app is the only Monkey game I have seen that I have been genuinely impressed by. But as far as I am aware, the source code is not available which kind of defeats its purpose as a demo.
Its not a demo, its a game in its own right that happened to be created with Monkey.

What does Monkey actually do?
He eats bananas. And goes "oo oo oo" a lot.


JKP(Posted 2011) [#27]
Its not a demo, its a game in its own right that happened to be created with Monkey.

OK true, it is a game in its own right, but I assumed skidracer made it partly for the purpose for the purpose of demonstrating the product's capabilities.

The point I am making is that I would like to see a convincing and reasonably complex demo with source code so I can see whether Monkey genuinely makes the whole cross platform thing easy or not. Monkey might be cheap but I have so much software I have bought and not used that I am getting more and more cautious.


Mr. Write Errors Man(Posted 2011) [#28]
I agree with Nilium as well. I never went through the trouble of trying to dig out information about the actual capabilities of Monkey, as the information wasn't readily available on the website.


Blitzplotter(Posted 2011) [#29]
Now, I want to make something clear, I've been around Blitz long enough to know that about the only thing these languages are useful for is games and middleware for games.


That is a bit of over-simplification. I'm using Blitz3D for something that is not a 'game', more of an application to view running data from a Garmin GPS training device in 3D as opposed to a 2D graph plotting speed & heart rate - just one example of something being created that is not a 'game'.

convincing and reasonably complex demo with source code so I can see whether Monkey genuinely makes the whole cross platform thing easy or not. Monkey might be cheap but I have so much software I have bought and not used that I am getting more and more cautious.


That is a fair point, I've a similar problem - of which I've exacerbated by taking on a job which involves cutting my teeth in ASP.Net, javascript and PHP. I have every type of Blitz product to date bar Monkey.

Monkey does appeal to me - I have not digested all the details from the Monkey site. I suspect it has similar attributes to its stable mates. I cannot see why apps could not be generated by Monkey instead of just 'games'.


Yasha(Posted 2011) [#30]
I cannot see why apps could not be generated by Monkey instead of just 'games'.


There's actually a pretty simple reason for this, and it's the same thing that affects most cross-platform technologies:

In the grand scheme of things, a graphics engine is a relatively easy thing to design with the same features for multiple platforms. You deal with drawing primitives, the details of which are defined by the user's art assets, and you either take control of the whole screen, or you open a simple graphics window and ignore what's going on outside. The same game will usually look the same on multiple platforms if it had access to the same high-level graphics API.

"Apps", however, require an actual interface. And unfortunately every single operating system has a wildly different idea of how this should work and even the basic philosophy behind it. The base themes are different, the standard button layouts and sizes are different, the standard ways dialogs appear and are controlled are different, even what gadgets you can actually use are different. Go and grab any GTK application for Windows to see this effect in action.

Your options are: use a common simplified subset, and have your app look equally awful and handle equally badly everywhere; use your own interface, and multiply the amount of work you have to do by ten as well as getting automatically disqualified from all the App Stores for ignoring style guidelines, and ignored by users for being unintuitive; or write a different interface each time and lose the cross-platform advantages.

There's no reason you couldn't use it to create applications of any kind, but the advantages that make it (and e.g. BlitzMax) good for games simply don't apply in that field.


EDIT: I am exaggerating, by the way - obviously Java has made a solid reputation for cross-platform app development. It also has a solid reputation for producing really ugly GUI applications though: it can be done, but doing it well is a great challenge. Java has the advantage of one of the biggest class libraries known to humankind, whereas Monkey ... doesn't.

Last edited 2011


Neuro(Posted 2011) [#31]
Java has the advantage of one of the biggest class libraries known to humankind, whereas Monkey ... doesn't.

But then again, Java has a 15+ years head start over Monkey.


Blitzplotter(Posted 2011) [#32]
or write a different interface each time and lose the cross-platform advantages.


Not if its only the interface element you have to re-write. The meat of the app that does the under the covers functionality need not be modified - So, okay the 'multi-platform' element may not lend itself to UI (it could do - I haven't tried yet) but the meat of an app should be able to remain intact. Maybe.....

Power to the Monkey!


D4NM4N(Posted 2011) [#33]
Nillum has a point.
Problem with monkey is is that it has not sold me. I have no idea if it can use the "stuff" from the various platforms or if at the end of the day it is just a canvas with some cool graphics commands for drawing on, purely for games and nothing else... Also the lack of proper debug, call stack and stepping makes a lot of these type of things more time consuming than just bashing out a native verision imo (at least when a multi-skilled team is involved). ...and I have seen seasoned programmers reduced to ranting wrecks when they cannot debug.

Where we are at, it is actually easier to have 4 guys 2 android and 2 ios guys ...(and all experienced in c++/c# so if winmob ever erupts like a pussy boil we have it covered too)... to "make something" than work with "translators" and "halfway houses" - and we have tried -many- of them from titanium to mono. While the app's core code is easily converted, mapping for the different APIs is the tricky bit.. but is where we all come in, in different ways using wrappings and interfaces.

Not meaning to rain on any parades, i am sure for normal 2d games monkey is great, but my "scope" goes further than just graphics. For example i may want to write a game that reads GPS coords to generate levels or uses a mapview oe webview in some way. Or simply my bread and butter, which is writing functional apps for companies, academies and other institutions to do what they want it to do.

These kind of questions are not clear at all and could ultimately confuse. I am trying to give an outside voice, of course the primary scope of monkey is for games, but it is misleading.

Last edited 2011


ziggy(Posted 2011) [#34]
@D4NM4N: The point of Monkey is that you can write and combine Monkey source with target native source very easilly, so you would have to write only the target specific code for each platform (I'm thinking on your GPS comment) while you can maintain a common Monkey source code to safe lots of dev time. You can create classes that act like "drivers" for native classes, that's one of the strongest points of Monkey but this is not advertised as it's not exactly what average indie game coders may be interested in...


SLotman(Posted 2011) [#35]
Can Monkey render stuff 'offscreen'?
Even something like blitzmax pixmap.paste()?

I just got an android 2.2 tablet, a really cheap one (this one, I guess - but I didn't bought it there), with very low performance (but it can run angry birds, so...) - I'm worried that without offscreen rendering, I won't be able to do anything properly for this device :/

PS: is there any Android game/demo made in Monkey I could test to see how well it will perform?

Edit: I can't download stuff from Android Market... apparently, this device comes with a Chinese Android Market, which has almost nothing in terms of games - so if anyone has some link, please post a direct link to an apk or something :(

Last edited 2011


xlsior(Posted 2011) [#36]
The "not being able to download from Android market" is a pretty common problem with the no-name chinese knock-offs.

In order to offer the Android Market, the developer needs to sign (and pay for) a hardware manufacturing license with Google. Without it, they aren't authorized to include google's integration tools like gmail, market, maps, etc.


SLotman(Posted 2011) [#37]
Hah! I actually "fixed it", and now not only it has the android market, but it's also even a little faster! =)


Neuro(Posted 2011) [#38]
What did you do to fix it? For the price, i may actually consider getting these cheap knock off for Android dev. Not sure about having to use the stylus all the time though..


SLotman(Posted 2011) [#39]
There are some Android versions called Uberdroid, which you can 'flash' into the device, removing all chinese junk, and leaving an original Android installation.

Took me a while to get everything working (wireless was a pain), but now it's all good =)

Well, as good as it can be, apparently the device has no 3d acceleration what-so-ever - I don't even know how Angry Birds can run so well on such device...


SLotman(Posted 2011) [#40]
...and now I know it - just had to forget about OpenGL and code everything using plain Canvas in Java - now I can draw a hole tilemap-screen and get around 30 fps :P~

Since Monkey uses OpenGL, I don't think it will perform any good on this device - something I just verified downloading some of the demos made with it on the Android Market :/

Last edited 2011


Neuro(Posted 2011) [#41]
Took me a while to get everything working (wireless was a pain), but now it's all good =)

But are you still forced to use that stylus for everything on it?

apparently the device has no 3d acceleration what-so-ever - I don't even know how Angry Birds can run so well on such device...

Well Angry Birds is 2D using physics lol :). Actually i was playing Angry Birds on the Motorala Xoom and it wasn't quite as smooth..


Yasha(Posted 2011) [#42]
Going back a bit to games vs. apps, I read this short article: http://theschemeway.blogspot.com/2007/03/erlang-or-gambit-ctermite-practitioners.html

...and immediately thought that if you swap "Scheme" for "Monkey" and "Erlang" for ...any big-name big-language, probably Java... you'd actually have a pretty good breakdown of why so many people say that Blitz and Monkey are "only for games", or at best also for rapid prototyping.

(Note the perspective, by the way: the author, Dominique Boucher, is a big name in the Scheme community, but you have to recognise problems where they exist.)

It's perfectly true that Monkey (or Scheme) can be used for large business applications, but you have to lay a lot of the groundwork yourself and there's not much to fall back on if anything goes wrong. Which leads me to this:

But then again, Java has a 15+ years head start over Monkey.


...and I very much hope that Monkey grows outwards and develops a bigger set of core libraries, because it deserves to catch up. Although the other thing is intention: the developers have to be interested in providing other kinds of library, too. I hope they are.

the meat of an app should be able to remain intact. Maybe...


Really it depends what the "meat" is. Many desktop apps have most of the code in the UI front-end and the database back-end and there's not actually that much going on in between. We (people with at least a little game design experience) exist in an unusual side-space where we can see that there's a lot of potential for interesting new app ideas that have a powerful, UI-independent core similar to the way games are structured, but this doesn't really apply to the majority or even a reasonable group of general applications. Good news for us at least!

I think I've long since stopped making a relevant point... oops.


SLotman(Posted 2011) [#43]
But are you still forced to use that stylus for everything on it?

Nope - just my greasy fingers ;)
(Really, the device doesn't even come with a stylus!)

But, performance aside - Monkey, as far as I can see, have just one big drawback: not being able to debug (or even step) the code. Without this, being able to hunt down a bug after writing tons of code... it's a nightmare.

Not having modules for everything doesn't bother me - but the lack of a debugger (being able to stop the code, watch values, etc) is vital.

And Monkey being a translator makes everything more difficult when implementing a debugger - it's not like code is translated on a 1-by-1 scale; a "drawimage" on Monkey could mean several lines of Java, or Obj-C.

Of course, you can debug in the generated target code - but then, it defeats the reason to use Monkey altogether.

Too bad, I was really looking forward using Monkey for iPhone/Android development :(

Last edited 2011


Graythe(Posted 2011) [#44]
Edited out...

Last edited 2011


Blitzplotter(Posted 2011) [#45]
@Yasha:-

We (people with at least a little game design experience) exist in an unusual side-space where we can see that there's a lot of potential for interesting new app ideas that have a powerful, UI-independent core similar to the way games are structured, but this doesn't really apply to the majority or even a reasonable group of general applications. Good news for us at least!


I think that is a reasonably good point ;)

And as for:

...and I very much hope that Monkey grows outwards and develops a bigger set of core libraries, because it deserves to catch up. Although the other thing is intention: the developers have to be interested in providing other kinds of library, too. I hope they are.


I agree entirely! I confess I have purchased all of Monkey's stable mates to date and their products allow indie coders to achieve what would normally only be achievable by groups of individuals. Monkey has not been on the streets long, I for one will be voting with my readies and purchasing a copy next month.

Last edited 2011