All the news which are related to any of our tools are listed here.

If you wish to know more about a certain tool, use the Categories menu on the right side, or select a tool from the top-side Menu.

If you wish to see only the headlines, go to the Tools Category.

This is also where you may read about very important announcements we have to make regarding our tools.

There are no important announcements for now.

This video presents overall aspects of the G3 UI Library as well as how I work with it in the development of Alien Invasion.

Version 0.4 of the G3 UI Library is featured in the video, and you’ll be able to see most of its features. You’ll also see a bit of the diagrams and source code behind the G3 UI Library and Alien Invasion.

For a technical presentation of the G3 UI Library, read this article.

And, if you’re curious to demo it, go play with this (older) version 0.2 on the G3 UI website^.

The video’s duration is 6:31.

Usage Instructions: please wait for the Video Player to load. It should not take long. Then, press the gray “Play” button in the middle of the Video Player.

Note: since I don’t own a top-notch microphone, the quality of the audio recording is not stellar.

The Gamaddiction Flash Games Library has just made two very big and important steps forward. During the development of Alien Invasion, I added two more very useful components to it.

The first one is The Archivist. It consists of a Class and an Interface, which are used to persist save-game data for Alien Invasion. I also integrated a Base64 utility Class which I am using to provide a human-readable representation of a save-game, which, in turn, I need for Alien Invasion’s ability to show its save-game data in a nice textbox, from where the user can copy, e-mail and then paste on another computer (since moving Flash Player save-game data can otherwise be quite difficult).

The Archivist Class handles all Flash Player Shared Object writing/reading functionality while the Interface represents the contract which any game object which desires to be saved needs to implement. We will be using The Archivist in all our future Flash games, naturally.

As for the name, I don’t think it needs any explanation. Or does it?

The second component freshly added to the GFGL is The Maratonist. Ok, this naming is perhaps a bit too hard to understand, but perhaps once I’m done explaining what this component does, you’ll see the connection with the word “Marathon”.

The Maratonist is a set of classes which is used by Alien Invasion to interact with the social back-end of various websites, in order to submit high scores, achievements and other such social candy. For now, The Maratonist works with Mochi and Kongregate, but a FaceBook implementation is also on the way.

Actually, I built The Maratonist in the context of a side-project I’m developing with a Norwegian company (after almost a year of focusing purely on Gamaddiction, I start to feel the wind blowing through my pockets, and that’s never good). But The Maratonist was always intended to be used by Alien Invasion for social integration. It’s just a coincidence that my collaboration with the Norwegian company required it first.

So, the GFGL is growing and evolving into a really nice toolset for Flash Games Development. When I feel happy with what it is, I might publish it for non-commercial use, or even Open Source it, who knows?

As unpleasant as this may be, I still have to say it. Development at Epic Game Studio has hit a road-block, namely that we’re simply too busy working at Alien Invasion, The Logicon, the GFG Library and the G3 UI Library.

Alien Invasion can live without Epic Game Studio. The game is pretty complex, but for now, we can deal with the bunch of XMLs from which its game design is configured.

Sure, I’d have liked to do the game design in Epic Game Studio, which would have advanced the project a lot, that is, working in it on an actual game rather than my usual sandbox. But this will probably have to wait for our third game, which, hopefully, will be RoboFite. RoboFite is much better suited for Epic Game Studio. The game is much larger in scope and will feature a continuous post-release development cycle. So having a well-coagulated game design and story will be essential for handling streamlined updates.

Until RoboFite, there is simply no time to continue work at Epic Game Studio, so we’ll focus on finishing what’s on our plate now, that is, the 4 projects I just listed above. The Logicon is actually completed, but small tweaks are still required. Version 2 of the Logicon will probably happen together with RoboFite and version 1 of Epic Game Studio.

I hope that next year around this time Alien Invasion will be long-released and we’ll have found some good financial support for RoboFite, because really, the project is too damn great to leave it hanging for longer than that!

Even if The Logicon has been released more than a month ago, that doesn’t mean that I stopped working at it. Not by a long shot! As a matter of fact, I wrote more lines of code in this past month than I wrote in the previous almost two months.

But the lines I wrote aren’t nearly as “deep” (read: complex) as the ones before. Why? Because I’ve been writing Unit Tests for the Library. LOTS of Unit Tests.

All in all, we got about 12.500 lines of Unit Tests. Yes. That’s 12 thousand 5 hundred ::- D. Which, considering The Logicon has less than 2000 lines of code, is quite a bit ::- ). But there is a reason.

The Logicon is a critical Library. Remember, it is used for EVERY game-play calculation we make in our games. This means that it is extremely important that there are absolutely no mistakes in any calculation, otherwise we might end-up with nasty game-play bugs, and we certainly cannot afford that.

Ok, so now that I finished with the bold-fest, maybe you understand why I tested the library so heavily. I am now quite satisfied with it and I have already started work at the actual game! Alien Invasion is finally on its way to a game portal near you!

However, this is not the end of development for The Logicon. During testing, I made many improvements to it, but I also took note of some improvements which I won’t be able to implement right away. These, plus some new ideas I had, will have to wait until Version 2.0 of The Logicon, which I plan to release sometime in 2012.

While we were busy in the past 2 years coding away at our various games, we failed to see something that was happening right there, under our very noses! A new Project was shaping up. And that project is…

The Gamaddiction Flash Games Library, which consists of a number of very useful classes which we used in Thunderbirdz, the G3 UI Library, RoboFite and now, Alien Invasion.

What’s it made of? For now, just three classes.

The Tools2D class contains various methods which work with the 2D drawing systems of Flash Player. For example there are various methods which work with Sprites and Movie Clips, but also some really nice functions for shape-adaptive hit testing, into which I poured dozens of hours.

The Numeric class, as its name implies, is a class which works with numbers. We use it for various custom number conversions which AS3 does not provide. Most importantly, converting Dates to Numeric or String representations, something we used heavily in our Thunderbirdz weather system.

Last but not least, the Math class contains functions which work with angles, distances, radians, conversions and rotations. This class is the newest addition and I’m still working at it, in the context of Alien Invasion.

It may look a bit chaotic or not too much for now, but trust me, this will become a respectable Project before too long. I got some nice plans in store for it, plans which will take shape as the development of Alien Invasion will kick-start in the following months (as soon as I finish work at The Logicon).

The Logicon is an in-game calculations library. It helps the game developer by taking care of absolutely all in-game calculations regarding: damage, skills, hit points, scoring, experience, level-upping, stats, properties and whatever other term you might imagine and has a number associated with it.

I built the Logicon with Diablo 2 in my mind ::- ). I wanted to create a library with which I could power all computation in a game like Diablo 2. As it turned out, the Logicon went beyond that, increasing my development speed using the XML loaders I integrated in it, which also make it extremely adaptable to game-modding.

The Logicon can be used for any kind of game (hence, the mash-up of terms I used above), written in any programming language. Its small size of only ~1500 lines of code, clear architecture and C-syntax makes it very easy to port in any language. The original code is AS3, as the first game to make use of it is Alien Invasion.

Below, you can see a diagram which shows a simplified structure of The Logicon. The main class has many more methods, but I cut them out for simplicity’s sake. You don’t want to know all the details, do you?

Using Alien Invasion as an example, I’ll explain a few of the general features of this class library.

At the base of The Logicon lies the concept of “Modifier”. A Modifier is, at its rawest form, an object wrapping a Number (Float). There are two types of Modifiers: Base Modifiers and Influence Modifiers. You can probably guess where I’m going with this. To confirm your guess: in Alien Invasion, the hit points of Bunkers and Flying Saucers are Base Modifiers, while the damages of all Weapons are Influence Modifiers.

The Base Modifiers offer a notification function for when their value changes, while the Influence Modifiers also provide various events.

Each Modifier type has an inheritance branch which perfects it and adds nifty new features to it.

Simplified Diagram of The Logicon

The Temporary Base Modifier, as its name implies, will only be in effect for a certain time. It’s useful for temporary boosts. And yes, The Logicon allows modifiers to stack on each other, using a unique Modifier Type ID. Furthermore, Modifiers can be percentile or numeric. And to top it off, they can be organized in Tiers, which allows the percentile Modifiers to be applied only in a certain order. This makes The Logicon extremely versatile.

As its clear name implies, the Perpetual Influence Modifier is used to make sure that a certain Influence Modifier gets applied more times to a target. This could be used for a poisoned arrow, or a weapon that causes bleeding. Influence Modifiers can also be percentile and numeric and can also be organized in Tiers. Of course, they too can be stacked. Furthermore, Influence Modifiers allow automatic randomization, to give you those “sweet” damage ranges you see in so many games.

The Logicon also has some internal logarithmic functions which are used to provide nice, gradually increasing difficulty in level-upping, or exponential-gradient functions with various curves of difficulty, for any imaginable game scenario.

As I completed the first version of The Logicon, I realized that this Library will probably pay a pivotal role in our future games. This is just version 1, and I already have a several optimizations and improvements in store for version 2. A C++/C# port will probably follow, as we (will hopefully) branch out to Unity / other game engines.

A quick update into our progress with the G3 UI Library. I think we can safely say that we’re at about 30% of the way until we reach version 1.0. And by version 1.0 I mean a fully utilizable version, not Alpha or Beta.

The most important Widgets have been added and the Render / Screens system is working perfectly. Among the completed Widgets: Buttons, Labels, Windows, Panels, TextBoxes, Images, Image Rollers, Group Panels and more.

But you know what they say, a picture is worth a thousand words, right? So here’s one from our upcoming G3 UI presentation website:

G3UI Preview

As you can see, we got a fully functional UI Library here! With it, we got a damn good fighting chance to complete some really nice and complex games.

The first game to use the G3 UI Library, will, of course, be Alien Invasion. So make sure you follow the Alien Invasion News Section, because the G3 UI is sure to make more than a few appearances around there!

As soon as the Alien Invasion project was started, it was stopped ::- D. I’m smiling because it’s nothing to be alarmed at. It’s just that… well… the project took an unexpected path ::- ).

As I was laying out the Class Diagram for Alien Invasion in Enterprise Architect, I started to realize that a certain (quite large) part of it is increasingly detachable from the rest of the project.

The part I’m talking about is a series of Classes which are responsible for calculating certain properties of in-game objects. I realized that with a bit of tinkering, I could create a library which we could use in all our future games. And that library is named… *drums*… *trumpets*…

The Logicon

We are still committed to Alien Invasion, and Alex, our designer, is still working at the game’s art. But I will be taking a short detour prior to starting work at the game itself. This detour will consist of finalizing the first version of The Logicon, our in-game arithmetic calculations.

Not to worry, The Logicon is not a huge project. Its size is quite small actually. Barely a handful of classes. However, the Logicon will help us immensely when developing just about any kind of game!

I estimate that I will complete The Logicon in two to four months from now. I will write more information about it when I get there.

It’s time to say a few words about the Epic Game Studio, arguably our most complex project (and, unfortunately, the most neglected – not by choice, but by necessity).

Epic Game Studio is a one-of-a-kind Universal Compiler which uses a common “base language” to transpose pseudo-code into actual code. It accomplishes this by using a Program Definition Database to outline the lexical structure of the Programming Language it will need to output code in; and a Game Database for storing “Epic” data (story, game design elements, etc.). It then translates all this into a very friendly UI, which people without coding skills can use (although a syntactical parser is planned as well).

What’s the purpose of this? Quite simple: to create a tool which ensures complete separation between Game Design and Game Engine. This is possible because you can store absolutely all Game Design Data into an Epic Game Studio Project which you build. When you build it, Epic Game Studio generates code in your format of choice (XML, C++, AS3, SQL, C#, whatever!) which you can then rebuild / import / recompile using your coding IDE. Epic Game Studio can be used by ANY (complex enough) game.

The project is a .Net 4.0 C# Windows.Forms application, with a SQL Compact back-end and extensively uses LINQ. The User Interface is enhanced by employing DevExpress controls and the IconShock icon library (both having been purchased by me during 2009). Epic Game Studio is fully internationalizable, using my C# I18N-by-XML framework.

Epic Game Studio Instruction Editor (CLICK for FULL SIZE Image - New Window)

Epic Game Studio was started in August 2009, but it barely reached version 0.1 before I had to focus on Thunderbirdz’ release and on the G3 UI Library. But, come 2010, I finally had time to shift the project from Visual Studio 2008 to Visual Studio 2010, which was actually a mandatory move, as Visual Studio 2008′s Entity Framework had no “insert” support for the SQL Compact Database I was using. Visual Studio 2010 added the required support so I was able to finally make changes to the SQL Compact Database rather than just have read-only access to it.

In August, almost a year after commencing the project (although less than 150 hours of work in it), I finally, I managed to reach a solid milestone with Epic Game Studio: data can be saved back into the database. That, made it possible for the Instruction Editor above to work. And, for the first time, the Build Workflow is able to compile the programs into target code!

A must-have of the 0.2 milestone was to give Epic Game Studio the ability to actually compile data from its two databases (the Language database and the Game database) into meaningful program code, as defined by the Language Database. This is achieved by using the Program Editor which can be seen below.

The Program Editor is that “user friendly” way of crafting code which I mentioned earlier. Granted, what “user friendly” means to a Microsoft Word user is a programmer’s hell. And since most game designers have programming background, that could be a problem. It’s something I intend to address by implementing a lexical interpreter.

Epic Game Studio Program Editor (CLICK for FULL SIZE Image - New Window)

Below, you can see the Build panel. This is where the Magyqck happens! Each Instruction Folder or Instruction Group in your Program can be output into its own separate Folder or File.

The custom Workflow button (visible but not functional) is used to add additional External Tools to your Compilation Process. This makes Epic Game Studio able to work with a countless number of external programs, sending parameters to them and accepting parameters back from them.

For example, Epic Game Studio could be used to generate a SQL script, after which it would call a little program you wrote which takes that SQL script, can do additional modifications to it and run it against the correct database. Or it can generate some files and then call a program of yours to upload them to an FTP. The list can go on. And on. And on.

Epic Game Studio Build & Workflow (CLICK for FULL SIZE Image - New Window)

Here is a little sneak peek at how Epic Game Studio works on the inside. This is a Language Database. Here, the Instructions and Data Types known by the Language are stored. Epic Game Studio is able to work with Numeric and Text data types, but can also understand any combination of such types, through the use of Advanced Data Types, visible in one of the tables below.

The diagram is not complete because this is, after all, a commercial product. However, if things go well with Gamaddiction in the following years, it may see a Community Edition as well. I have a great respect for the indie developers community. Because I came from there.

Epic Game Studio Language Database

This other diagram shows a portion of the Game Database. This is where your Game Design data goes. The data can be organized in Folders, Groups and Procedures. Here, you may define Variables and use them in Instructions. The Value Entries table is used to store the values of Variables, as well as instant-declaration values.

Epic Game Studio Game Database

Well, I think this is a healthy preview for Epic Game Studio so, for now, I’ll leave you with a sexy screenshot of the program’s Main Menu. And, if you noticed that in the Title Bar it says “Epic Game Studio 0.3″ (as opposed to the 0.2 in the title of this entry), that’s because it’s the version which is in work right now.

If you have any questions regarding this project, feel free to Contact Us.

More news, as we produce them ::- ).

Epic Game Studio Menu (CLICK for FULL SIZE Image - New Window)

It’s time to say a few more things about our Great Graphical Gear User Interface Library. Boy, isn’t that a mouthful? ::- D.

The G3 UI Library is a simplified, game-oriented alternative to Adobe’s Flex. There are huge differences between what a game demands of a UI Library and what a business applications framework (which is what Flex really is) can offer. The “F” in Flex is for “Fat”. It’s huge, eats up a ton of memory and its a pain to /really/ customize. And by /really/ customize, I mean the enormous differences between the UI of two games.

But this is not to say that Flex is bad. On the contrary. The fat guy has its strengths, but the fact that it was conceived for a certain application domain cannot be changed so easily. Just like the G3 UI Library is not meant to be used for business applications. However, the G3 UI Library could scale up to business while Flex can’t scale down to games.

The class structure of the Library allows for a complete separation of functionality and design, through the use of template methods and other design patterns. The “Skinnable/Metallic” part of the library, which also draws the Widgets, does so using the most primitive objects in AS3 (Shape, Display Object), allowing for a very light memory footprint.

Besides, creating a UI Library was a challenging task and it immediately peeked my interest and I was curious how I could pull it off. I built my last UI library in procedural Pascal 12 years earlier, and naming that, a “UI library” is a not fair, all it could do was square, bland buttons.

I realized that this is no easy undertaking and that I’ll probably have to invest many months of work. But I’ve seen many games which employ Flex controls. They all have the same bugs, the same functionality caveats and the same ridiculous memory usage, sluggish UI performance and poor rendering. I wasn’t happy to take that route.

So, given the poor choice of alternatives for a pure-AS3 UI library, I’ve decided to roll my own! Enter the Great Graphical Gear User Interface Library. What a mouthful, eh? That’s why when we talk about it amongst ourselves, we lovingly call it simply G3 UI.

G3 UI Core

The structure of the G3 UI Lib is based on the trusted Abstract Factory Design Pattern, which is the best structure to use when dealing with User Interface Libraries.

At the core of the G3 UI, we got the G3Director static class, which contains several global management function which control the UI Engine.

Then, we got the Renderer Interface, which allows the G3 UI to be rendered in any kind of Display Object Container (the Stage, a Sprite, a Movie Clip).

The G3Designer Interface is used in enabling the Model-View-Controller way of working with User Interfaces. We do that using Designer Files which contain all the UI code. This is similar to how Microsoft implemented things in Visual Studio. As a matter of fact, the G3 UI has its own special UI Designer which I wrote in C# (compilable with the Mono Framework, to ensure cross-platform support).

Not present in the Diagram segment above is the G3LayerManager, a very useful class: it’s a Z-Index organization engine which is used in all our Flash Games and, now, in the G3 UI as well. The LayerManager is an extremely versatile tool, completely removing the worry of ever calling functions such as setChildIndex and swapChildren.

G3 UI Abstract Factory

Here, you can see how the Abstract Factory pattern is implemented on a few Widgets in the G3 UI. The base class is, of course, the G3Widget.

G3Widget is, in turn, extended into Buttons, Panels, Radio Buttons and so on. These constitute the actual User Interface Elements which comprise the G3 UI Library. But, by themselves, they are aspect-less.

Only the last tier of Widgets can actually be constructed and used. In the above Diagram, you can see the “Barren” variety, while the “Metallic” variety is not shown. “Barren” and “Metallic” are two very different UI styles.

“Metallic” comes with its own drawing functions while “Barren” forces the user to custom draw everything and provide only the names of the sub-components so that the G3 UI Library injects its functionality in them. Actually, this will be renamed into “Inject”, which is more relevant to its real use.

You can see two G3Constructors: Barren and Metallic, but the library supports unlimited customization, which is not only restricted to UI, but also allows modifications in the behavior of the base Widgets.

G3 UI Widgets - Part 1

In this Diagram segment, you can see a part of the G3 UI Widget hierarchy. This part focuses on Panels and Images.

The Image is a rather special case, as it required me to use loosely coupled interfaces to pull it off. This is because the Border of an Image is at the base of both Image and ImageRoller, but we get into considerable (read: impossible to solve) trouble when we wish to conciliate that with the fact that both Image and ImageRoller can have any number of child classes. The result is that the Border class cannot be abstracted unless its extracted from the inheritance chain of Image and ImageRoller.

The solution was to indeed remove the ImageBorder from the inheritance chain. But I still managed to make it inheritable, by using the concept of a Border Renderer, which is a per-Constructor class. Images and ImageRollers require a Border Renderer which to do the border rendering for them.

G3 UI Widgets - Part 2

Here’s another segment from the G3 UI Widget hierarchy. Enjoy it while it lasts. In total, there are about 20 Widgets right now in the G3 UI Library.

UPDATE 2012-01-27: see the architecture in action! Version 0.4 of the G3 UI Library, which is featured in our 2011 game, Alien Invasion, has gone a long way from we were in 2010. Click here to see some Alien Invasion videos.

There is also a fully functional demo of the G3 UI Library^ (version 0.2) on its own website.

If there was anything Thunderbirdz (our first game) made clear, is that you can’t build a game without a proper UI library. Well, Thunderbirdz did make and is making a few more other points, but that’s beside… the point ::- ). Right now, we got an announcement to make.

Me and Gabi “DiAngelo” Balasz started work at a UI library for ActionScript 3, which we are calling the G3. Why G3? Well, because it’s both ActionScript 3 and also because it’s some Great Graphical Gear!

Sure, you could argue that there already is a big UI library for Flash Player: Adobe’s Flex. In that case, I’d argue that Flex is an elephant targeted mostly at business applications and I don’t want to have anything to do with it. I saw plenty of games using Flex and I was utterly disappointed in the sluggish performance they offered.

No, I think we’ll roll our own. Lean and mean, super-customizable, targeted for game developers! That’s the G3 UI Library, at which design work started today, with the first diagrams I’m building in Enterprise Architect.

The motivations behind the G3 UI Library can be found within our own Gamaddiction: we want to continue making games. We are here to stay! In order to facilitate our stay and improve our quality, we need to start building our own tools, because, I believe, that’s what any proper game studio should do.

For now, we got Epic Game Studio (which is temporarily stagnating due to budget constraints) and a bunch of utility classes I developed during Thunderbirdz.

So today marks the first day of development for the G3 UI. It will power all our future Flash Player-powered games. Now that Thunderbirdz has been released, I am currently in planning stages with a new game, but more about that, soon.

The development of Thunderbirds goes well and it fills me with hope for the future. I have lots of new game ideas and I’m full of energy and enthusiasm. Unfortunately, budget, as always, is not unlimited. Therefore, we (me and everybody involved in Gamaddiction) must be very careful in what we invest our time.

And when time is so limited, we always try to make the best of it. One way is to work more efficiently. Another is to buy new time. Since we don’t have the money normally required to buy new time, what if we build a really cool tool which would save time, therefore, win us time?

Such a tool is Epic Game Studio. This project was initially born out of my necessity to work with a very weird scripting language called ERM. ERM (Event Related Model) is a script created by Russian Slava Salnikov and his international team for the now-defunct game Heroes 3. They hacked the game’s executable in a wonderful way, adding fantastic flexibility for map makers.

Unfortunately, ERM syntax looks like it came from space. Check this out!

!?CM2;
!!CM:I?v98;
!!CM&v98>67/v98<75/60:R1;
!!CM&v98>10/v98<13/61:R1;

Yeah, that’s what I thought ::- D.

As my Heroes 3 map became increasingly complex, I had to build a C# tool to manage some of the code, because writing in Notepad or the rather primitive ERM editors wasn’t good enough. But, eventually, my map became too complex even for that!

Then, I paused all my Heroes 3 activities to focus on Thunderbirdz and my own game development career. And this brings us to Epic Game Studio.

Epic Game Studio is a monster project which will not only help me to finish my Heroes 3 project (whenever that will be), but will also allow us to create very complex games. The entire Gamaddiction team will be able to take part in the creative process of game design because working with Epic Game Studio will not necessitate programming skills.

Epic Game Studio is a tool which will speed up development for all our upcoming titles. It is one of our aces in the hole through which we intend to buy the precious time which for an indie developer is worth millions of times more than for big buck studios.

More news about Epic Game Studio will be delivered… as we produce it ::- D.