Is Monkey on-par with Blitzmax?
Monkey Archive Forums/Monkey Discussion/Is Monkey on-par with Blitzmax?
| ||
| I know somebody's going to jump straight in and go "no, it's BETTER!" - but it's only better if it meets my needs. After my current game I'm going to have a go on the mobile market and haven't fully decided what I want to use yet. I'm leaning towards Monkey because of the familiarity, but last time I tried it for a major project there were many shortfalls and I always felt I was trying to put a square peg into a round hole (and it *will* go, but only if you hack off the corners!). With that in mind, I'd also like to be able to stick with Monkey/whatever else I choose if I go back to the casual market at any point in the future. I recently set up a limited company and am now 100% full time, so I don't want to have to waste 90% of that time trying to figure out something completely alien like GLBasic or haXe if I can possibly avoid it. I haven't used Monkey for about 20 versions now (other than dabbling with Box2D recently). How is it for "must have" features on Windows/Mac required for casual games? Specifically: 1. Ability to change screen resolution. 2. Switch between windowed/fullscreen. 3. I presume still GL, not DirectX? 4. Querying folder locations for stored data. 5. Capturing window events; move, close, minimise, maximise etc. 6. Any support for changing app icons. 7. Decent file support (last time it was LoadState() only, which was a pain) There's probably more but that's all I got off the top of my head this morning. |
| ||
| Well I am sure you already know, but you can compile with the blitzmax target so have the best of both worlds? Not sure when it will get updated to monkey v69 though? 1+2) http://monkeycoder.co.nz/Community/posts.php?topic=4418 this is not uptodate yet but I will be looking at it at some point as I need it myself. 3) GL yes, the win8 target appears to use dx11 4) not built in 5) would be easy enough to add this to a custom target. 6) not built in 7) check brl.filestream module |
| ||
| A few things come to mind these are: 1) networking is there to a fashion but no hosting servers written in monkey 2) the filestream module is platform specific there is no definite file system thats there on all targets and the loadstate and savestate is the only cross target solution |
| ||
| BlitzMax has: + "Batteries included" for just about everything you need for desktop development + Good filesystem support + A large code and userbase - Requires dynamic linking to be expandable beyond its built-in limitations Monkey has: + A more mature language syntax and coding convention than Blitzmax + A toolkit with what you need to get started on mobile development + Most of what you need for cross-platform mobile development + Does not require dynamic linking to be expandable; can use static-linked code on any native target * Somewhat less-mature filesystem support (but still able to do everything you'd probably need as of ~v64) - No built-in event capture, but not locked to an operating system - A very small code and userbase |
| ||
| I would suggest you to considere using the BlitzMax target for Monkey for Desktop development, so you can take advantage of the better language, and at the end you have a portable game that can later on be compiled for Android, iOS, etc. And at the same time, you can later fine-tune window position, icons, etc on the BlitzMax target before final release on BigFish or any other portal (if that's your current scenario) |
| ||
| My worry with doing that, is that I would have to add in certain things *after* creating the Blitzmax project. If I need to modify the original Monkey code later, I would have to add all of that stuff into the resulting Blitzmax code again. |
| ||
| Gfk brings up a good point that it's time for the desktop platform on Monkey to begin its maturation. perhaps a bundle of code mods and presented to Mark for inclusion to monkey standard? the built-in filesystem seems ok to me, what more do people need than what's listed in the OS or brl.filestream module? You use FileType(path$) to check for the existence of folders or files. 6. changing icons: someone had a little tutorial on this, but this is a need for monkey. it's not difficult since GLFW looks for the GLFW_ICON resource (windows). |
| ||
| I've said this before: * BlitzMax for Desktop * Monkey for Mobile Monkey is no where near ready for the casual market. I've built a GLFW exe, it ran on the development PC but when I copied it across to my test rig it didn't run at all (even after putting OpenAL dll on it too). And that's why I created (with help!) MonkeyMax (although it needs updating...) |
| ||
| Any word on when monkeymax is gonna get an update? |
| ||
| * BlitzMax for Desktop * Monkey for Mobile Agree. For Windows/Mac/Linux desktop, there is no better tool than Blitzmax, IMO. Monkey's GLFW target is nowhere near as capable. I often "step back" to BlitzMax, especially when I need to code a little utility/tool (eg, batch jpg processor, file parser, audio generator/processor, data encryptor/decryptor etc). For casual web or mobile games, however, Monkey is great, especially when used in conjunction with a third party framework (eg Ignition) or engine (eg MiniB3d). |
| ||
| Any word on when monkeymax is gonna get an update? Not for a while, I'm pretty busy with my new game and I haven't even looked at Mark's new target system. I still believe we will still have to "hack" trans to pick up the target... |
| ||
| still have to "hack" trans to pick up the target... yes. hopefully there will be a better way soon. overall, i didn't find the new target system difficult. |
| ||
| Do you think that Monkey will ever be good enough for desktop games? Does MonkeyMax currently work with the latest version V69 or is it unusable for now? |
| ||
| My worry with doing that, is that I would have to add in certain things *after* creating the Blitzmax project. If I need to modify the original Monkey code later, I would have to add all of that stuff into the resulting Blitzmax code again. The way to do this properly would be to add the blitzmax native stuff using import. Use BlitzMax as a Monkey module and that's it. No worries. nothing to be rewritten. That's the joy of Monkey. |
| ||
| Do you think that Monkey will ever be good enough for desktop games? It depends on your requirements. Right now it will create an OpenGL Windows and Mac game, or a DirectX windows game, which you need to expand to enable normal windows functionality (maximise, full screen etc). Does MonkeyMax currently work with the latest version V69 or is it unusable for now? Nope MonkeyMax does not work with v67 onwards, it is usable on v66. |
| ||
| I've built a GLFW exe, it ran on the development PC but when I copied it across to my test rig it didn't run at all (even after putting OpenAL dll on it too). Oddly enough, I've done the same thing (on many different machines) and GLFW worked perfectly on each one (except for my dev machine). And all i had was the OpenAl.dll in the game folder - didn't even install it. Matter of fact, most of the time it would even perform better than BlitzMax target. But the main downside is that you actually have to install OpenAl for sound/music and inability to control windows functions (or can you now? Thought i saw a thread on it). The main issue i have with GLFW target is that it runs sporadically on my dev machine, and of course the OpenAl thing. Which is why i ended up using the BlitzMax target instead. |
| ||
| @EdzUp[GD]: networking is there to a fashion but no hosting servers written in monkey ...why on Earth would you write a server in Monkey? o_O @Nobuyuki: - Requires dynamic linking to be expandable beyond its built-in limitations.... + Does not require dynamic linking to be expandable; can use static-linked code on any native target I don't think you quite understand "linking" in the traditional sense. Blitzmax and Monkey can both support static and dynamically linked libraries. It's generally as simple as choosing static or shared when you configure the Makefile. Either way, you will still need to write native glue code. The difference is that Monkey requires you to write it for every target you want to support. Blitzmax only really has one target (maybe minor tweaks for Linux/Mac). @therevills: I've said this before: * BlitzMax for Desktop * Monkey for Mobile +1 @AdamRedwoods: Gfk brings up a good point that it's time for the desktop platform on Monkey to begin its maturation. @impixi: Monkey's GLFW target is nowhere near as capable. Agreed. The GLFW and XNA targets are subpar at the moment. I wouldn't even consider releasing a desktop game built with Monkey, as much as I love it. |
| ||
| ..why on Earth would you write a server in Monkey? o_O For LAN games, you can write a server in BlitzMax that listens for connections, sorts packets and sends them to the relevant clients. This cannot be done easily with bog standard monkey, what I would like to see is more done on the network side of things to allow this seeing as it supports Windows, OSX, Linux it would be nice if we could create servers within monkey itself :) Agreed. The GLFW and XNA targets are subpar at the moment. I wouldn't even consider releasing a desktop game built with Monkey, as much as I love it. +1 Its about time all targets were brought upto par. |
| ||
| I'm about to start work on a desktop game and I am still undecided about whether to use BlitzMax or Monkey. The biggest draw back with BlitzMax is the lack of 64bit support, which in the long term maybe an issue. Monkey seems more tempting in terms of of long term support, but the state of the desktop targets also worries me slightly. Thoughts? |
| ||
| Monkey doesnt have any problems building for Windows, OSX, or Linux I use it on them quite often. One thing I would say though is use MinGW as I have had nothing but problems from the VC++ route (this could be a Vista thing or it might not but for me it wouldnt install no matter what I did always stopped at 80%). |
| ||
| I would go with Monkey. I would only use BlitzMax as a Monkey target. |
| ||
| I want to release a commercial PC/Mac game later in the year and I really want to use Monkey to do it, so I'm really into having it as close to BlitzMax as possible for PC/Mac exes. GfK's list and OpenAL support would probably solve most of the issues. BlitzMaz took a lot of tweaking/upgrading back in the day to get commercial quality titles but now it's great. I think it's essential for Monkey to be upgraded so it can be a professional solution for commercial desktop games. |
| ||
| GLFW3 is coming and the maintainer has done a great job. 64bit and shared contexts are coming, very soon. This will help the desktop targets reach those levels. https://github.com/elmindreda/glfw |
| ||
| I still think the format thing is a pain, having different formats for different targets is annoying at best |
| ||
| I would add to GfK's list the ability to stream Sounds/Music. A bit like maxmod for BlitzMax. |
| ||
| Like many others I'm also undecided which one to use. I don't have much to say, other than that I wish Windows had a solid target available. If I have to go OpenGL there has to be some real benefits compared to the likes of LibGDX. |
| ||
| I tend to disagree with poeple saying Monkey is just for mobile development. I am currently using it for making a commercial online game using websockets which is targeted first for desktop. To be honest i had way less problems with desktop dev using XNA than mobile. Also? Everything is working properly (ok i had to make my own input system for xna but this wasnt monkey fault plus there at the momment a little bug with reflection i have to send some code to mark for this but adding the files to the filter have fixed the problem). About GWFL you cant copy the openal32 directly i found out you had to install it with the installercto make it work on other PCs. Anyway sure there isnt much UI lib atm but this is a question of time and to be honest jungleide is going rather well. I use a modified version of challenger gui which is really awesome not that i didnt want to use jungleide but this was simpler for my need and really fast but jungleide will definitivly be awesome in a near futur. Monkey is really a powerful solution the language is solid if your a oop addict like me. :) So no i disagree you can stillcmake things awesome with xna even if it dead.. it doesnt mean its crap or cant work. |
| ||
| @Rushino: You meant JungleGui, don't you? |
| ||
| Yes sorry mixed the terms. :) also be warned i wrote this on a mobile devicenvery fast so i am sorry for any mistakes or bad grammar. |
| ||
| I think Monkey is almost there. I just hacked GLFW, so: - I can switch from window to fullscreen mode; - Window is created already centered (instead of first being created, then centered) - Set (manually) app title (just a matter of wrapping glfwSetWindowTitle) The only things missing in my opnion: - Icons (on Window and even on taskbar) - loadstate/savestate should write on appropriate folders, not where the EXE is. And maybe, *maybe*, load stuff from (password protected) zip files, so we can protect our media on desktop. But - here's the thing: some publishers (like GameHouse) don't want games in OpenGL on Windows (just look at their requirements pages, it's there), so a DX target (without XNA) is important. |
| ||
| so a DX target (without XNA) is important. Is there any specific reason for a target not requiring XNA?I still think best desktop target on Windows is BlitzMax as a target. If you consider this, Monkey is on pair with BlitzMas to the point that Monkey can be used as a driver for BlitzMax. So, yes, definitively on pair |
| ||
| Well the problem with XNA (only one i know of is the fact that microsoft abandonned it) |
| ||
| Well the problem with XNA (only one i know of is the fact that microsoft abandonned. Abandoned as in not new released of it to be done. But it's still compatible with current hardware. I supose they're going with a C++ windows 8 mode for their next gen console as they're doing with Windows 8 Pro, Windows 8 RT, windows 8 Phone. They've brought DX to it. Time will tell... |
| ||
| But anyway win8 target is supported in monkey plus you can run them like win7 apps in windows 8 (as seen somewhere) so it doesnt really matter. |
   |