The Developer’s Blog

I decided to start a new tradition, a comic about CoolBasic, and its community and staff. I intend to keep the publishing pace of the comic relatively slow, but I do have some fun ideas reserved already. I’ll enrich the comic with more characters in future coming strips, but for now let me introduce “The Zero“, who is the Lead Developer of the entire thing, and “The Evil Admin“, a stereotype of someone watching over our forums in a daily basis.

Game Creation Tools Comic

Now this is exciting! The graphics engine of Cool VES (that is used by CoolBasic Classic) is currently the most complete sub-project of this entire development process. It’s already featuring all functionality that current CoolBasic does, and even more. This blog entry focuses on to introduce the new graphics engine (with a little surprise at the bottom), and will shed some light to the matter. The new graphics engine is considerably faster, and is now fully GPU accelerated. It uses OpenGL for rendering, and it’s also cross-platform *cough*. We take advantage of modern graphics hardware, thus enabling us to use some advanced effects, which means that CoolBasic Classic users will be able to create stunningly good-looking graphics if they’ve got the skill. Now excuse us about the quality of the preview images you’ll find all over this entry: they’re our internal work and made for testing, and don’t generally look that good. They simply haven’t been meant for demoing/promotional purposes. That’s why there’s lots of test data visible on screen as well. However, they do actually cover a major part of features from the new engine. We’ll create some ‘properly-finished’ sample images at a later time. But now, on with the preview…

Let’s take a look at these 3 images (click for a larger version):

First Image (on the left)
This one has a lot of going on on the screen. It was one of our first test programs. FPS without 2D drawing is very high. It’s difficult to exmplain everyting as you can’t see it on the move, but here’s a somewhat complete list what you can see in this demo:

• We have basic object loading from an image file in place. We’ll also support loading from memory and from pack files in the future
• We can move, rotate, and scale objects realtime without any performance hit. Come new era of particles!
• Objects support alpha channel extracted from the image texture (encoded in PNG images)
• We can change the mask color to enable transparent backgrounds
• We can colorize objects by changing their base color (the red cube)
• Objects can have a custom-located anchor point around which and according to which they rotate and scale
• Objects can be alpha-blended (i.e. ‘ghosted’) by a given percentage
• Objects can have custom drawing order (user-defined Z-depth)
• We have multiple blend modes, including (but not limited to) additive (lightening) and multiplicative (darkening)
• We can load fonts and render text to screen
• Basic 2D drawing works too: lines, dots, rectangles, triangles, and ellipses. Filled or not
• We can now rotate and zoom the camera in addition to objects! This means we can affect how the entire game world ends up being presented on screen

This is not visible, but we also have a solution to draw static UI elements and backgrounds at absolute screen coordinates as well as showing images in the old-fashion way, i.e drawing them only once. We’re still discussing about normal images, but it just might be that we end up consolidating everything to objects as they can be rendered in much more diverse way than just plain images can.

Second Image (in the middle)
This one demonstrates available filtering modes which basically affects the quality of drawing rotated and scaled (or otherwise transformed) game objects. We can instruct Cool VES to render graphics in a pixel-perfect fashion, which might work well for UI, but in general game objects look better when a filtering is applied: either a bilinear or trilinear methods can be used. We may add additional modes in the future.

Third Image (on the right)
I saved the most delicious one last. First of all, we have multiple viewports, which is cool because it enables more than one camera inside the game world! This will give the users new possibilities to create, say, multiplayer games. I mentioned at the beginning of this blog entry that we take advantage of modern hardware. What you see in 3 of the viewports are actually shaders. They can be used to post-process the rendered game world, or to enhance single objects through our new material system. The possibilities are quite limitless, and I expect to see very beautiful water effects, motion blurs, and color tone-affectors in the future.

The top-left viewport uses a shader that renders its contents in grayscale. Although this is a very simple shader, it’s quite commonly used effect in gaming. This grayscale effect is achieved via a relatively simple shader code:

void test()
{
vec4 texel;
vec3 colors;
float average;
texel = texture2D(p_Texture,gl_TexCoord[0].st);
colors = texel.rgb;
average = (colors.r + colors.b + colors.g) / 3.0;
gl_FragColor.r = average;
gl_FragColor.g = average;
gl_FragColor.b = average;
gl_FragColor.a = texel.a;
}

That’s the contents of the shader file – Cool VES loads shaders from normal text files.

The bottom-left viewport uses a blurring shader, another widely used effect in gaming. It could be used to achieve nice effect to emphasize something on the screen (while the background gets all blur).

The top-right viewport enhances whatever is under the mouse with increased intensity, making everything underneath to ‘bloom’ out. Can be used, for example, to highlight explosions and such.

The final viewport (bottom-right) visualizes a scene graph. Cool VES optimizes rendering through this system. It’s now also possible to assign child objects to parent objects, creating hirearchical models! We can literally construct game characters by attaching the limbs, which are separate objects, to each other, and then, for example, animating them according to custom made sequences (yeah, object animation is no longer limited to image strips). Since object hierarchy enables us to ‘glue’ objects to each other, it’s extremely easy to make objects automatically move and rotate with their parent. Imagine a health bar attached on top of a game character.

Physics

Let’s take a look at these 3 images (click for a larger version):

Ok, this is really really cool stuff. We’ll replace the old collision system entirely with a 2D physics engine! All collisions between game objects are now affected by full rigid body dynamics. Basically every game object can be applied with a collision shape, mass and a few more attributes. Once set, Cool VES will automatically update them with full physics response! The collision shape can be of any convex or concave polygon, or a simple primitive. We can also access the collision data to determine what happened to any object. Objects will bounce off/collide with each other or static obstacles.

The first demo (on the left) has some static immovable objects horizontally aligned in the center, and lots of bouncing dynamic objects: they get impulse outwards whenever they collide with anything. There’s also a keyboard guided triangular ship flying (at the moment of screen capture, located on the right side). Although very simple, toying with the ship, all objects involved, was quite fun.

The middle image demonstrates liquid physics where a keyboard controlled circle object swims in a sticky goo.

The image on the right combines everything. It’s a pinball test with zoomable and rotateable camera. Collision data has been added and it follows the contour of the image. You can also add new collision walls to the screne by mouse – on the fly!

Networking

Cool VES will finally feature in-built networking using TCP/IP and UDP. More info about that later, but it’s very likely that we’ll build some sort of high level command library to handle some advanced mechanics, such as interpolation and extrapolation (to overcome latency issues), automatically.

Game Creation Tools Cool VES, CoolBasic Classic

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!

Game Creation Tools Misc

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.

R.I.P

Game Creation Tools Misc

The new CoolBasic project is divided into several sub-projects. Each team member has been assigned to one of these projects according to their skills. This first half of the year has proven to be productive, and we actually have concrete results already. Most news has been posted on the Finnish forums, and I apologize to you non Finnish people, although we tend to evaluate things we want to share every once in two weeks, we’ve been quite silent about our plans and doings. The reason there’s been so little information in English is purely that we want to limit how the word spreads at this point in time – we all know what happens to too high expectations in the end. The Beta plan is to first limit it to a smaller closed group which makes possible for us to iron out the most critical bugs. After that we’ll extend the Beta program, ultimately for all. However, please notice that talking about Beta doesn’t mean it exists yet. We’re not there yet. In this blog post I wish to shed some light to the different aspects of the huge CoolBasic project. More details will follow in forth-coming blog posts, this is just a compendium.

Before we start…
At the beginning of June we had a public meeting to which nearly 20 members of the CoolBasic community participated. We rented a summer cabin for a weekend and headed to Nilsiä situated in middle Finland. Many of us saw each other in real life for the first time and had a chance to talk face to face. It was a bit rainy, but I at least wasn’t too sad about it – I think we all had a great time having sauna, barbequing some sausages, playing games, and having fun in general. Too bad it was only 3 days, but arranging the date so that this many were able to make it, isn’t as easy as it sounds. Half of the participants were in fact Devs from the team, and we actually had a presentation, powered by a video projector, to show off the new editor and engine features. More social meetings, please There’s definitely going to be another next year!

The Editor
The old CoolBasic editor will be completely replaced with a modern project based development environment. This time we’re aiming really high, and this new editor, Cool Developer, is designed so that it can serve as development environment for future coming products as well! It’s highly modular and the architecture makes it possible to develop powerful plug-ins for it. We’ll probably even offer free Visual Studio templates for download so that anyone can develop a new plug-in (or an entire product, perhaps your own programming language) for Cool Developer. The editor is fully customizable and localizable, and it can dynamically load custom made UI modules on the fly. In addition, the way the editor looks, is fully customizable through skinning. I think we’ll go for cool black look this time If you know XAML, it’s relatively easy to write your own skins. Skinning the editor, however, is not just defining the colors – it’s possible to compose everything, including layout, UI animations, and visual effects!

CoolBasic games are now created as projects that host all the related code files. Much like in Microsoft Visual Studio, project structure is a hierarchical list of all files associated with that project, including code, media, and other content. Those units don’t necessarily reflect the underlying file system at all, but the entire project is easily transferred between different machines by simply copying a single folder. You can also have several projects open at the same time, in which case the top-most element within the hirearchy is a “Solution File”. it’s basically a collection of different projects. Imagine you have a game (solution) that includes a CoolBasic Classic code project, and a Tilester project that has all the maps the game uses.

We’ll also construct a new “Start Page” that will list the most recently accessed projects, show you some news from the CoolBasic community, and perhaps feature some interactive content. It might even be possible for you users to customize the start page via XAML.

Everything, including the Start Page, manual, code files, and visual editors, can be opened into a tab. The behavior is much like in the current (obsolete) editor, only there’s no limit what you can open in a tab. We can even present complex editors, such as a tilemap designer, inside the editor now. Imagine a visual editor to build game objects, or a tool that packs game media in a compressed file! We basically associate some content presenter to a file type: for code files it’s going to be a syntax highlighter editor, for other types it’s going to be something else – a web browser for web pages, for example.

The editor also has a built-in update engine which keeps all installed products always up-to-date; you no longer have to manually download and install updates when we fix bugs or add new features to CoolBasic Classic compiler or the CoolVES engine.

As for the user interface, it resembles Visual Studio a bit, but we’d like to enhance it with some fresh ideas. It’s relatively rare, for example, a code editor to have a ribbon… or how about something completely different to the standard Solution Explorer + Property Window combination? A screenshot of the new editor will be provided later – there are a few things we’re experimenting at the moment. At this point, however, it’s looking really cool in its black theme! As a side note, the editor is currently developed by two professional WPF (Windows Presentation Foundation) programmers. And yeah, it’s in .NET Framework 4.0

Compiler & Language
Although we plan to design the language as similar to the old CoolBasic as possible, we’re going to make some changes to the basic syntax to accommodate “more accustomed” practices. For example the member access operator “\” is going to be replaced with a dot. Custom typed variables are declared via the “As” clause inside a “Dim” statement. Arrays and Linked Lists will also see major improvements – it’s now possible to pass arrays as arguments, and return arrays from functions. Arrays can also be of any (custom) type. Linked Lists are no longer singletons based on a type i.e. you can create as many Linked Lists of any type as you like. There’s also going to be differentiation of Subs and Functions. We may also enhance the “If” statement chain. Structured error handling and a debugger are also considered. Of course, we’ll integrate the debugger to Cool Developer editor as well. All in all, most old CoolBasic games should be relatively easy to port and compile against the new execution engine. Simple find&replace throughout legacy code will probably not be enough, but the additional adjustments one would have to make manually are merely trivial.

CoolBasic Classic is producing CoolVES compliant byte code. This means that the game engine is separate to the language that simply is porting games for its use i.e. it might be possible to write CoolVES games in other languages than a BASIC in the future! Or having a completely visual game building tool (like Click’n'Play / Game Maker) for the CoolVES engine! Maybe CoolBasic Classic could even operate as the programming language for other execution engines as well *cough*.

The improvements to the current CoolBasic Classic compiler (taken from experimental code of the V3 compiler) have proven to be working well. The lexer and parser are already done, and code analysis is under construction. It won’t take long until I get to the synthesis part which essentially means, at that point, the compiler can actually produce byte code and the development of the CoolVES execution system can begin! That’s also when the cool stuff begins and the rest of our team members get their hands on some really nice stuff. Perhaps a public tech demo will follow

The Game Engine
Now the actual game engine is something that has made huge progress during the past few months. It’s going to be OpenGL based and cross-platform. Whereas the old CoolBasic only has software renderer, the new graphics engine is taking full advantage of modern hardware. The engine is already able to render game objects on to screen, and rotate, scale and transform them – basically everything one can already do in old CoolBasic. Blending with different modes is supported as well as different filtering methods. We’re even experimenting with some more complex materials. The game objects can now also have a parent so that they move, rotate and scale in relative to the parent object. In addition, we now have multiple camera support, and camera zoom and rotation! It’s probably a bit too early to talk about object animations, but we do have major plans to drastically improve it. Also tilemaps are going to go through lots of improvements in terms of rendering, interacting and collision checking. All in all, there’s a lot more you can do with game objects now, and the command sets are going to be re-designed from scratch.

As what comes to the audio system, we’re dumping integrated FMOD. It may become an option again later in the future (optional engine you could enable for use in the project settings within Cool Developer interface). FMOD makes it possible to use wide variety of different formats, and even visualize the output stream, but for now we’re going to implement the Audiere library which is completely royalty free for commercial and noncommercial use. As a side note, the primary recommended format all CoolBasic demos and tutorials will use, is going to be MP3.

Perhaps one of the most interesting new major features we’re adding, is the in-built game physics. Every game object can have full 2D dynamics applied to them. You’ll simply define mass and shape (amongst a few other attributes) for an object, and everything else is done automatically for you – objects will bounce accordingly from walls and each other. Implementing this powerful feature will enable the users to create games like never seen before in CoolBasic! This system also serves as base to in-game collisions, to make game character jump you only need to apply an impulse upwards. Should you hit your head to the ceiling, you simply drop down again, and automatically stop falling upon hitting the ground. Collision events can be queried; making it possible to fire certain animations in certain situations (crouch upon landing, for example). The physics naturally also apply to particles on screen. You can build more complex physics bodies by combining several existing bodies and you can create constraints to bind separate parts to each other. Perhaps a visual game object building tool for Cool Developer editor will be written at some point.

There are already fully working internal tech demos for the graphics engine and physics. No screenshots for now (as those demos in question render lots of test data on screen).

The Manual
We haven’t formulated full details yet, but a graphical design plan document already exists. As with the V3 manual, we probably won’t be implementing such deep tree view based document structure, but more like a mixture of old design and easier navigation through document pages. We have a few professional web designers in the team, so this time there’s going to be a lot more look and feel to it. While the manual will be written in both English and Finnish, in addition to comprehensive language and framework references, we’re going to focus more on complete tutorials and examples and even in social media and interactive content in general. You will be able to comment the pages, as well. Integrating the manual to Cool Developer so that the two work seamlessly together (in an attempt to provide studying material like never seen before anywhere else) is also one of our top priorities. We have some exciting technologies in mind on how to provide the best manual possible.

The Website
We’re aiming for strong user community. Integrating with the forums and blogs require custom code, and we’re currently building our own CMS (Content Management System) on the CodeIgniter framework. The amount of content we have planned for the new coming website is huge, so its management requires a CMS. It’s a bit too early to provide any screenshots, but the goal is to make the website such a place the users want to visit it in addition to just reading the forums.

Closing words
The information provided by this blog entry was intended to be a general peek of what different sub-projects are involved and what’s their current status. We’ll get back to details later. I hope this delivered some idea of how big of a project the new Cool Game Developing Environment really is. It’s not just CoolBasic Classic, but rather a whole base and framework for future work as well. We have regular internal meetings every other week, after which we normally decide what information we choose to share publically. Sorry for the long wait since the previous blog post, stay tuned.

Game Creation Tools Compiler, Cool VES, CoolBasic Classic, Editor, Language, Manual, Web

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.

Game Creation Tools Compiler, CoolBasic Classic, Misc

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.

Game Creation Tools CoolBasic Classic, Misc

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
Developer
Graphics Artist
Sfx/Music Artist
Forum Administrator
Forum Moderator

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.

Game Creation Tools CoolBasic Classic

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

Game Creation Tools CoolBasic Classic, Web

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.

Game Creation Tools CoolBasic Classic