CoolBasic Classic DevTeam Applications

Time is now!

As of 1st December we’re now accepting DevTeam applications (Finnish only) via a web form. Open spots, requirements and detailed instructions have been announced in the Finnish forum here. Everyone who thinks he/she’s qualified (including existing staff) may supply one primary and optionally one secondary application for the following titles (including 3 officer/manager ranked spots):

General Manager
Content Manager
Community Manager
Tech Developer
Web Developer
Graphics Artist
Sfx/Music Artist
Forum Administrator
Forum Moderator

Time is now!

That’s right, we have one superior layer. Also people that are currently not part of the CoolBasic community may apply: If you know someone skilled enough who might be interested in participating a fully organized development team for the future coming CoolBasic Classic programming language and game making environment, please inform them. Those accepted will be contacted later on January 2010 after which they’ll receive their personal DevTeam-account and thus gain access to internal web pages and confidential files. Candidates will also be interviewed. All applicants are bound to DevTeam contract and NDA.

Preparing for the DevTeam

Three weeks ago I announced CoolBasic Classic, and also told that it’s going to be out before CoolBasic V3. I also mentioned about a DevTeam that I’d assemble to help me in this project (it’s just so massive I kind of can’t do it alone in a reasonable time). My plans have now become clearer, and a major part of the preparing work I need to do before launching the DevTeam is already in a good shape. Now I won’t be officially announcing the process on how to apply to the DevTeam just yet. But next time I blog, I probably will. All in all, I urge anyone truly interested in participating, to monitor the forums closely for the next few upcoming weeks. This opportunity (being part of the DevTeam for CoolBasic Classic) only applies to Finnish people – at least for now.

So what have I been doing during these 3 weeks then? Mainly websites – for the DevTeam.

The DevTeam will have their own website much like any company Intranet, but in a smaller scale. It consists of (includes, but is not limited to) dashboard, document storage, ticket system, and administrative interfaces for web content (including the www-portal and online manuals). Those two mentioned first are mostly done. The rest will be developed by the DevTeam itself. This website is, of course, secured and restricted from public access – excluding the document storage system which will host both public and internal documents. Each member of the DevTeam will receive their own userID and password that they use to log in to the system. Members can also edit their settings like email and password. Security of this website is something I have paid great attention to: the authentication module can prevent SQL injections, session fixation, XSS, CSRF, form spoofing, path traversal, and brute force attacks – only to name a few. I’ve implemented even some advanced mechanics to prevent certain newly found attack techniques such as DNS rebinding and the protocol comment newline injection. Database credentials (and the documents/files of course) are also inaccessible from web browser, and they’re actually invisible to the web developer, too. It really has become my little experimental sandbox for a secured website. Ironically though, I haven’t yet managed to enable SSL on my web server (gosh, I’m a programmer, not a sysadmin).

The document storage website is an interesting service and it has taken the majority of my time. I consider it now “finished” (although I’ll probably write a visual administration tool for easy role assignments later). It supports full hierarchical category structure the documents belong under. I can assign which user roles are eligible to access any files found from the storage host. Roles can also be assigned to the users. These two combined it’s very flexible to control which users can access what. I can also suspend accounts or “retire” them. All member-made file requests (together with general authentication module logins/logouts) are also logged.

In addition to the DevTeam website, there now exists database schemas for the forth-coming web portal and the CoolBasic Classic online manual. I will probably delegate at least a portion of the web portal development to someone in the DevTeam once I get it assembled. And for that, I need to write some serious specifications. One thing is for sure… there will be 1-2 open spots for skilled and able web developer(s) within the DevTeam. Yeah, there’s that much work.

I’ve also sketched the organisation chart which basically illustrates the members of the DevTeam and their dependencies. In other words, I already know the open spots and what kind of people I’m going to need. Their skill requirements and “job descriptions” have also been planned and written down. There will be applications. While this information will (probably) be published in much greater detail next time I blog, I suppose I can safely say I’m looking for lots of different kinds of people with various expertice and skills: programmers, designers, specialists, web developers, content producers, and artists. Even managers. Also, the DevTeam will probably be extended with new members at some point in 2010.

So what am I waiting for… let’s do this!

Sorry, but I still have lots of work to do before I can start recruiting (I will do my very best to get things rolling before Christmas). Now that the web thingies are in such good condition, it’s mainly the CoolBasic Classic compiler I need to finish. And then there’s some serious writing work to be done (but then again, I can probably do most of it during recruitment time). Without a working compiler nothing else really advances, and that’s why you’re basically now waiting… But! Worry now, I have a good feeling about this 🙂

CoolBasic Classic

First of all, this is purely a strategic decision. The idea has been around since Assembly Summer ’09 (held about 3 months ago), although strictly kept in secret. This news should delight the current CoolBasic user base. And here it comes: “We are announcing CoolBasic Classic, a procedural game programming language, and it will replace the current version.” It will also be released sooner than CoolBasic V3!

There have been rumors and speculation about further development of the beloved procedural and easy game programming language, CoolBasic. Your concerns about too steep learning curve between procedural and object oriented programming have been taken into account, and CoolBasic Classic is designed to continue from where the current (outdated) Beta left. Yes, CoolBasic Classic and CoolBasic V3 are two completely different products, although both are free BASIC-like programming languages designed for game creation. The programming language of choice is partially linked to taste, and forcing everyone to move on to object oriented world seemed a bit too harsh – especially given that the user base is relatively young (c’mon, it’s a game making tool). We want to offer options from which the users can choose the best tool fitting to their interests. Also, we felt that it really is time for some serious technology upgrade – I’ve seen how bad it is. And it could be so much better. There are lots of other reasons behind the decision as well, but I’m sure you’ll find them out by yourselves eventually.

The current CoolBasic will undergo a complete overhaul. There will be a new Development Environment, new Compiler, new Virtual Machine, and new User Manual. There will also be changes to the website (it will reborn as real portal) and the forums. All content will be available in both English and Finnish. The amount of work is too much for me alone, so I will also assemble a DevTeam – with real responsibilities and assignments. I’ll talk about each of the mentioned aspects in greater detail in a moment.

The language
In a nutshell, CoolBasic Classic syntax will remain mostly the same as in the current version. Some features will become obsolete, whereas others will be fine-tuned and improved. All in all, users should be able to port their existing code without too much of a change (outside of find-replace, that is). However, due to complete re-write, command sets can change (and probably will) a bit. But this is necessary in order to implement some of the planned new features in a rational and consistent way. Syntactic changes as well as composition of command sets are something I’d like to hear other opinions about, and that’s one thing I need the DevTeam for.

The in-built data types mainly remain the same, only float numbers are double-precision now. The design also pays extra attention to 64-bit integers for possible later implementation. The language is also slightly more type-safe. You can now define arrays and functions of any type, or pass arguments of any type to a function, including typed arrays. In addition, you can overload functions now. New statement types may also be introduced later (enumerations, anyone?).

The compiler
This is already a work in progress, and it’s, in fact, half done! The CoolBasic Classic compiler is also borrowing technology from CoolBasic V3, and I’m really excited about it because this is a perfect chance to test it in practice as part of a slightly less complicated process. Since CoolBasic Classic is a procedural language, the compilation is much simpler. I can skip some phases that CoolBasic V3 compiler performs, and this will result in very fast compilation and also somewhat smaller memory fingerprint. The new compiler is hundreds of times faster than the current CoolBasic compiler – the process would be done in a few milliseconds even if the source code was tens of thousands lines long.

The compiler is just plain better in every aspect now. It has much better parsing mechanics (no more special-case syntax bugs). For example, you can now define multiple variables and constants within a single Dim/Global/Const statement, as well as initialize them. Moreover, all limitations are gone now – Yeah, the legendary function limit is no more (you can drop the hacking now, *cough*). Just like the V3 compiler, this one also fully supports Unicode, and it has been built 64-bit architecture in mind. Just like the V3 compiler, CoolBasic Classic compiler is a console application callable easily from 3rd party applications.

Virtual Execution System
CoolBasic Classic is still interpreted, although it has much better raw performance. I’ve named the new virtual machine as “Cool Virtual Execution System”. CoolVES is a game engine framework offering functionality to display accelerated graphics, play sound, use sockets for networking, and access advanced game mechanics (in-built physics library, maybe). The graphics engine is finally fully compatible with Windows Vista and Windows 7, and will cause no dump of AeroGlass upon launch. It uses DirectX 9 technology, although it’s possible to enable OpenGL, too. The sound engine is no longer bound to FMOD by default. No more questionable licenses. Executable sizes will be smaller, and it should now be possible to change the icon without messing with UPX in the middle.

There will also be a publicly available documentation about the byte code’s structure, basically enabling anyone to write their own compiler, and this code can then be then run in the VES. The idea behind is to leverage limitation of “the language of choice”. Maybe we’ll see CoolC#, CoolJavaScript, CoolPython (I’d like to name this “CoolBoa” hehe), CoolPHP, or something similar in the future. In the end, it doesn’t matter which language you used, the game will run just fine in the VES utilizing all features made available by it. We actually encourage community members to implement new languages to the CoolVES technology 🙂

The manual
Let’s bring this up to date as well. I already have the design ready, and the database schema is in the works. Details belong to the DevTeam, but the structure of the Classic manual will probably differ from CoolBasic V3 User Manual. The focus is the online content.

The editor
The aim is to have a shared Development Environment for all CoolVES languages (and probably for CoolBasic V3 as well): You just choose from a list what kind of a project to create, and in which of the installed language you want to work on. All game files naturally belong to a project, but CoolBasic Classic still utilizes the IncludeFile statement, don’t worry. Project based approach, however, enables nice new ideas to control and load game media and other content. But that’s, once again, the DevTeam’s business.

Everything is based on modules, and they can be updated automatically. Everything is always up-to-date, and only the changed files will be downloaded. The purpose is to deliver bug fixes and updates as soon as they become available with minimum trouble. Modules can also be tools. Imagine game wizards that generate source code for you – or better yet, build a complete game for you without a single line of code!

Also the editor component will be updated: I’m planning for better syntax highlighting, code refactoring and full Intellisense – only to name a few. Writing code in a modern and efficient way is the top priority.

The DevTeam
I need an orchestra! I can’t play this out alone. CoolBasic organization will be founded before the end of the year, with full hierarchy and assignments. CoolBasic staff will born, and we’ll do development together, mmkay? And for all this, I need volunteers willing to carry responsibility. I need developers (this includes tech and web too). Confidential material, such as source code and technical documentation, will be shared among them. The required skills vary a lot, but I expect good knowledge in whatever that is they were chosen to the team for. I also expect that they have the time and true interest in CoolBasic technologies and are willing to improve CoolBasic products. Staff members don’t necessarily have to be master programmers; I need designers, writers, managers, and content providers, too. If you want to be part of the Finnish game making culture, and you want to aim high, then you fit the profile.

More information about the DevTeam’s tasks and how to apply will be posted on the official forums later.

Document Storage
For the past few weeks I’ve been building a website specialized in document storage. It has a login system and access permissions based on user privileges. While visitors have access to public documents, members of the staff may log in and gain access to certain internal documents, source codes, database dumps, tools and generally everything that is meant for the use of the DevTeam. Also this project has past the halfway now, and it’s looking really good in general.

TL;DR: CoolBasic Classic will be remade, in every way. And it will be released prior to V3. More information about the DevTeam will appear on the official forums.

The Finnish translation of this info is also available here.

Copyright © All Rights Reserved · Green Hope Theme by Sivan & schiy · Proudly powered by WordPress