Cool (Game) Developer

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 CoolBasic Meet 2010

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.

The compiler FrontEnd is now finished!

Hello again! As I promised last time, I have two big announcements to make. Even though summer has been warm and beautiful, I’ve been working very hard on CoolBasic compiler for the past few weeks. We’re talking about something like 8 hours aday on average, but there were also a few of those days during which I coded 11 hours pretty much non-stop. And it’s been great! Even though most of the work has been nothing but bug fixes, my motivation has all but diminished. Some people might think otherwise, but I actually get encouraged by intriguing bugs that take 24 hours to track down because it’s very rewarding to ultimately fix those.

I don’t normally mention about bugs I’ve found and fixed, but be it exception this time: I had a medium-sized architectural issue regarding method invocation and how the reference is passed to them. Static methods and structure methods add an extra twist. The original implementation had fixed stack position for the reference – which ultimately proved to not work out for complex dot notations that involve static members in the middle. I fixed the problem by re-writing the part that is responsible for recognizing valid references and injecting them into the final code. References are now always at the same relative location they appear in the original statement. Even static methods now have them although those don’t necessarily point to anything. Long and complex dot notation paths in general have been giving me quite a lot of work recently.

The first announcement
I’m proud to announce that I have now finished the Intermediate Language (later referred to as “IL”) entirely. This effectively concludes Pass#2 and thus the compiler FrontEnd is now considered “finished”. It’s been of a long road, and reaching this major milestone is a great relief to me. What this means in terms of progress? The IL still needs yet another transformation, but this time it’ll be final. So basically there’s just one process to make for the compiler, and then I can start working on the runtime. Also, it’s July already, and I think the devTeam won’t be assembled this summer but in autumn perhaps. There just is so much work to do, sorry. I’m about a month late of the original schedule I had. But I’d say it’s normal because in program of this nature surprises tend to emerge. Some of which force medium-to-large re-writes of existing code. Modifications always affect somewhere else and thus extensive testing needs to be done after architectural changes – be it minor or major. Thankfully, I didn’t have to implement major changes to anything (atleast not just yet).

I spent 5 days (there were quite many bug discoveries and fixes involved) to write an extensive array of Unit Tests. A Unit Test is basically a standalone fragment of code that responds to input and output; they are used to test program functionality isolated from the big picture, and each test runs in its own sandbox. These small programs I wrote, test all CoolBasic programming language features. After compilation I examined the emitted IL in detail and ensured that everything went well and that the IL was correct. As a result of this process, I gathered interesting data and statistics I’d like to share with you. I think the numbers speak for themselves:

Test Program:

– Code size: 2547 lines in 7 files, 62 kb in total
– Composition: natural mix of comments, declarations and executing code. All language features
– Symbol table size: 1150 identifiers
– Emitted IL: 7410 lines

Testing Platform:

– HP HDX18-1000EO (Laptop)
– T9400 processor
– 4GB memory
– Windows Vista (64-bit)


– Number of compilations: 20
– Average compile time: 105 milliseconds
– Fastest compile time: 97 milliseconds

That’s pretty fast compilation considering the complexity of the process. Overall I’m happy with the outcome and that “pressure test”. I’ll be using the same gigantic Unit Test program to validate everything when any new feature gets added later on.

The second announcement
Now that the pressure is mostly gone, there’s something completely different I need to do: I still haven’t finished my thesis, so I’m technically still a student. That’s something I’ll soon need to take care of as the official time limit of graduation is closing to its end (and I don’t wish to extend it). As some of you may know, I already work as professional software engineer, so that’s taken some time and focus off the studies. The only thing remaining (and the only reason I’m still in their register as “pending graduation”) is the unfinished thesis. So I’ll take a few weeks off CoolBasic, and finish up my studies in Bachelor of Business Administration in Information Technology. Graduation and receival of the official “shiny paper” will also be a great relief, and after that I can fully focus on CoolBasic once again. I will start the thesis from a blank table very soon. During this time, however, I will be watching the forums, and am available via IRC (nothing new there). My four-week summer holiday is starting on 20th July so I have lots of resources to use on the thesis (although I don’t wish to spend all the summer indoors). I will also be participating in Assembly Summer 2009 this year!

Some random thoughts
I reviewed CoolBasic V3 manual. After careful consideration, I came to conclusion that the black theme is unfitting to such material that is to become the primary textual source of information for Coolbasic V3. Although silver text is still very readable on black background, you can actually read dark text on white background longer without the eyes growing tired. I’ve taken a little more MSDN-like approach although I plan to enhance the visual look and feel.

It’d be cool to allow the online manual to be somewhat interactive and more dynamic. Features such as User Comments, Version History, Multilinguality, and linking to outside sources as well as flexible Maintainability will basically require a database. Thus, online version of the manual is best to separate from offline version. I’d still like to use XSLT for the offline manual, but then the end users couldn’t use Firefox to view it – or otherwise I’d have to make the manual very dull looking basically ignoring text styling within paragraphs. So there’s still some open questions to the offline version, but database approach for the online manual certainly looks quite promising. Either way, it’s always possible to generate the offline manual directly from the database. Database design, however, will be a challenge!

Enjoy the summer, folks!

Sneak Peek: CoolBasic V3 manual

In parallel to compiler development, I have been designing the future-coming CoolBasic user manual for the past few weeks. I still use nearly 100% of developing time on the compiler, but the technical solution for the user manual is something I should keep an eye on as early as possible. Nothing too fancy, but I think it’s decided now how I’ll implement the manual (I have a working prototype already). Just like in the current version, the new manual will also be based on webpages. The exact same manual will be accessible both online and offline. You will be able to choose which version is the default when you access the manual from the editor. This way the end user can see always up-to-date online version if he/she chooses so, although the offline content will be updated regularly as well. It’s still uncertain whether or not those users who have a forum account, could write comments on the online manual pages.

Since the exact same manual is also available online, I must ensure that it’ll render the same way on all of the popular web browsers. This has been given me some headache. The offline manual relies on Internet Explorer WebBrowser control anyways, but as it’s well-known fact, IE doesn’t really follow the standards very well – especially IE6! A fresh statistics on indicate that 1/4 of all Internet users worldwide still use IE6 as their primary web browser. Basically this means that the manual must support atleast IE6. This sets some limits and workarounds I have to consider when I design the CSS and the dynamic functionality for the manual. I test the manual with IE6, IE7, IE8, Opera 9.6, Opera 10, Firefox 3.0 and Safari 4. For some reason, I couldn’t be arsed to install Google Chrome yet. Also, comes to good use.

There’s always atleast one browser that fails to function like the rest. IE defines its own standards, naming attributes differently in javascript. Some browsers just function differently in some javascript cases, for example the “name” or “id” attributes combined with “getElementByName”. Frames render differently no matter how you define the borders. And then there’s Firefox that refuses to disable escaping in XSLT despite all the whine that has been roaming for several years now. Due to all this, I had to write some “hacks”. But atleast it works now. Why can’t all browsers just follow the darn standards! Why must they define their own rules that only apply to them and not to any of the rest!

Enough whining, let’s talk about something else… like the looks of V3 manual! There will be a treeview. The manual will be hierarchical. As opposed to the current manual, you can now see the entire path to the currently open page, as well as easily change to other articles that belong to the same context. The treeview operates in an intelligent manner, making sure the expanded listing will not grow too big; only the relevant contents will be shown, the rest of the pages always remain collapsed. Some users, however, like to browse the treeview with several separate parent nodes open at the same time. This isn’t possible because of the intelligent collapsing (and it’s intended), so to help browsing back, there is a “breadcrumb”-like collection of recent pages at the top side of the manual. This collection updates dynamically, reorganizing itself so that duplicate elements don’t appear.

The color scheme will probably be the same as the current placeholder website (it looks so cool) with black background. I’ve made some minor improvements to the style sheet so that the layout fits better for manual pages. Captions will be aligned to the left, and their colour is now Orange. Links will remain blue. Text is still light silver. Emphasized text is now bright white and bold as opposed to current orange colour. In other words, every colour has it’s own, unique meaning. The test pages I have look very good at the moment. I also tried pastel colours with white background, but somehow it doesn’t look as good. The code editor will have white background, but this doesn’t fit to the dark theme of the manual. Therefore I’ll have to reconsider the source code colours for manual pages. More about that later.

Although the prototype is there, I won’t provide a screenshot just yet. There’s still tweaking to be done. I’m probably going back to 100% spent developing time on the compiler.

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