3 months ago BlitzPlus went open-source. A few days ago Blitz3D followed. When I first read about BlitzPlus being made available on GitHub I kind of silently congratulated them for making that decision. To me it wasn’t surprising at all because of what has happened to the indie game industry and hobbyist game making in general for the past few years. The trend is strongly leaning towards mobile platforms – at least for 2D games. On PC you’d better be going with 3D nowadays – unless your 2D game is either one of those more complex genres, or when the touch interface isn’t enough. In other words, BlitzPlus had become somewhat obsolete (being 2D only and desktop only); it simply doesn’t answer to the modern game development demand. So in my opinion, it made perfect sense to go open-source since not them (The Blitz Research Lab), or anyone else would be making any real money out of it – especially now that they have two competing products of their own (i.e. BlitzMax and Monkey).

Originally, BlitzPlus was released after Blitz3D. I never understood why they wanted to do that – why develop a new product when they could’ve just brought the new features (native UI commands) into the existing product, Blitz3D. It would’ve strengthened the brand and not confused new customers. Not just that, but then they introduced BlitzMax whose main selling points were cross-plaform support (for the desktop) and language syntax enhancements. These changes actually do warrant a new product, though, because all of the breaking changes. From developer’s point of view, however, cross-platform support is a nightmare to establish, improve, and maintain; you’ll have to provide the base functionality for all supported platforms now, which will essentially multiply development time by an order of magnitude. This also explains why BlitzMax launched without 3D. They simply didn’t have time to do it, especially when the community expectations were “at least Blitz3D level of functionality”.

Thankfully, BlitzMax is rather modular. To this day it has been extended with countless libraries developed by the community. Much more than a one-man company can produce on its own. There was even a community driven 3D module in development. Sadly, it was shut down before release because Mark Sibly announced the “official 3D module” with some teaser screens and info. I believe there could’ve even been a small demo. Well… that official 3D module never came out. I don’t know what happened, but I guess developing a full featured 3D engine that works on all supported platforms the same way took so much time that Mark lost interest before it was finished. Just kidding.

A more reasonable theory is that back then the mobile revolution was happening, thanks to iPhone, and Mark saw the huge market potential. So maybe the point of interest just shifted. As BlitzMax already had the functionality that met the mobile game development needs (which is to create 2D games as easily as possible), why not utilize that. So BlitzMax now needed to support new platforms. But if you want to run games on a phone it will place some limits to the engine. A system that was designed to execute on a desktop was too heavy for a phone. This is when Mark first hinted about “bmax2” on his blog. The new system would have to be “lighter” which in itself would already require lots of code rewrite. So why not bring yet more syntax enhancements and make it a new product. Monkey was born.

Monkey targets 12 platforms, including Ouya and PSM. That’s pretty impressive. The only way to make this happen in a reasonable way is to translate a program written in the Monkey language (basically a BlitzBasic derivative) into some well-known other language and compile that for the target platform. Based on what Mark has written on his blog from 2011 onwards there has been quite some technical challenges to get everything to work on such a broad set of platforms. Fighting environment related bugs rather than having fun implementing new features into your product can get really tiresome after a while. And I think that explains why the development of Monkey has been slow. It’s still plagued by a large amount of little bugs. These are nasty because they seem so minor in the users’ eyes and if not fixed in a timely manner they will begin to lose interest and faith into the product’s quality. In addition, new potential customers first scan the forum for some general information, then find about the endless list of these small unfixed things, get a negative first impression, and move on in search of alternatives.

All these products. All these years. Yet there is no 3D functionality apart from Blitz3D. And B3D is still based on the ancient DirectX7. Even mobile games nowadays heavily utilize 3D because the sharp improvement in hardware performance in modern phones and tablets. What’s more, is that the explosion of mobile market has caught the interest of “more-than-just-indie” level game development companies. These shops have professional 3D artists, animators, programmers, composers and designers and release some really nice looking 3D titles for mobile devices. Mobile games are no longer all about 2D. And if Blitz Research Labs want to be offering a “serious” development tools that target these platforms, they’ll need a 3D engine and fast! Unity is already taking over as the “de facto” environment to develop 3D games for the mobile. You’re already late!

Mojo3d is already in development – although it may not be called that once it’s finished. The basic idea here is to provide a simple, immediate mode, low level 3D API that people can use to write higher level stuff with, for example, a backwards compatible Mojo driver capable of enhanced effects/custom shaders etc. Currently, I am aiming for compatibility with all targets capable of gl2/gles2/d3d11. More on this is it develops…

It’s still not out, and reading that topic gave me the impression that it’s not going to be anytime soon. As I said earlier, the expectations are “minimum B3D level of functionality”, but this time for all target platforms. Mark, haven’t you learned anything? You really want to try and make it available on all 12 target platforms, including HTML5?! Even Unity doesn’t do anything like that (there’s a browser plug-in for rendering instead). This is a MASSIVE job to do; you can’t handle it alone. Not within a reasonable time anyway. At the same time your competitors are rocking away with their 30+ member development teams. Technology soars up faster than ever before. If you do this the engine will be outdated right from the get-go.

3 months ago, Mark dropped a bomb. He said in the roadmap topic:

Alas, there is no ETA on ‘next up’ Monkey features.

The sad truth is, Monkey sales are not good and it’s likely I will have to find some kind of ‘supplementary’ income soon – not easy for a guy who’s never held down a real job! Well, since I was 18 anyway. This is not likely to improve productivity, but I do plan on at least continuing to provide updates/fixes and improvements to current Monkey, pretty much as I have been doing recently. But ‘Monkey 2’ (as it was evolving into) is right now on hold.

It’s possible that Monkey 2 was supposed to be a successor for Blitz3D and/or BlitzMax. But since that is now out of the picture and Monkey is going to have only maintenance fixes from now on, I wouldn’t expect new products anytime soon. Which means that Blitz is losing the last momentum it had and will undoubtedly be overshadowed by the competing products.

Soon after that statement, Mark wrote a follow-up in his blog. The article was titled “A slightly depressing update…” where he elaborates about the low Monkey sales. BlitzPlus was announced open-source 2 days later.

He agrees that marketing could be better, but in my opinion fails to see some important points that all, in my opinion, play part in the problem. Anyway… this post was depressing also to read, and it has caused a lot of stir and concerns all over Monkey and BlitzBasic forums. I have always thought Mark’s writing style is a bit too aggressive, but this is not how you do PR. Even though you had to get it off your chest, you shoul’ve picked your words better.

And now Blitz3D went open-source too. For BlitzPlus it made sense, but I really don’t get the reasoning behind this move. Yes, it’s old (15 years, huh?), but it’s still *the 3D dev tool* in their whole product line. All you had to do was to update its engine pipeline to use DirectX 11, and perhaps add more commands that affect the entities’ appearance. Maybe physics too. Make it compatible with the more modern Windows versions. Or maybe MacOS and Linux. I know that you couldn’t apply the syntax enhancements that BlitzMax and Monkey have, but quite frankly, you didn’t have to. People would still use it. You don’t have to (and shouldn’t) compete with your own products. Monkey and Blitz3D serve different needs; one is cross-platform and the other is specialized in desktop (it doesn’t matter if it had a simpler syntax).

The problem is that the Blitz Research Lab has too many products. Instead of adding to existing products they develop a new one. And each time the new product is expected to also contain everything than the previous product did. In addition, they also keep introducing these breaking changes to either libraries or language syntax. Even though it may seem like a good idea to release something completely new every now and then (and get paid for of the purchase) the fact is that you have a flaw in the business model.

Blitz products have always been buy-once-get-lifetime-updates-for-free. This can only take you so far. You basically have to develop completely new products regularly to get (partly the same) users to pay more. And there comes a point where the amount of work is simply too much (especially for one man) to sustain this pattern. Too little return for too much work. Now, look at how some other companies do it… companies like Microsoft, Adobe, Autodesk etc. They too publish a new version of their most popular software every 1-3 years. But they always build on top of the previous version. If you take a moment and look how Visual Studio, for example, has evolved since 2003… it improves each time, but is still definitely based on the previous version. Moreover C# and VB.NET have both evolved as languages too, adding new features and syntax. But the developers still view C# as a single language and Visual Studio as a single product (or brand). As a result, the products are more mature, too.

Even though I think Monkey is a great product, it simply fails at marketing. If you’re a programmer, I completely understand that there might not be any interest in marketing. The Blitz Research Lab is a really small company. I’ve got the impression that Mark Sibly is completely self-employed, and I don’t think there’s anyone else to help with the “boring” things such as writing documentation, managing websites, or doing accounting. it would help a tremendous amount if you had a sales guy, or even another developer (who could handle the editor and website, for example). But the problem appears to be that they can’t afford to hire anyone. It’s a vicious circle that feeds itself: you can’t do everything needed → products suffer → sales suffer → starts over. It’ll generate frustration, create stress, lead to burnout, lose of interest etc.

As someone in the Monkey forums put it: “Monkey’s major issue is that it simply cannot keep up with the perceived competition in the form of Unity, Gamemaker and other well funded and well teamed tools, and the gap is going to grow over time.”

I think that BlitzPlus and BlitzMax were mistakes. Mark shoul’ve just developed Blitz3D to have their features (while still targeting multiple desktop platforms). But the mobile revolution blinded him. He took a big risk with Monkey and it didn’t turn out as well as expected. While the new language features such as classes with constructors, and even polymorphism do sound good on paper the fact is that at that point why would I not choose C++ instead (especially when you lose your sweetest carrot i.e. 3D). One might argue that BlitzBasic as a language would then be outdated. But that’s fine because the game runtime and easiness to use it were the things that mattered most. Blitz3D had its target audience. But not anymore, and only because its tech is too old.

While Monkey supporting mobile platforms is indeed a really nice thing, the problem is that those platforms already have official SDKs that everyone uses; If you’re a newbie game developer who wants to create his first iPhone game the first googling will not lead to Monkey website. It will lead to the SDK download and developer community sites. Also, you won’t find a way to solve your coding problems in Monkey but with the “more-adopted” way instead.

I don’t know how Mark will overcome this, but I think making Blitz3D open-source without having a replacing product already available, was made in a hurry and without thinking. I don’t think Monkey has any chance at competing with mobile game development tools (2D or 3D) anymore, but I don’t know if introducing yet another product will be the desperately needed medicine either 🙁 All I can say is: Mark, get a job to stabilize the income, take a time to think about what you want to do with the BlitzBasic brand and products. Put Monkey on Steam if you don’t want to handle marketing on your own.

Just a quick update. As you can see the blog now has new looks. This is part of a larger configuration regarding our web services. There’s now a new domain, coolbasic.fi that currently redirects to coolbasic.com. We now have a virtual web server instead of a standard web hotel, meaning that we can execute whatever we want on it. We recently migrated the forums to this new server, and everyone’s DNS should be up to date by now. There’s still some setting up to do such as a custom user account database and a complete CMS solution for the future website; the plan is that everything under coolbasic.fi will feature Finnish content only, and coolbasic.com will contain the international site. There will also be different discussion forums based on localization.

As a bonus note, we were 11 people from the Finnish CoolBasic community who participated in a summer cabin holiday just now. Back there, they managed to forge some motivation in me: An interesting community-driven project exists that basically implements a custom runtime & game engine for the old CoolBasic. It’s called “CB enchanted“, a very cool name I might add, and is a reverse-engineered CoolBasic byte code interpreter packed together with a fully hardware accelerated graphics system. Quite impressive! The real WTF is that these people managed to reverse-engineer the entire byte code structure, inject the engine as part of standard CoolBasic compilation process, and deliver overall better performance compared to the good old CB – and all this before CoolBasic Classic 😀

Yeah, I opened the compiler solution a few times and thought: “It’s time to finish this.”

Before we begin, I’d like to say that the feature demonstrated herein will NOT be part of the first release of Cool Developer and CoolBasic Classic, but I’m merely playing with a cool idea instead.

I’ve been interested in versioning and Source Control technologies in general lately. One part of version controlling is the ability to handle conflicts when two or more developers check out a file for editing, do their changes and then check them back in. Two simultanous check-outs will often result in a conflict within the source file, and these conflicts have to be resolved through merging. Merging means that both developers’ modifications and fixes are applied to the source file, without the other’s changes getting lost in the process. Merging is one thing, but analyzing the differences is another. I decided to try out some difference tracking techniques.

First of all, there are number of algorithms available. Some are easier to understand than others, and some support more features (such as the ability to detect moved lines and code blocks). The most popular method I found was the Longest common subsequence problem, and it is, in fact, used in most Version Control software. It’s a good method of producing a script that can be used to “patch” the destination file with tiny changes so that it’ll transform to that of the source file. Basically you get a set of “add this to place X” and “remove this from place Y“. Unfortunately, while this technique indeed gets the job done nicely, visualizing these kinds of changes can be confusing. When a conflict occurs, for example, determining whether the merge would break something, can be tricky.

In addition, due to how LCS works, comparing two very big files (10,000 lines or more) quickly starts to eat giant chunks of memory because the algorithm operates with a matrix of n*m, where n is the number of code lines within the first file, and m is the number of code lines within the second one. There are a number of ways how to optimize memory consuption and matrix size, but that is out of scope of this blog bost.

Ideally, when a developer encounters a conflict (and a merge needs to be done), he or she will be provided with two source files side-by-side; one from the server and the other is the local file. This view should visually present those parts that differ between the two versions. If the developer spots a problem that would break the code upon auto-merge, there should be a way to edit the file before committing. LCS cannot by itself provide good enough visual presentation because it can only tell insertions and deletions, but not modifications. For example, editing a single line would produce both “delete” and “addition” changesets.

Then I came across with this Patience Diff algorithm. All in all, it would seem to fit to the purpose perfectly – it offers a very nice and clear presentation of changesets between two files and doesn’t take an awfully lot of memory either. I spent hours and hours trying to find a .NET implementation of it, but as of yet there apparently just aren’t any (the number of “good” C# implementations of the other algorithms is substantially small aswell). So I started working with a proof-of-concept. I spent a little less than 2 days on this challenge, and finally came up with a working solution. When I’m writing this, my work is the only C# implementation of the Patience Diff algorithm that I know of 🙂 . As a side note, there’s seemingly only one Version Control product that uses Patience Diff as its main tool, Bazaar, but apparently one can optionally enable it for Git aswell.

Here’s a sample of two slightly different files: the left side represents the original document, whereas the edited version is on the right:

The following difference graph can be generated from them (green = insert, red = delete, yellow = modify):

So what does this mean for CoolBasic? I don’t really know yet, but I have some ideas 🙂

Okay… where to start. The year changed. Gosh, that went fast. I can remember me writing tons of stuff and assembling the DevTeam 12 months back like it was yesterday. Obviously we didn’t make it in 2010 like originally planned, but the CoolBasic Classic project continues still. Actually, I just went ahead and changed the year from 2010 to 2011 on coolbasic.com (…and yes, it’s a common joke amongst project managers that deadlines should indicate month, but intentionally leave the year unspecified 🙂 ). I’ve been a little slacky the past few weeks, I admit, but it’s been hectic at work and other members of the Team have had all kinds of stuff going on in their lives (who wouldn’t). It being a year now, the DevTeam members’ contracts are closing to an end soon, naturally. This means it’s time for a round of renewals! That being said, few people are leaving their duties due to a number of things, but the majority has expressed their interest of continuing in the Team. And that’s great! For now, we have decided not to open new positions, and will recruit more only when needed – who knows, perhaps some of the original members will make a come-back. The organization structure is going to change a little bit, and details will be published later.

So what’s been done since last time… well, most of it has been management oriented. I feel it’s most convinient for you if I just list the things:

We have explored alternatives to SVN version control, like Mercurial

We actually purchased a Virtual Server for web hosting

We now have domain coolbasic.fi (and it’s already operational on the Virtual Server)

We have configured PHP and MySQL databases

We have explored ways to use LDAP authentication services

We have explored ways to improve forum experience through measures in order to shut down spam

The PureBasic accounts have been terminated since we now use other tools

The web host isn’t fully configured yet, but we’re working on it. When that’s done, we can set up a true testing environment for web developing (full copy of the portal, forums, everything).

I saved some money for not having to purchase a new set of PureBasic one-year licenses, but then again… I did purchase the Virtual Server, and it costs roughly the same. No gain there. In addition, I just recently purchased a license of Resharper which was around 200 €. I use it together with StyleCop at work, so I’m quite used to it. Coding without these essential tools feels somehow awfully wrong nowadays. Resharper is an extension for Visual Studio that provides advanced code analysis and refactoring tools that will help you write better code that is styled and constructed according to “best practises”. It helps to improve code readability and maintainability, and overall I think the gain is notable. I’ll be spending at least a few days refactoring my existing code now…

Fortunate me, I’ve had a chance to experiment some of my compiler specific ideas at work as well (I’m working on a project where I am able to use this expertise of mine), so even though not much code have been added to the CBC compiler project for the past 2 months, I, in fact, have done something useful that will help me achieve my goal in the CoolBasic project (I proved some techniques and theories work in practise).

One of the to-be-implemented-next features of the Cool Developer editor is to get it perform an actual “Build & Run” action using the CoolBasic Classic compiler and the Cool VES linker. Once this is done it’s obviously possible to start coding in CoolBasic (although the runtime and compiler aren’t fully working yet). Anyways, to get this wheel rolling I prepared a dummy compiler and a dummy linker executables that can be used for to simulate a Build process. To hook ’em up I also prepared a CoolBasic Classic Cool VES game project template that Cool Developer consumes. The project template consists of a set of XML files that describe the allowed project items and how they’re presented in the editor. They also define how this project type needs to be built. Currently, the CoolBasic Cool VES project has two build steps: 1) compilation, and 2) linking. If one fails, the entire chain fails, and is also terminated immediately.

I mentioned “dummy executables”. In actuality, they’re the real CoolBasic Classic compiler and the real Cool VES linker, but they aren’t feature-complete yet. For example, the compiler only has lexical analysis and the linker only creates an empty (yet valid and runnable) executable. Both can be tested by intentionally providing invalid source (such as CB source with invalid parentheses or mismatched string quotation). This enables us to test error reporting and build step chaining properly back in Cool Developer.

I uploaded this package for the DevTeam a few days ago, however, it was only for Windows. I decided the sooner I can verify that it works on Linux as well the better. Finding out that you have to change half of your code when it’s time to deliver would such big-time. So I installed Linux on a VMWare virtual machine this weekend. I then went ahead and fetched Mono and set up the CoolBasic Classic compiler and Cool VES linker projects in MonoDevelop. They both compile out-of-the-box and seem to work properly. I was a bit surprised how easy it was. I have zero Linux experience. None, whatsoever. Now I just need to figure out how to share a folder (or something) so that my Windows 7 host and my Ubuntu can share stuff… or just link them both to SVN somehow. Lots of research work to do.

I haven’t yet gotten started with the Parsers, but let’s see what the forthcoming week produces.

We recently had a discussion at our regular DevTeam meeting about exploring other possibilities for a proper development platform (and for the record, that meeting was one of the longest so far). There is a number of reasons why we think we should migrate away from a certain programming language, and base our code upon a “more supported” platform. For example, when the Chipmunk physics library updated not so long ago, several problems emerged regarding cross-compiler generated code, and ultimately broke some compatibility. Now, one would expect that since it’s C it was standard enough to “just work” every time. In reality, however, our developers have had hard time with importing and invoking (consider SSE2 and dozens of compiler flags in the equation) the 3rd party libraries. We’ve got Chipmunk working in the current build, but there’s a high probability that it’ll break again in future coming library updates. All in all, fighting these kinds of problems is indeed quite frustrating (and uncalled for), especially when debugging these things is very difficult – if not impossible.

I think that procedural coding in general, an inadequate editor, a bit too simple tools, and a somewhat limited debugger will not serve our best interests in the long run. To me personally, it’s not too encouraging to open up our current development environment and start writing productive code anymore. I’m a professional C# developer, and this procedural coding (I once preferred) is becoming a mental burden for me. It has definitely affected my motivation in a negative way. I know I said a year ago that in order to create a fast and compact compiler, a procedural approach would be ideal. But I consider pleasant and powerful tools equally important because it enhances productivity of the programmer and maintainability of the project. I’m referring to Visual Studio (which in my opinion is the best IDE out there) as well as to Intellisense, refactoring, code analysis, unit testing, and other very powerful tools provided by it. After all, I think that if the compiler required a tad more memory and it took 2 seconds longer to build a game, it wouldn’t hurt too much (in a year the computers running the compiler are probably multiple times faster anyways).

So we’ve come to a point where we’re going to port our existing code over to C++ and C#. This will make a whole lot of new possibilities available to us: We can now harness the power of modern development environments, get more productive, and we no longer have to worry about the import files. We can trust that the generated ASM is correct and that using external libraries won’t conflict (that much, at least). There are pros and cons in object oriented design, but overall I’m confident that the marginal speed gain provided by procedural coding style isn’t going to outweigh anything. One of the most important things is that the developers are happy and get to work on something they enjoy.

The Cool VES game engine is going to be re-written in C++. This still enables us to inject ASM to where speed is critical. We’re also experimenting with a new multimedia library that ought to ease our job when implementing certain command sets in the future. We also continue developing Cool VES for both Windows and Linux.

I also mentioned C#. That’s for the CoolBasic Classic compiler! Now, this is quite interesting because there has been one project (that has nothing to do with us) I’m aware of, that attempted to write a compiler in C# about a year ago. It didn’t turn out that well, and currently the project in question is apparently frozen. One would think that this should be considered a warning example, but yet I’m willing to try doing the same thing because I really think it’s possible and quite doable. Yes, there are some serious challenges, and the architecture plays an exceptionally big role here. C# makes it possible to create a very high-level and sophisticated core for the compiler, and I’m very excited about it. Only a day after the meeting, I already had an initial architecture plan and a Visual Studio solution in place. Given that procedural model is seriously impacting my motivation, I actually believe I’ll get the job done faster now that I have good tools – even when it means I basically have to start over.

Many people associate C# to the Windows operating system. While it is true that C# is largely used to write software for the Microsoft .NET Framework, not everyone is aware that you can target programs written in C# to other platforms as well, like Linux. Just as Cool VES is intended to have both Windows and Linux versions, CoolBasic Classic compiler should also be available on Linux. I’ll be using Mono for that, but more information about that will be published at a later time.

If this becomes an epic fail, I can always revert back to the old compiler, although I highly doubt that. “I want to believe” 🙂 . In fact, I should have known better when I made the decision of the development environment almost a year ago. I hope I get it right this time…

TLDR; We decided to start using more powerful development tools, and we’re all now more productive and happy.

Can’t believe it’s been a year already as I vividly remember writing the ASM 2009 raport. This year’s Assembly demo party was, similarly to last year, 4 days in length, but this time I actually slept better so overall it was even cooler :). Every year it feels like gaming is taking more major part in the party. Besides lots of people there are playing and enjoying the lightning fast party network, there are also seminars and career opportunities related to game industry. Every Finnish university that offers courses for game development are strongly visible at the party booths. I myself attended an interesting seminar of XNA and Windows Phone 7 game development.

We had a group ordering for the CoolBasic community, which once again, gave us a geat opportunity to get known with each other also in real life in addition to good old forum posting. Having pizza, playing games, and discussing together was just splendid again. Below is a group picture taken outside the Arena; we had to look against the sun, and that’s the reson to grins and wet eyes.

Last year I presented details about CoolBasic V3, and this year I had presentation about CoolBasic Classic and Cool Developer (the code editor). This presentation had lots of info that was revealed for the first time in public! This time we actually went to some place more quiet than the Arena, so hopefully people would hear what I had to say more clearly. The mass of people followed me to the dark and shady parking hall for some demoing from my laptop. Needless to say, having the presentation in such a place felt a bit akward, so maybe I just book a room with a video projector next time :). Two major topics were without a doubt the game engine and the editor, and as it’s now basically public, I will post official overviews of them shortly in this blog.

I planned to write some code and do some HC development for CoolBasic Classic at the party, but due to constant competitions and other events on the big screen (forcing everyone to stop whatever they’re doing and close their monitors), I got interrupted all the time. Oh well, it’s a demo party after all – gaming and coding can be done in small doses, but in the end of the day, I achieved close to nothing of productive work. Good party!

I learned just recently that one of our beloved forum moderators, Bagard, is no longer with us. Bagard was nowhere to be found since last January; he didn’t answer to any emails nor private messages, and he disappeared from IRC. I feared for the worst, and we finally got a forum post confirmation (which judged by the tone of it, I believe strongly, isn’t a troll) about his condition from an anonymous friend of Bagard. Even though this may come “late”, I’m deeply sorry. Bagard attended the first CoolBasic summer cabin meeting back in 2009, and all of us who were there, I’m sure, will remember him as a great person.

Yeah! Over 2 months in the making, all necessary arrangements are finally done to bring the development team up and running. During this period I’ve been documenting, and documenting, and.. umm.. documenting some more. Less time coding, I know, but it’s better to have well thought-out plans before we start implementing anything. The biggest time-sink has been writing down most of my ideas for CoolBasic Classic so that every member of the DevTeam is aware of and understands them. For now, I think there’s about 200 pages of text if printed. The management has decided to let the newly selected members to have some time reading the important contents from the hidden forum and from the document storage before assigning the first tasks to everyone. We’ll be having our first welcome meeting soon, too. I was happy to see both technical and design-related discussion about various topics within the same evening I promoted the members. I look forward to have rich brainstorming for the few future-coming weeks, too.

I and the managers interviewed all applicants. These sessions were about 45 to 50 minutes long discussions where the candidates were tested against their applications, and their motivation, skills and suitability were evaluated. Those chosen, I believe have true interest in developing this remake of the current, oldish CoolBasic, called CoolBasic Classic. Generally speaking, all interviews were pulled off during one week. There were 4 to 7 interviews per day, and they took place after normal business hours. It was exhausting for me to tailor the questions and the frame for each interview separately (in addition to executing the actual interviews), but I think we did a very good job at it. Having chosen managers beforehand definitely helped, and I’ve had support from them in many aspects how to organize the team efficiently – among other things, we now have an SVN in the works.

Every member was promoted to the Dev forum group, and they now gain access to the hidden development forums. The devs can be recognized from their bright yellow name color. They also received a @coolbasic.com email address as well as the login credentials to the internal website wherein the document storage is found, too. Tech Developers also get a free PureBasic license for 12 months. We ended up to 12 members + management, and I feel that we have a good team that has expertise from various areas of IT. The reviewed organization chart looks like this:

Now that the launch is behind, I can continue my work on the CoolBasic Classic compiler. It’s top priority because we cannot really start with the CoolVES engine until we have some byte code to feed in. Soon there will be various other “projects” launching in parallel, including code editor, internal DevTeam web services and experimental code for CoolVES. In a nutshell, all team members (apart from music artists) should soon have something to work on. Also, we have code quality checks, regular development meetings and branching. Once the compiler is at a certain state, I’ll start writing its technical documentation (internal) along with a public byte code documentation for CoolVES. Yay, I so love documenting *cough*. Right now I’m working on function overload resolution and optional parameter fill-in. When that is completed, only statement-specific validators remain for Pass#2. And when Pass#2 is finished, it’s time to implement the actual byte code synthesis (at that point, I will start specifying its exact command set). The compiler is already lexing and parsing all language features.

So the world has now entered a new decade. Let’s summarize what happened in 2009, and also peek into the future a bit.

For me, the year 2009 was pretty solid all the way. I developed CoolBasic V3 compiler, and managed to finish it. Well, nothing is perfect the first time you do it, so I’m still going to have to rewrite parts of it in order to improve performance in certain situations. However, as I got this idea of complete rewrite of the current CoolBasic, V3 will have to wait. There are number of good reasons why it’s smart to finish CoolBasic Classic before continuing V3 development. Being such a gigantic project with a whole lot of things that can ruin it all, CoolBasic V3 will definately need a development team. The contrast between current CoolBasic and V3 would simply be too much for the current community to handle, making it very hard to establish a competent DevTeam. CoolBasic Classic is a step to that direction, and it gives me an opportunity to test the idea of a small (yet fully organized) development team as well as some of those technical solutions already implemented in the new V3 compiler. CoolBasic Classic should provide a smooth step to V3’s direction, but it’s still going to be mainly procedural language. With CoolBasic Classic I hope we can increase the size of user base, resulting us better chance to find willing and competent people to develop CoolBasic V3 – when it’s time.

The last quarter of 2009 went on me planning this CoolBasic Classic DevTeam thingy as well as writing the Classic compiler. I must say time has wings and has flung by. It’s almost as if it just was autumn. I spend several hours a day working on CoolBasic Classic and its DevTeam launch, but due to big plans I need to study a few areas of interest regarding a few technologies I’m going to utilize in this project. It’s too early to tell publicly what those would be, but if all goes as planned 2010 will be a very interesting year for CoolBasic community. We’re definitely going to launch this year, and CoolBasic Classic will also be available fully in English! As a side-note, the Finnish community has grown vivid after the announcement, and there’s a lot of excitement in the air. I’m very happy to see an increase in the forum’s activity.

So DevTeam application period has now closed which means I’ll start studying those applications and then assemble the team. I was wondering if 31 days was too long a period to accept web form applications, but they came in pretty evenly throughout entire December (with slight front-load, though). I received 29 applications in total which I think is quite good considering how strict and demanding the requirements were. All vacancies were fulfilled, including the superior layer. The organization chart shown in the previous blog entry, will be changing a bit, but its reviewed version will be made available not until the team has been finalized. All in all, I think we’re going to have a solid team consisting of different areas of competences – even at a professional level. That being said, there will be interviews, to be held soon enough, based on which I’ll make final decisions about the composition of the DevTeam. DevTeam website has already been set up, necessary documents have been written (and will be available to DevTeam members through internal document service website), initial assignments have been formalized, and the forum now has additional hidden sub forums the normal users cannot see. I’ve spent countless of hours preparing the DevTeam launch, and the material they’ll have to read in the beginning, may feel a bit overwhelming.

There are quite a few topics I’m going to discuss with the DevTeam, and as things get decided, I’ll be newsing about them in this blog. Even with 15 people plus me, it’s still going to take months until we can launch CoolBasic Classic. Yeah, it’s THAT big of a project.