Archive for the ‘Bold Pixel Engine’ tag

Bold Pixel’s Namespaces and Interfaces

After much thought and discussion by myself or at the FGL chat I made some decisions about how to make Bold Pixel more modular in order to simplify my own work. Since we are still on top of contracts, I couldn’t give enough attention to this but my brain was dealing with it in the background.

Inheritance Spaghetti

The problem presented was somewhat simple. My early coding of the blit engine got tangled in the dreadful inheritance headaches. My solution to it was to create one class per major responsibility. It worked fine until the time I decided to expand one of the classes to do something it wasn’t designed to do. So on one hand I solved the inheritance problems but on the other I lost modularity. At this time I had a OOP doubt that I expressed in the FGL forums and the discussion that started there really helped me to move in a different direction, one that I had never considered.

More over I said that I would not support requests that didn’t deal with deal with real problems we had in our own development. And while I stick to that, I couldn’t help but to think: what if Bold Pixel could help someone but it missed one little tiny feature? While this was puzzling me, there was real problem, one with impact in our development that was taunting me…

The case of Blit vs Physics

So Bold Pixel has a blit engine and it will wrap a physics engine (more about the physics engine this later this month) so the question that was on top of the table was: considering there is a blit entity and a physics entity, which one should access the other? Whatever the answer was, modularity was lost in the sense I imagine it. I don’t want blit to know physics and I don’t want physics to know blit!

After a nice chat with Antriel at FGL (thanks mate!) I got to know the Strategy Pattern and all my problems were solved. In simple terms, I will be defining interfaces for all interchangeable objects but the implementations of the interfaces can exist anywhere. In the case presented, a blit entity will have its spatial properties (rotation, x, y and scale) defined by a spatial interface. By default it will be a simple class and it’s needed since the properties of the spatial interface are needed to render bitmapdata. A physics entity will be a implementation of  the spatial interface, so if I want to use physics on a blit entity, I simply write: myBlitEntity.position = myPhysicsEntity;

Visibility and Access Issues

This brought another problem. Bold Pixel has always kept its inner “stuff” hidden. The objective was this was to keep the auto-completion short and the use easy preventing mistakes. In order to implement interfaces I would have to make a lot of code public.

The answer to this would be abstract classes, but ActionScript3 does not support it. That will be addressed with simple naming and convention over configuration. Any class in any namespace in Bold Pixel that starts with Abstract will only have the simplest shortest implementation needed for something to work. For instance, if I want a blit entity that draws pixels I will have to extend a AbstractBlitEntity class (I guess that will be the name) but that brings another problem…

So ActionScript does not support abstract classes… convention will say that Abstract defines an abstract class.

Namespaces (to wrap this up!)

To have a better code organization I will need more packages and to have more packages I will need to provide access to classes in different packages. This will be done with namespaces. The only thing that annoys me is that Flash Develop in the current version (3.2.2) does not support code-completion with custom namespaces, but what matters is that using custom namespaces solves two problems. First I can have a bunch of private functionality like I like, but second, any coder can with a simple namespace use extend Bold Pixel to his own needs in a full modular way.

While I reckon that this is all just in my head and that a lot of work will have to be done and even considering that probably this will make Bold Pixel a little bit more complicated to the average coder, I feel it sorts a lot of questions, so: Namespaces and Interfaces FTW!

Bold Pixel Engine v1 Post Mortem

I guess it’s pretty strange to have a post mortem of something that is not a game, but Bold Pixel Engine, in its first version was a fantastic learning experience, but it had a overwhelming amount of failures also. To sort my thoughts I checked the tag of the engine in our blog and read some of the stuff that happened as time passed. This led me to write this post mortem, on one hand to know exactly what is right about it, on the other hand to learn from our own mistakes.

A bit of historical perspective

Bold Pixel Engine started with our first flash game because of a simple music management class. Back then, both me and Diogo were coding and I remember (and I admit I deeply miss) our discussions about code standards and organization. I’m a bit of a dictator when it comes to have stuff organized, credits to Marco that has used the word “dictator” more than once and with a large amount of reason and giggles.

Soon our bunch of classes were our own internal library and I even posted some of my own experience while organizing that library. Some of the most important definitions of Bold Pixel where then starting to emerge. July 27th 2009 we announced Bold Pixel Engine was alive.

I was quite excited about it!

The turning page from internal library to public engine was the blit engine. We had so much help from many amazing developers that we would not keep it for ourselves. We wanted to share, we wanted to hear what others had to say and that’s what we did. After two games under his belt and a lot of opinions, the engine was publicly available and his version 1 life was pretty much that until the version 2 turning point a couple of months ago… but I’ll get to that eventually.

What went right!

The learning process was amazing code wise. After Diogo left I really had to raise my standards and get to work and the engine allowed that. Coding such a piece of technology made me contradict myself several times and pushed me forward. I’m absolutely convinced that I am a much better ActionScript programmer now than I was before and I feel I learnt little from the games but a lot from the engine because I forced myself to respect the principles I wanted to see applied to it.

And speaking of principles, these stay true from the first line of code until today and are something that really went right. And these are:

Convention over configuration: Bold Pixel Engine is written assuming some conventions. For example, if the programmer tells the Scene Manager to create a new scene, the previous one and all dialogs will be removed, which makes a lot of sense but maybe it makes less sense to say that all scenes have their pivot point at 0,0. This means that scenes and dialogs are simply added to the display list and that’s it, nothing to configure since there is a convention.

Ease of Use: This goes hand in hand with convention over configuration. If there’s something that really makes my head hurt is to look at the code needed to make something happen in libraries like Flixel and Box2D. I appreciate the effort put in these libraries and the flexibility and power provided but I believe that if we have to configure every single tiny detail the code becomes cryptic and extremely difficult to debug. I don’t mind loosing flexibility because I will create more mechanisms that will help me achieve my goals as time goes by.

Modularity: There is only one dependency in Bold Pixel Engine, which is the Manager class. If you want a single loop or to manage scenes and dialogs, you need to start it up. Apart from that Bold Pixel Engine started modular and will stay modular. The reasoning behind this were two questions I made once:

1. What if I don’t want to use the blit engine?
2. What if I want to add something that will wreck dependencies?

The answer to that was that I wanted it to be flexible, meaning, I can use whatever I want with only one dependency and that’s it. I don’t want the engine to behave like an engine. I want it to be a toolkit at my disposal. I even had a laugh about this.

What went wrong…

First and worst aspect of thing that went wrong was that I did too much stuff that we didn’t need that was requested and I didn’t do it with the same dedication I did the rest. That will never happen again. I’m convinced I got carried away by the kindness of a lot of devs, but we can’t have the engine restricted to the needs of others, which was something I said it wouldn’t happen from start. But what it really makes me feel bad about it was that other devs got involved in the project and this collided with either our work or their work making it a bad solution for everyone.

The second thing that went wrong was that I overcomplicated somethings because I felt it made sense. For instance there is a Scene Manager and a Input Manager and a Manager. All of these managers depend of a Display Object and/or its stage. While it sounds easier to manage code and it looks more tidy and clean, having a gazilion classes doesn’t make it easier to code with. I found myself looking through the classes to find what I wanted… that doesn’t sound like a good thing, right? I mean, I coded it!

And last but not least, I think I really rushed things. The idea behind the public releases of the engine were that we would make two games between each release, which we actually did with v1, but as soon as I had the mechanics ready and all the engine’s juicy code was on a actual project, I went head over heels with it. It lacked documentation, it lacked cross-testing (so, just because I did two games, I should have tried against the two games again) and most important it lacked a critical look and a some honest and critical analysis.

Conclusions

Great experience and I really appreciate all the kind words that I got from developers. I think the really cool thing that most developers got from it was the ease of use, probably the YouTube channel with some nice overview on it. I could’ve written a post trying to sell the idea that we are overwhelmed with joy and l33tness, but I would be failing to be honest. I truly believe that BPE v1 is a great piece of software, but I was naive in the approach and maybe over-friendly in the “pleasing my fellow devs” department.

We have a game going with v2 and I think I sorted my doubts about what is going to happen with the engine. Many things that were wrong with v1 are already gone and there is a lot of stuff that isn’t even started, like moving the Music class which started all this into the current version.

There’s a lot to be said about v2, but this is a hell of a long post mortem and I’ll write about that soon.

Random thoughts on life and code

Been a while since I write here. This post will be a bit like therapy.

So life is treating us so-so. A couple of contracts are approaching the end and after speaking with Marco we concluded that we won’t be doing contract work for a good while. We have too many good stuff right now to work on that has caught way too much dust.

Looking back over the past few months, a lot of what we did was neglected because of contracts. They were alright in a way, some for the money, some for the knowledge, some for something else. But unlike our own games, there’s always a part that is missing, regardless of how good the project is. We feel that has to stop and that what moves us forward is our ability to pursue what we want: pride and happyness.

I also feel that both can go hand in hand with stability and stability is what we found in the past months. We need to step up and do our thing. We need to improve what we did for us.

Project wise, that means that we have to put Hajime on FGL, we have to decided what we want for M:A:D and we have to have time for our most promising game. Code wise this means that I have to reflect if we want to keep Bold Pixel public considering that the current version suits our needs more than it suits the initial user friendliness. I strive to keep things simple, to impose convention over configuration as a standard. Right now I’m not that sure that this will fit developers needs to the point that BPE is helpful.

We’ll see about that in the next couple of weeks. Thanks for reading and the therapy session.

Vlad out!

Bold Pixel Engine v2 Annoucement

Hi everyone, just a quick note to let you know of some stuff going on regarding Bold Pixel Engine.

Collaboration with Arne G. Strout

It really felt great to hear about a developer wanting to build on BPE to make it go further. That’s what I felt when I read Arne G. Strout blog post about BPE. Under the spirit of open-source, Arne offered a great deal of thought and ideas regarding our little framework.

In the meantime, v2 was already under way so we exchanged some ideas and I’m pleased to announce that Arne will be collaborating in v2 development.

Box2D integration…

Wrapping Box2D in a minimalist Bold Pixel Engine kind of package is no easy treat, but it’s done. It doesn’t offer the full potential of Box2D yet and it’s not integrated with blit, but it will and it’s working great.

Toolkit changes

Manager has been removed from the toolkit package and it is now the manager of all the engine. Again this is related to a minimalist approach. Box2D wrapping needed information about framerate and we could get it from the main movieclip that is passed to the manager. This also offers other possibilities like controlling mouse focus, quality, yada yada yada.

I’m cooking a Button manager. I know most developers don’t really like SimpleButtons, but I actually do! What I was lacking was a central point to control those… it’s being taken care of.

Scene and Music will now have transitions. This is possible mostly due to Greensock tweening library, which Vortix Games now officially supports by becoming a member of the Club Greensock.

And that’s it!

There won’t be many news in the next weeks, since we have a lot of work (remember that we kinda disappear when we are just starting up a contract project) and the rest of the bunch, like the Japan game, Bold Pixel Engine and so on.

Sorting out some random thoughts

I’m cleaning up my brain today. It has been cluttered with code and projects and today after almost six months I’ve managed to stop and think. At first my objective was to code but while I was pulling some design decisions I noticed I was also organizing my own brain.

Projects

We are now in the final ‘meters’ of a long race. This race was a nice and big contract project we are just just just about done with. As it is approaching the end we have more opportunities in front of us.

Less than a week ago all we had was this current project, the japanese themed game being coded by Pedro that Marco has spoke about lately and Mechs and Drones in a full stop. It was only natural that our option would be to pick up where Mechs and Drones was left, but suddenly another possible contract landed on our hands and the doubts start.

We’ve passed the startup phase with no investment capital but our own work, which is a huge victory. I wonder what we could have done with venture capital… We are currently in the consolidation stage, so these crossroads are always a doubt. Go for the stability of the project or the chance of a game like Mechs and Drones?

Bold Pixel Engine

A lot of stuff planned for v2. We’re implementing Box2D in it, plus camera and more and more behaviors. We will migrate all time based stuff to Greensock’s Tween Platform.

With this a lot of questions appear also…

Will the engine stay modular? By this I mean, right now I’m not dependent of the blit engine, but to implement Box2D I have to decide if only the blit engine will be served by the physics wrapper. I want to write a simple collision system. Should I implement it with sensors in Box2D? Or create a separate one?

I can even go backwards… should the current animation of the blit engine be able to be applied to MovieClips? And the list could go on and on…

I know what will decide all this: simplicity and minimalism. Whatever makes Bold Pixel Engine be more simple and minimalist will probably be chosen.

Sorting it out

Monday marks the beginning of March. I’m betting it will be a defining month for us this year. For starters the japan game will walk the extra mile in terms of content, quality and so on. Then, depending on what we will be doing, a lot of extra effort is needed… that’s what I think right now. We’ll see how it goes.

By the way… thanks for reading

« Older Entries