Beginner's thoughts on Monkey
Community Forums/Monkey2 Talk/Beginner's thoughts on Monkey
| ||
| (Long post warning) Hi, I'm not sure who is the target audience for Monkey 2 is, but I'm gonna assume here that Mark wants to keep it somewhat simple and accessible for beginners. I consider myself a beginner (I learn programming in my spare time), so I thought that maybe I could provide some valuable feedback about my experience with Monkey so far, and how it can be improved with Monkey 2. Here are the outstanding things for me: 1. Documentation I know it’s hard for Mark to maintain the documentation by himself, but it’s really one of the weakest spots in Monkey. I’d like to make a suggestion here: maybe provide the basic documentation, but then crowd source it? If there’s a an easy, centralized, web-based way for people to contribute to the docs (code examples and tips & tricks are the most obvious things I can think of), and any contribution that’s upvoted ends up in the official docs, and gets distributed with the next release? Sounds like a good way to leverage and nurture the community at the same time. I’d be more than happy to contribute to a system like this, since I feel that posting code in the forum gets a little lost in the noise sometimes. 2. Standard modules Despite being a simple language, there’s a surprisingly steep curve in getting a simple, but professionally made, small game in Monkey. The language itself is not the issue, sifting through the options, and sometimes having to reinvent the wheel, is. There are a few free and commercially available modules that will help you get up and running, but it takes quite a lot of trial and error and, combined with the fact that most of those “feel” different from Mojo, it can be really slow to achieve something that’s not super basic if you’re not a pro already, specially when you consider other paths like using Construct or a similar editor. I’d love to see Mark including some basic libraries that would ease this burden, things like a standard Vector module, Polygons (with collision methods), maybe a simple scene graph and entity system? Nothing too fancy, just the basics so people could take it and extend to their likings, confident that performance will be good and other people will be familiar with the design style. For instance, people could assume an entity system is in place when creating a fancy Physics module, and it would be easy to incorporate this new module into other people’s projects. In a perfect world, these modules would approximate creating a simple scene in B3D out of the box: create some entities, define their appearances and collisions, add a little code that updates their placements and, voilá, a simple interactive scene is created . 3. Better IDE or good integration with popular IDE’s out of the box Another obstacle when learning Monkey is that you constantly have to switch to the Docs to figure out the most basic things, like the parameters in a function. Having an editor with proper autocomplete can be a big help when learning things. I’ve tried many IDE’s available for OS X, and the autocomplete is either non-existent or half broken. Support for other code editors is also half-broken (I tried using Sublime text for a while, but gave up and am using Mollusk now). 4. Branding Minor one, but man, “Monkey-X 2” is a nearly unmarketable name. Since “Monkey” is cute but doesn’t really work well with internet searches, how about a unique name that’s still related to simians? I’d vote for “Monki” - that’s monkey in japanese! Sounds even cuter, would be a somewhat unique brand in the western hemisphere and “Monki language” would work much better in searches. Anyway, those are my shiny two cents. Cheers! |
| ||
| I should preface my response by saying that I've been here for about 3 years, and I love what Monkey does right. What it does wrong is another story. As far as Mark's following, I'm probably one of the youngest, but one of the most interested. I started with Blitz3D as a kid, and BlitzMax not long after. I've moved past BlitzBasic, and also see BlitzMax for the great step it was. However, I also see where the issues were, and exactly why I had to learn languages like C++ as soon as I did. 1. Documentation: The documentation is open source, it's just not the best system. It's a variation of markdown, which is nice, but it's not quite as feature-filled or even structurally sound as most would want. A lot of times, you end up having to use HTML tags anyway, and there's no easy way to load examples. I do like the module sub-folder approach, though. It lets you maintain your own docs for your modules. It's not a fun process, though. 2. Standard modules: As for a standard library, Monkey 2's already boasting much of Monkey 1's 'brl' library, as well as C bindings. I don't think Mark should maintain everything, though. With features like 'Struct' and the like, this does make a number of things simpler. This is especially useful for math. What we really need is a module manager of some sort, and perhaps have it integrate with git. With something like this, you could have a manager that lets you clone different git sub-modules recursively from a repository. For example, you could have one repo for community modules, and have things like Diddy and my own modules in it. This way, people could manage their modules either through individual repositories, or through one repo. As for scene-graphs and the like, I think we just need to supply the tools, and how to use them. Unless Mark intends to go all-out on this, we're probably going to be the ones who work on it. 3. Better IDE: Jungle's a great IDE, and will hopefully be updated for MX2. Other than that, there's few existing IDEs that do a good enough job. Although, better access of the pipeline would be great. That seems to be Mark's sentiment moving forward as well. Personally, I find Ted 2 terribly unfinished, and I wish Mark would stick to something more effective like QT, GTK, or even WX. This would be a great way to showcase Monkey 2's external language support, but Mark seems to think that it would be a better feat to write it all in Monkey 2. Very quickly, I think he realized just how that works out before having an actual debugger. Ted 2 seems to be the plan, though. I'm unsure if I'll use it, but it's happening. 4. Branding: We aren't in the days of branding anymore. We just need to use the product and talk about it. It's not commercial, although some parts (Modules) may be in the future. You aren't going to get the people who want to make the higher level portions of games with a product like this. The fact is, I'm a fan of building a good game engine, but everything above that is just an excuse for me to program. The fact is, if all your language can do is make 2D games somewhat quickly, then you're missing people like me. There's a reason the original Blitz products didn't resonate with me, and that's because they're isolated and are so intertwined with things like graphics, that even the build system depended on it. They weren't modular, and everything was just built in like operators. There's a reason people used to like the no-parentheses syntax. With Monkey (And even BlitzMax), you're dealing with a language with so much potential for general programming, but it's slated towards games only. This is why the C++ Tool target in Monkey is great, and why people liked BlitzMax's module system. People don't just want a game language, they want a programming language. They want the tools to make games, but to also be able to do the things other languages do. Monkey takes influence from languages like C and Java, languages that are used to make just about anything. This is why I like Monkey 2's direction. It's trying to be a full programming language, not a game programming language that needs to touch other languages to work. Sure, you need bindings, but the intent is to make that as simple, or even as automated as possible. Not only that, but it also gives people the control needed to work with external code directly. The number of problems with doing this in Monkey 1 is staggering. You've got stability issues, undocumented classes, ABI issues, no pointers in any sense, no stack-based storage, no temporary references, a GC that needs an overhaul, an awful build system (Anything but JS), and a lack of community support and bindings because of these issues. This is why Monkey 2 should succeed. Because it won't be a specialized product. It'll allow you to write something like Mojo by wrapping DirectX or OpenGL yourself. You'd be able to write the code that Mojo has in native files, but with Monkey 2 itself, adding to its portability and accessibility for users. If Monkey 2 can do this, then not only is it on par with languages like Java, but it also has many of the benefits Monkey 1 had. On top of this, it would heavily attract the BlitzMax crowd, and everyone who knows the Blitz name in the industry. Not because of its name, but because of its capabilities and scale. I'm glad Mark's looking into technologies like Emscripten, because it means Monkey 2 could not only stand as a modern language, but also a future language. A flagship for new technologies like ASM.js, and the promising work behind the "WebAssembly" tech. Honestly, I don't care about the name, or the brand, I care about a good product. |
| ||
| My 3 cents... > Documentation First up, whatever happens, the 'raw' docs will remain in source, ala javadoc. Speaking as the dude who will be writing 99% of the docs, it's just too much of a headache to do it any other way. I would also love some kind of 'online doc comments/contribution' system, but who's gonna do it? I suck at web coding and I know from experience it can be a huge time sink so this will have to wait until I can afford to fund something or someone volunteers to do it. > Standard modules I do agree there should be more in the standard modules, esp. the geometry stuff like the Vec2<T>, Vec3<T> etc classes so I plan on moving these to either std or their own module. Polygon classes etc would be nice too. I was also vaguely thinking of doing a simple 'SpriteView', that provided 'sprite versions' of image, rect, text etc, eg: ImageSprite, TextSprite, RectSprite etc. > What we really need is a module manager of some sort, and perhaps have it integrate with git. Totally agree, although I think git integration is overkill at this level (in the IDE would be nice though). What I've been vaguely thinking about is something like: * Add a 'modules/sources.txt' file that contains a list of source URLs. People can edit this to add new module sources to the module manager (or edit it in module manager). * Each URL returns a JSON file that contains a list of modules available from that source, along with url/version/dependency/checksum info etc for each module. * Each module is shipped as a simple 'zip' file that gets extracted into the module tree. These zips can be stored in a 'backup' dir for rollbacks etc. These source.json and module.zip can of course themselves be stored in a github repos... > Better IDE or good integration with popular IDE’s out of the box Ted2 *will* improve - it is still barely more than a GUI test, but the end result should be a considerable improvement over Ted1! Integration with other IDEs is something I feel is best left to 3rd parties, as there are people out there with way more experience at customizing sublime, atom, etc than myself. > Branding I'm still 100% fine with Monkey2, but regardless, the thing that's gonna make or break an open source language like monkey2 is what people actually do with it! |
| ||
| @marksibly: Regarding the module manager idea, that doesn't sound bad. It's kind of like what some JS projects do on GitHub, Ace for example. In this case, it's a separate release repo, but it could also simply be its own branch. From the look of it, NPM uses JSON as well, so maybe that's a good model to follow. The big problem I have is that I maintain my modules using git sub-modules, meaning each module can be maintained separately. This makes version control a lot simpler. I'd be willing to ship in a separate repo, though. GitHub already generates zips on demand, so that could work. When I brought up git integration, I was more so talking about running the basic command-line stuff. Things like pull, clone, and recursive cloning, which is really simple these days. You may be right about leaving this up to IDEs, though. I imagine Ted 2 is going to be open source anyway. |
| ||
| .. |
| ||
| Thanks for the thoughtful replies! Just to clarify, I really like Monkey, and came back to it after a while experimenting with other languages and tools. But I do think that despite its simplicity, it has a higher entry barrier for beginners compared to other solutions out there, and that these issues can be addressed. ImmutableOctet, I agree with everything you said. But your view is the view from an experienced developer, and what I was talking about is much, much dumber stuff like getting stuck on "how do stacks work again?". I do believe that things can be made easier for beginners without compromising the appeal to more seasoned programmers. Those goals aren't mutually exclusive! Mark, unfortunately I suck even more at web programming, otherwise I'd help! I wonder if there's an existing solution for that out there that could be easily integrated into the main website. One thing that would have helped me A LOT in the beginning would have been more code snippets and examples right there in the docs, along with their explanations. Yes, I know how much work that would be, which brings me to... Honestly, I don't care about the name, or the brand, I care about a good product. Wise words! But a more successful Monkey language would benefit everybody involved, and maybe even result in some budget that could be used to simply pay people to fix some of those issues. Things like branding can go a long way. I agree, though, priorities are priorities, and this is not one. (But you have to admit, Monki would be a super cute unique name! :-) With that said, I'm happy that so many talented people are involved with it. Keep it up! |
| ||
| On the crowd sourced documentation front, has anyone checked this out: https://readme.io/ Seems like it could be helpful I also wonder if there's any Github based documentation solution, where people can merge different contributions, etc. Cheers! |
| ||
| > This is why Monkey 2 should succeed. Because it won't be a specialized product. I wonder if this is true - there are a lot of other general programming languages already which also have cross-platform support (Haxe comes to mind). What will Monkey2 do to be more popular than those? |
| ||
| @mark I would also love some kind of 'online doc comments/contribution' system, but who's gonna do it? I suck at web coding and I know from experience it can be a huge time sink so this will have to wait until I can afford to fund something or someone volunteers to do it. I have the feeling that i'm going to make the online doc maybe :) Working as a webdeveloper (php/mysql/nodejs/javascript/html/css) for many years and really want a only doc for monkey... I will contact you later... |
| ||
| @ratking: When I say success, it's relative. As long as people use the product, and aren't held back by its shortcomings, then I consider it a success. When Monkey 2's a mature product, it should be able to do what the language sets out to do. For example, interoperation with native libraries, concurrency, and control of memory. I think you're looking at this a bit backward. Monkey 2's not a commercial product. It doesn't have to match up with or best existing products, it needs to not impede a user's progress, just as the others don't. It's about constant improvement and application, not comparison. With a mature version of Monkey 2, I shouldn't have to count it out as an option, just because I can do the job in C++. I should instead be able to compare the two on their individual pros and cons, and make a decision then. Sometimes the choice could be even simpler. Maybe you just like the language's aesthetics, or implementation of certain concepts. Maybe you know one language better than another, and are more comfortable using it. When there's so many factors, and we're just talking about a side project, you can see why specialization can be bad. Usually the choice is a lot simpler, say, to learn the language in question? You could just be fed up with the problems of one language, and would rather try another. Perhaps you wanted to try a different dialect (BASIC), or you wanted insight on an idiom or design pattern (Functional for example). How about insight in a language's design choices, or library features? I know I looked at some talks about Go when I made this module. Nothing's perfect, and people have preferences. I for one love C++ as a language, but hate much of its build-system. If Monkey 1 had improved this aspect, as well as the flaws holding back my particular project, as Monkey 2 may, then I'm more likely to use it. Case in point, I created a program that synchronizes input events between computers. I was originally going to use Monkey, but because of its shortcomings, I chose C++. If Monkey 2 was out, I would have likely used it instead. Not all of the project could be done in Monkey 2, but the parts that wouldn't be could still work with it. Obviously, Monkey 2 wouldn't have been perfect, but neither was C++. Want to know what language I first used for that when I knew nothing about the topic? BlitzMax. Want to know why I implemented MD5 in Visual Basic? Because I wanted a perspective of the dialect. There's just so many variables, and that's fine, but there's a reason why programming languages aren't a big market. We live in an age where anyone could make a language, no matter how good or bad it may be. Some may stick, and others might not, but if the software fits the bill, then it might just stick around. I guess the main idea I'm trying to bring across is that people will use a language that can do what they want. Even if one language does something better, they may still choose the one they're familiar with. Likewise, if they see something they like made in one language, they may be inclined to try it. That could be Monkey 2, or it could be C. People still use Python for things they could have written in another language, but they use it because of its strengths with their project. Python has benefits like portability and interpretation. This could be a better fit for some people, just as Monkey and Monkey 2 have their benefits. It's all about the user's preferences, and that's why variation is the spice of life. |
| ||
| > I think you're looking at this a bit backward. I don't, you misunderstand me. I am not against more languages. I just hope the popularity will grow enough so there will be a big enough community which provide more modules and alternatives to modules. I used Monkey-X for a few days now, and I'm not a great programmer who wants to create his own game framework and so on... so it's really frustrating when I just can't find enough documentation for a module, or when providing feedback on git or so doesn't get me any response, because the developers don't care (anymore). A big community only can be good in this regard, and I think nowadays specialization can only be helpful. It helps to set a focus, and make it clear to people what Monkey2 is for and can do, and why they should use it and not something else. |
| ||
| Hmmm, never cared for the name and I also think it has nothing to do with the succes or potentional lack of it but I have to say I like 'Monki' ;) |
| ||
| Hmm i doubt that monkey2 qualifies as a beginners language. Partly it is but partly it is not. Monkey already didn't qualify because there were too many holes (people stumble already about the collision detection, no proper docu, a lack of comfort zones) and it's less forgiving than other languages, like for instance Max. Man, Max had this direct punch (fire it up, ctrl+n, code, hit compile and *boom* it's running). According to his posts Mark seems to be aware of quite some issues. Except the syntax/online stuff i like the route he's trying to go. I like to think of it as a focused tool which enables you to do certain stuff more easily/quickly and with joy but being easily understood/used isn't its major point too. I like the focus on being a game focused language but that it can be used for other stuff as well. It would be cool if modern 3d could happen (soon). Partly subjective but i think that a good name makes a difference, you wouldn't want to call it iMonk, well, maybe someone would. |
| ||
| FWIW Monkey is just a name, over the years I have used: C/C++ ASM Fortran Cobol Delphi Builder DarkBasic PureBasic Sinclair Basic Commodore Basic My point is simply they are all names that signify what your coding with just so others know you use it, my gripe would be it doesnt matter what its called as long as it does what you want it to do and when. |
| ||
| Do you have any kids? If so, would you also call them Commodore Basic and Dark Basic? A nice name is fun to speak and listen to/to write and look at. It can make you smile and motivate you. Nah, nice names are important. Some names can also tell you something about the products. |
| ||
| Well, to be honest (I don't want to offend :P) http://monkey2.monkey-x.com is ... an horrible URL to remember/write/read! And you missed the 'x' in monkeyX2 (just kidding). I know you need a 'space' without spending other money to host the progress about MX2 In any case it seems that (1) and (2) are quite 'defined' (even in the roadmap), so I don't worry about them too much. (1) will take some times to be completed... we need to learn to wait :) (3) (IDE) in my opinion *should* be the base element (0 in this order) as its represents the first impact for the user... I would prefer to invest time on it than in documentation: this could be completed in the future and/or forum/wiki/online/offline etc solutions could fill the gap in the time. About the name/branding... I would call it FROG (frogX or froggy..). it's shorter :) (I know we were losing our time speaking about the brand :P) |
| ||
| My 1 cent... > What we really need is a module manager of some sort, and perhaps have it integrate with git. Totally agree, although I think git integration is overkill at this level (in the IDE would be nice though). What I've been vaguely thinking about is something like: * Add a 'modules/sources.txt' file that contains a list of source URLs. People can edit this to add new module sources to the module manager (or edit it in module manager). * Each URL returns a JSON file that contains a list of modules available from that source, along with url/version/dependency/checksum info etc for each module. * Each module is shipped as a simple 'zip' file that gets extracted into the module tree. These zips can be stored in a 'backup' dir for rollbacks etc. These source.json and module.zip can of course themselves be stored in a github repos... This is great but really only half the battle... and the less important half IMO. Why are Atom, Linux, Unity, MSCode, Gamemaker... so easy to expand? They a have central formalized location to "publish" extensions, modules, enhancements. We as programmers need something that's easily browse-able to find the modules in the first place. Mark's module tool should really only need 1 url which is fully and officially supported by Mark himself. Though it doesn't matter who writes the backend. Preferably it would be a repository[file host] as well so remote changes don't alter link status... Preferably again, it should be part of the monkey2 site or at least linked to from there. Maybe, once you "install" a package it would then add it's url to sources.txt. |
| ||
| How about Gorilla-X? |
| ||
| > Mark's module tool should really only need 1 url which is fully and officially supported by Mark himself. I think this is quite easily achieved. The default '/modules/sources.txt' file would contain something like: http://monkey2.github.com/...blah.../modules.json And that's it. The modules.json file is at a fixed location, and contains the 'root' set of modules. It is fetched each time module manager is run and can itself contain more module sources. The initial modules.json file might contain something like:
{
"desc":"Blitz Research Modules",
"modules":[
{
"name":"monkey",
"shortDesc":"Blah..",
"longDesc":"Blah..",
"md5":"blah..",
"version":"1.0",
"author":"Blitz Resarch",
"destDir":"/monkey/",
"sourceURL":"http://monkey2.github.../monkey.zip"
},{
"name":"lib",
...etc...
"destDir":"/lib/",
"sourceURL":"http://monkey2.github.../lib.zip",
"dependancies":[
{"monkey":"1.0"}
]
},{
"name":"std",
...etc...
"destDir":"/std/",
"sourceURL":"http://monkey2.github.../std.zip",
"dependancies":[
{"lib":"1.0"}
]
},{
"name":"mojo",
...etc...
"destDir":"/mojo/",
"sourceURL":"http://monkey2.github.../mojo.zip",
"dependancies":[
{"mojo":"1.0"}
]
}
],
"sources":[
"http://diddy.github.../modules.json"
]
}
The "sources" array at the end means the module manager would 'see' not only the brl modules, but also whatever modules are listed in diddy.github's modules.json file...and any sources listed in those sources etc. I don't need to maintain the diddy modules.json file at all, and only need to modify the brl modules.json file to 'add' more modules or more module sources. In addition, by leaving sources.txt modifiable users can add 'experimental' modules to their config that may not be quite ready for primetime and are therefore not reachable from brl, diddy etc modules. Publishing a 3rd party module is a little involved I guess. You need to: * Upload a zip of your module somewhere. * Upload a modules.json file that describes the module and references the zip. * Instruct people to add the URL of your modules.json file to sources.txt. Module manager could provide a 'Add Source' option for this. Meh, not that bad, and once people have your modules.json in their sources.txt, you can publish any changes quite easily. This is all actually loosely based on my meagre understanding of apt-get and linux repositories, and one thing that is VERY useful with linux is the ability to add 'foreign' repositories that may contain packages not supported by your distro. I don't think this is the right place to be using git - in fact, I tried that once before with a monkey1 module manager and it didn't work out well. The main problem is that this *is* a simple version control system, and adding git in there somehow just complicates things. There is perhaps the option to be able to provide a git repos as a SourceURL in modules.json, but beyond using it as a different download mechanism, I don't think git should play much of a part here. Git integration in the ide would be very nice though! How does that sound? |
| ||
| Yes I agree with all that basically but that still addresses only the one half... (unless I missed something) just having a sources isn't going find me the url's to put in them... when I used the term publish I meant "register" with an official source that either has knowledge of all the registered mods itself or has knowledge of all the "registered" sources. Imagine the internet without root dns servers... :) I don't just use apt-get to get one package I know about... I use it's "primitive" command search functions to query for packages I need. There is a main backend dataset there and you can of course add more but what we don't want is everybody who makes a mod have to put their url in "sources" I got to go but I'll finish up later.... |
| ||
| > I don't just use apt-get to get one package I know about... No, but apt-get still deals with a 'fixed' list of packages that is approved/tested by the distro maintainers. There is, AFAIK, no mechanism in linux to publish an apt-gettable package beyond asking the distro maintainers nicely to add it to the distro, or creating your own repository that people can add to sources.txt. But like I say, my knowledge of linux packages is pretty limited... I suspect you're talking about something else though, perhaps some kind of online 'module registry' for people to publish 3rd party packages to, with the need for any interaction with 'distro maintainers' (ie: me)? In which case, the module manager side of the things could stay the same, only with perhaps 'extern_modules.json' added to sources.txt, that references a dynamically generated file containing modules in the registry. |
| ||
| How does that sound? This would be a cool setup, but (sorry, sorry, sorry) my inner Grammer Nazi is screaming "dependancies" --> "dependencies" and won't let me simply skip posting and move on... |
| ||
| Module manager could have a switch to -publish / -add / -submit new modules. So if I publish or update my module here, the main module list @ BRL server gets modified, and 5 minutes later other users here can update using module manager and receive my latest updates. Module manager could -list all available modules, -install the modules I would like to install, and -update all installed modules automatically. lib.haxe.org is nice. Additional GUI frontend (later) is even better. And web frontend to browse / search Modules with description, categories, targets, etc. is also nice. For a start, the cmdline module manager would be enough. Just requires an automated way to submit/publish/add/update external modules. Probably needs to take care about naming conflicts, in case 10 "json" modules get submitted. ;) |
| ||
| I like Haxelib - nice and simple, so they end up with a ton of modules: http://lib.haxe.org/all/ |
| ||
| I suspect you're talking about something else though, perhaps some kind of online 'module registry' for people to publish 3rd party packages to, with the need for any interaction with 'distro maintainers' (ie: me)? In which case, the module manager side of the things could stay the same, only with perhaps 'extern_modules.json' added to sources.txt, that references a dynamically generated file containing modules in the registry. exactly. (though the location needs to be "official") lib.haxe.org is nice. Additional GUI frontend (later) is even better. And web frontend to browse / search yes, perfect example... I was going to mention cpan.org since that was my first experience with such thing some 20 yrs ago back when I was a unix admin.Modules with description, categories, targets, etc. is also nice. For a start, the cmdline module manager would be enough. Just requires an automated way to submit/publish/add/update external modules. There is, AFAIK, no mechanism in linux to publish an apt-gettable package beyond asking the distro maintainers nicely to add it to the distro, or creating your own repository that people can add to sources.txt. ah, but that is exactly how you do it with apt. my admin skills are quite rusty but back in the day I would find and pull packages from all over using different package managers and pretty much all of them worked that way. [edit] https://wiki.debian.org/HowToSetupADebianRepository [old] http://www.linux-mag.com/id/5006/Now, that said.... don't do that, well, it's fine to build the system that way but all my experience tells me that just lead right back to fragmentation or hidden packages. With linux, the reason you see these other repositories is mainly because of the compatibility issues. with a language you don't have that issue... therefore you get lib.haxe.org or cpan.org both of which are available from the command line and a browseable/searchable webpage. or even https://atom.io/packages which is searchable and browseable from right inside the atom ide. MS visual studio the same. This package publication / notification I think is one of the most critical elements for adoption. oh, lets not overlook how much the app stores for iphone and android enhanced those eco systems. as mentioned by DruggedBunny, most of the managers (pretty much all the OS managers) also handle dependency. but start small. :) |
| ||
| I think losing the association with Blitz is probably hurting. I know some people who have heard of Blitz Basic and have no idea what Monkey is or that it comes from the same place. I've always wondered, why not something like "BlitzMonkey"? |
| ||
| In retrospect, maybe a good compromise would have been to brand Monkey extensively with the Blitz name from the start (as in "Blitz has evolved", etc.). That way even if there was no official branding, it would be sticky enough that the association was clear in searches etc. Probably a bit late for that now. I guess Mark wanted to make a clean break - but Blitz has a good name in the indie development community who would be the ones buying the product. |
   |