This page was last modified on 21 May 2016, at 23:34.
|Paradigm||multi-paradigm: structured, imperative, object-oriented, modular, reflective, generic, concurrent|
|Designed by||Mark Sibly|
|Developer||Blitz Research Ltd|
|Stable release||0.86(E) / 02.02.2016|
|Typing discipline||Static, weak, strong (optional), safe, nominative, partly inferred|
|Platform||Windows, OS X, Linux|
|OS||Microsoft Windows, Mac OS X, Linux|
|License||zlib, proprietary (commercial)|
- 1 History
- 2 Target platforms
- 3 Compiler
- 4 Preprocessor
- 5 Using native code
- 6 Modules
- 7 Games development
- 8 Disadvantages
- 9 Programs written using the Monkey
- 10 Sample code
- 11 Links
The language was developed by Mark Sibly — founder of Blitz Research Ltd. He is known to some developers for such tools creating games as BlitzBasic, Blitz3D и BlitzMax. Monkey is an evolution of the previous line of the Blitz Research Ltd products. Cross-platformity is achieved by translating. All that Monkey compiler can — is checking and translating code, collect valid platform project, and run native tools to build applications. In this regard, for the assembly of the final application, you must install the SDK for all required platforms. Thus, it is possible to avoid the use of different launcher and plug-ins to run the final applications. It looks as if the application was written independently. Of course, the translated code is not easy to read and not always optimal, but at the same time it gives you all the benefits of native development.
- Mac OS X
- PlayStation Vita
The compiler is written in Monkey. But it was an intermediate stage when the compiler was written in BlitzMax. The source code for the compiler is fully open source, therefore, if necessary, you can modify and recompile it into a Monkey, using the target platform Stdcpp (standard C++).
Monkey uses a simple preprocessor for the separation of specific parts of the code for different platforms, the installation of additional configuration settings and to include or exclude blocks of code depending on the build configuration.
Using native code
To write a platform depend code it could be used native for the platform language. Using the Extern directive, classes and functions can be included into Monkey code, using specific features of the platform. It gives an opportunity to expand the functionality of your application almost without restrictions.
Language capabilities can be expanded by using modules that can be written on the Monkey and on the native language for the platform.
Monkey comes with the following modules:
- monkey (Basic language features)
- brl (a set of classes and functions for streaming)
- os (module for use with the operating system)
- dom (module for DOM-tree HTML-document)
- mojo (2D-framework)
- opengl (module for use with the OpenGL)
In addition to the list, developer community has been written more than 20 add-on modules, including ports of different physics engines (Box2D, Chipmunk и Fling), GUI-systems, modules for working with fonts, modules for the implementation of IAP (in-app purchase), module for use with the XML, JSON and various services.
Mojo module that comes with the Monkey is used for games development. This module provides developers a cross-platform API for working with 2D-graphics, sound and input devices. Features of the framework is somewhat limited and it is connected, first of all, to the need to support multiple platforms. Not all features are available on a single platform are available on another. If some feature is not available on at least one of the platforms, it will not be included in mojo.Of course, it is somewhat radical. But at the same time, you can be sure that your application will work properly on all platforms.
The second reason for such modest functionality - easy to add new platforms. Technologies rapidly changes. New devices and operating systems appear. For this reason, the possibility of rapid addition of support for the new platform provides a distinct advantage over other similar tools.
Of course, functional mojo is not enough to write a complete game. After the game - it's not just work with graphics, sound and input devices, but also the user interface, various states, animation, physics, and more. Unfortunately, this is not mojo. But here comes a game frameworks, and other modules created community Monkey.
- Diddy.One of the most popular frameworks for Monkey. In addition, directly framework, it provides a lot of additional functionality.
- FantomEngine. Creator of the framework is the author of «Monkey Game Development», which examples were made by using fantomEngine.
- Playniax. The only commercial framework, but with good reviews. The author is the developer of the eponymous framework for BlitzMax.
If your goal is to create a 3D-games, ypu should use the opengl module (does not work on all platforms) or framework minib3d.
Monkey has its disadvantages, like any software.
This is probably the most serious problem - the lack of a normal development environment. Despite the fact that Monkey supplied with two IDE (Monk and Ted), none of them can not be considered complete. Writing major projectson them is rather problematic.
To solve this problem, you can use a commercial Jungle IDE (there is a free lite-version) or one of several plug-ins for popular text editors. However, the problem with IDE, unfortunately, remains one of the key.
The lack of supporting tools
Most professional tools for creating games come with a level editor, sprites, animations, etc. You will not see such tools in Monkey. There are only the language, modules and IDE.
Here comes third-party software, as paid and free. Usually, to make the import of projects from these instruments is not big problem. Besides, if you look at the official forum, you can find ready-made solutions, such as the import of texture atlases from TexturePacker, import of tile maps from Dame and Tiled, etc.
HTML5 mojo version uses 2D-context, which affects the performance of games. Unfortunately, WebGL not supported in IE. And if some feature which is not supported, it is not used at all.
To remedy this situation, you may want to use an experimental patch for mojo - Mojo HTML5 GL, which replaces the 2D-context on WebGL, which gives a significant performance boost.
Programs written using the Monkey
- Zombie Trailer Park — Flash and iOS
- Pirate Solitaire — iOS, Android and Flash
- Jet Worm — iPhone and iPad
- Blotty Pots — Android, iOS, WP7
- New Star Soccer Mobile — Android, iOS, Flash and HTML5
#Rem This example relies on the 'mojo' module, so it will not compile with a non-game target. Mojo comes with all versions of Monkey X, and is implemented for most targets. Classes and functions such as 'Image', 'App', 'LoadImage', and 'DrawImage' are provided by Mojo. NOTES: * Knowing Java or Visual Basic may help you learn Monkey. * Multi-line comments are described with the preprocessor ala "#Rem". * Single-line comments are represented with apostrophes. (Similar to Visual Basic) * Variable-naming standards are generally user-dictated. * Monkey is statically typed, however it does support automatic type resolution. * 'End' may be used to end a scope, however, specific forms of 'End' may also be used for clarity. ("End Method" for example) * Monkey's compiler is generally "multi-pass", so the placement of elements does not matter. This can also lead to different stylistic choices, such as placing fields at the end of classes. * This is a modular language (Some Java parallels can be made), however, Monkey uses files to represent modules, not classes. This example uses a class because it's dictated by Mojo. Monkey is also not strictly object-oriented, however, it does fully support polymorphism, and similar strategies. * This example uses spaces instead of tab-characters for the sake of consistency, such practices are discouraged in realistic applications. #End ' This will enable strict-mode. (This makes the compiler less lenient about code structure) Strict ' Imports: ' Import the standard Mojo module. (Required for this example) Import mojo ' Like several C-like languages, but unlike most BASIC languages, ' Monkey uses the 'Main' function as an entry point. Function Main:Int() ' By simply creating a new 'Game' object, the application will be started. New Game() ' Return the default response to the system. ' Zero: No errors found. This is system specific. ' This point may or may not be reached when the application closes. Return 0 End
' This will act as our main class. Multiple inheritance is ' not supported in Monkey, however, interfaces are. ' The 'Final' specifier works similarly to Java, and is not explicitly needed. Class Game Extends App Final ' Fields: Field player:Player ' Methods: ' These override the 'App' class's methods (Your own methods may also be written in this class): ' Though, technically 'OnCreate' is a method, some consider it a type of constructor, and may label it as such. ' 'OnCreate' is called automatically when an 'App' object is created. Method OnCreate:Int() #Rem Most media should be stored in a folder called "ProjectNameHere.data". The 'LoadImage' command will load an 'Image' object from the path specified. Mojo assumes that what you're loading is in the "ProjectNameHere.data" folder by default. Variables, especially local variables may also use the ":=" operator, in order to use automatic type deduction. #End Local img:Image = LoadImage("player.png") ' Alternative: Local img:= LoadImage("PathHere.png") #Rem Create a new instance of our 'Player' class using the image we loaded. As you can see, 'player' is a field, and because of this, an implicit use of 'Self' can be assumed if there is no name conflict. People familiar with languages similar to C++ would know this pointer/reference as 'this'. Monkey is garbage collected, so there is no need to deallocate this object from the heap later on. #End player = New Player(img, 100, 100) #Rem This will set the update-rate to the rate we specify (X times per-second). This update rate is also implicitly applied to the draw/render rate; however, uses of 'OnRender' are target and system defined, and are therefore decoupled from the main update routine. Setting this to zero will result in a system-defined update-rate. Doing such a thing will hint to Mojo that it should attempt to make this application update and render, as many times as possible. #End SetUpdateRate(60) ' The return values of the 'App' class's commands are currently placeholders. ' Monkey's documentation advises that you return zero by default. ' Returning can technically be optional under certain conditions. (Not always recommended) Return 0 End #Rem The 'OnUpdate' method is called automatically several times per second. The number of times this is called is based on the update-rate. Mojo is generally good about implementing fixed-rate behavior, it will attempt to update the application more than render if profitable. This does not "save you" from the use of delta-timing, or similar techniques, however. #End Method OnUpdate:Int() ' Add '1.0' to the player object's 'x' variable. ' Adding ".0" to the end of a literal can be used to ' explicitly describe it as floating-point ('Float'). player.x += 1.0 ' If the value of 'x' exceeds the number we specify (In case a literal), set it to zero: ' This could also be done using 'Mod', the modulus operator. ' (Represented by '%' in several C-like languages) If (player.x > 100) Then player.x = 0 ' Once again, 'Self' is implicit. Endif ' 'End' could also be used here, instead. ' Everything went according to plan, now return zero. Return 0 End #Rem The 'OnRender' method is usually called as many times as 'OnUpdate', however, this is system and target dependent, the update-rate is used as a hint for this, not a demand. For this reason, having any code that mutates "in-application" data is considered variable and in some ways non-standard. Normally, all graphical/drawing operations must be done in here. However, a non-standard target-dependent way of rendering in 'OnUpdate' can be done using the 'BeginRender' and 'EndRender' commands. (Not recommended) Actions such as loading resources should be done in 'OnCreate' or 'OnUpdate'. #End Method OnRender:Int() ' Clear the screen, then display a color based on the values specified(RGB, floating-point). ' Explicit usage of ".0" is not needed here, as there is no integer overload. ' An alternate overload may be used, which clears the screen using a system/Mojo defined color. Cls(32.0, 64.0, 128.0) ' Call our 'player' object's 'Draw' command. ' In the event that 'player' is 'Null', this will throw an error. player.Draw() ' Everything went according to plan, now return zero. Return 0 End End
' The 'Player' class, as referenced previously (Placement does not matter): Class Player ' Declare all of our fields (Class-local variables): ' These two variables will act as our position on the screen. ' (Alternatively, an 'Array or third-party class could be used) Field x:Float, y:Float ' This will be a reference to an 'Image' object we'll specify. Field image:Image ' Constructor(s): ' Overloading 'New' mainly works the same way as constructors in other languages. ' Returning is generally not recommended for constructors. Method New(img:Image, x:Float=100, y:Float=100) ' Due to the arguments using the same names, 'Self' ' is required to resolve our fields' names: Self.image = img Self.x = x Self.y = y End ' Methods: ' This will be our main render-method for this object: Method Draw:Void() ' Draw the 'image' object to the screen using our 'x' and 'y' fields. DrawImage(image, x, y) ' Returning in a 'Void' function is not required. (Some still recommend it) Return End End