2014-0816

VERY TEMPORARY

Comments Off on VERY TEMPORARY[Author: Category: Game Creation Tools ]

Today I’m going to talk about some old stuff. Don’t worry though, most of you haven’t seen it yet. A year ago, at our traditional summer meeting, I demoed some very early and experimental CoolBasic builds. The reason I want to show code and screens this old, is so that it’s easier to explain about how things have since changed in the future coming blog posts.

Back in 2013 I actually had a working environment that consisted of a code editor, CoolBasic compiler, and a debugging runtime. You could write CoolBasic code, pass it to the compiler and finally execute it. It couldn’t render game graphics or play sounds, but the very basic text input and output was in place. At that time I focused on code execution rather than game libraries. Control structures, strings, arrays, types, operators, all that kind of stuff. As a result, the demo was probably very boring to watch, but hey, at least it was executing something!

The Compiler

The compiler was naturally the number one priority to get done. In refreshment, it’s written in C#, running on .NET CLR and Mono, and is a standalone console application so it can be called from anywhere. It wasn’t feature complete back then (for example, Select…Case was missing,) but it could handle most control structures and generate the final bytecode.

Compilers aren’t very exciting, though. All you need to know is it’s now faster, more feature-rich, and hasn’t got a function limit.

A VERY TEMPORARY Editor

The VERY TEMPORARY editor

Before you go to the forums and start complaining about how awful it looks, mind the window title. Guess why it’s called “VERY TEMPORARY EDITOR”. The caps are intended. This will *not* be the editor that will ship – don’t worry. I promise.

In short, I just wanted to test a) how easy it is to integrate the compiler into an IDE, and b) could I perhaps use AvalonEdit as the editing control as opposed to the commercial Actipro SyntaxEditor. I’m already quite familiar with the Actipro component (had a chance to use it in a work project) and I know it is the state-of-the-art option, but perhaps that would be a little bit of an overkill for my purposes.

As it turns out, AvalonEdit is just perfect, at least for the starters; I can always upgrade to Actipro later. AvalonEdit offers configurable syntax highlighting out of the box, supports code completion popups, and is generally fairly extendable. Syntax highlighting definition is loaded from an external XML file, and the list of commands provided by the game engine is imported from a special “framework definition file” that I can generate automatically off a compiled executable or DLL (via reflection.)

It was pretty easy to invoke the compiler, have its output written in a textbox, and parse off any errors it would report. All in all, a successful little test editor.

A VERY TEMPORARY Runtime

The VERY TEMPORARY runtime

That’s not a real game engine. It’s actually just a normal WPF application powered by the new Cool VES virtual machine. In fact, the only available commands are Print, Input, and Timer (for benchmarking.) The intention was to establish a simple “console” which would provide basic input and output so that I could test that the virtual machine doesn’t corrupt the virtual stack or leak memory at any point.

For this reason there are some debugging features available. At any time, I can click this cute pause button:

The pause button

This will halt the virtual machine that’s executing the code. While paused, this UI becomes available:

Metadata: symbols

Debug info: metadata

This view lists all functions and variables and their types. Symbol information is needed for a number of reasons. Firstly, the debugger can emit more meaningful call stacks when the functions’ names are known. Secondly, the runtime can perform proper clean-up when returning from a function as it knows which resources are stored in heap.

Bytecode

Debug info: disassembled program

This listing represents the current program in its “disassembled” form. Here I can see that the program was decoded properly and matches with what the compiler spat out.

Managed resources

Debug info: managed resources

Remember how LoadImage would return a handle that you’d then store into a variable for later use? These handles are called “Resources” internally in Cool VES. For more efficient memory management Cool VES keeps a list on what has been loaded. It’s not a real (unmanaged) memory pointer, but a reference to an internal object that also contains metadata of that object.

Interestingly, also strings are managed resources and they, too have handles that are manipulated every time a string is stored in and consumed off the stack.

Call stack and locals

Debug info: virtual stack

If I want to see the low-level state about the executing program, this is the view I’m interested in. I can inspect the values of each variable, for each function within the call stack. This information, of course, would be presented in a more intuitive way in a real debugger.

So that’s how things were a year ago. Nowadays the compiler is pretty much feature complete, and the real code editor is in the works. I also did some engine experiments based on the DirectX10 interface (initially on DX11, but for whatever reason DirectWrite that I use for text rendering isn’t easily usable in it.) More on these topics in future coming posts.

Tags: , ,
2010-1004

Framework Definition Files

Comments Off on Framework Definition Files[Author: Category: Uncategorized ]

The purpose
Ok, so I think it’s finally time to introduce something I’ve been working on for the past several weeks. This is actually one of the two “bigger” things that I referred to in my previous blog post. As I’ve been hinting a couple of times already, one of our strategies is to design our future coming game making tools in such a way that they’re as modular as possible. That is, we want the languages (such as CoolBasic Classic) to be separate from game engines (such as Cool VES) so that a language is merely a tool to write programs and the user can choose the target framework that best suits his/her needs. This also dictates that language compilers should not be directly dependent from the target execution system (read Virtual Machine). CoolBasic Classic, as a language, thus doesn’t really know about the functions and constants or any other type of symbols that are available in, say, Cool VES game engine. For example, unless explicitly specified, you couldn’t call LoadObject or PlaySound from CoolBasic Classic source, unless you wrote those functions yourself.

So you have to tell somehow to CoolBasic Classic compiler that these functions exist and how to invoke them. What happens under the hood, is that instead of executing CoolBasic source, a game engine (Cool VES) procedure shall be invoked. This is where the Framework Definition Files come in handy. As a part of Cool VES installation, this file is provided. The definition file is passed to the compiler during build operation. It contains a list of function and constant symbols that will get imported to the compiler’s symbol table to begin with. In this way, the compiler is able to recognize those services provided by the target framework, in our case Cool VES game engine.

There are two types of definition files: one is XML and the other is binary. They both host the exact same information about symbols. The XML format is intended for easy reading, and it can be consumed by 3rd party applications. Also, Cool Developer editor reads symbol listings from the XML file so it can highlight the code properly. However, parsing XML can be a bit slowish, and doing so every time we want to build and run our game will be an overkill, simply put. Luckily, the binary format is designed for fast reading and parsing, containing offsets for fast file seeking. The data is stored there as a structured tree so that full scope info is retained. We are planning to publish the binary format specifications (yes, a public document) at some point too, but this information is, of course, subject to change.

The editor application
Needless to say, we needed an editor to create and maintain these definition files. So I created a neat application for that. It’s an internal tool that the DevTeam uses, thus it’s not available to public. This hasn’t prevented it ending up being a quality piece of software, though, and I’ve actually put a bit more time on it than I originally planned. But that just makes a point, eh? We drive for quality! Quality takes time, but in the end, it’ll be worth it. This is how the editor looks:

Cool Framework Definition Editor 0.9

It’s been written in C# (.NET framework 4.0), and that cool dark appearance (something like that will be in Cool Developer’s theme collection, too) is the Expression Dark theme, from Microsoft (and it’s also available for free at codeplex.com).

The video
As a bonus, I decided to try something new, and managed to conjure up something I think can be considered a video. That’s right, I made my first video ever, and put it on YouTube! I have absolutely zero skill and experience in video recording, editing, encoding, and presentation in general. It’s narrated in english (which is not my primary language), and I found out the hard way just exactly how difficult making a video like this can be. Despite careful planning and preparation, I found it surprisingly hard to not begin to stutter midway or how to keep your speech fluent without any moments of disturbing silence. Before the actual presentation, I actually wrote a 2,300 word transcript, but as soon as I got started with the presentation, I noticed I actually had no time to read anything (despite I’d learned half of it by heart). So I ended up improvising it all to the end.

Making the video took me all evening, and I learned how to zoom the screen only after uploading it on YouTube. All in all, I’m pleased to the outcome, but now I know how to do it better next time. Enjoy this 15 minute long demonstration (I recommend watching it in 720p, and yes I know it’s still blurry):

There’s also another video coming, stay tuned!

Tags:
2010-0816

Cool VES Game Engine

Comments Off on Cool VES Game Engine[Author: Category: Game Creation Tools ]

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):
Graphics demos

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):
Graphics demos

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.

Tags: ,
2010-0629

Cool (Game) Developer

Comments Off on Cool (Game) Developer[Author: Category: Game Creation Tools ]

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.

Tags: , , , , , ,

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