Nineteen days have gone… WOW! After getting full speed ahead for a number of days, I had a stop for a day… domestic stuff kicked in. A lot of work was finished in those quick days though.
With all physics and blit done, I went straight ahead into coding the level. First task was to look at what I had done previously and finding out… it would be easier to just start over, which I did! One very cool thing is that a Finite State Machine class I wrote earlier really proved its worth and is the base for all stuff in the level. I really have to go through how the level code is structured as soon as the dust settles down since right now a lot can change and it will probably make no sense.
One thing I had to change was the Manager class. Remember I mentioned a dependency to a specific class that put all in motion. That is easier to manage now.
But the really cool thing I did today was to quickly test a console class! I used Junkbyte’s Console 2.4 and I just love it! With it we will be able to change a lot of aspects in the game without recompiling.
What is happening right now? Visually? Not much, there’s a circle representing Bruce on screen. Code wise there’s a lot of stuff going on. For starters all the level classes (controller, factory, scene, blit, physics, etc) are created and doing their thing, so it’s just a matter of adding features to it. The state management system is just beautiful and it will save tons of work!
What is missing? Graphics and stuff getting kicked!
Hello, Marco here.
Sometimes a drawing can spark an idea for a game or an idea for a character. But this time, the drawing of a character has actually sparked ideas for gameplay and for the whole visual production of the game.
Using drawings for game development works not only to help visualize ideas, but also to create empty worlds which we later fill with our ideas. This first sketch you’ll see made me want to see the other character and what their poses would be, and that gave me ideas for their fighting style, which then gave me ideas about how that would play in the game. “Will this character be able to jump, will he block or will he charge in really fast and strong?” Those questions can be answered by a pencil. It’s also fun to see the characters take a life of their own. At first I’m drawing them, but as they get more and more fleshed out, it is the characters that are drawing themselves. I just provide the pencil.
This video goes a bit into that. On how much a drawing can change your mind about your ideas for a game and also you get to see some new stuff straight from the drawing board.
Take care and I hope your like this,
I’ve been asked quite a lot how we organize our projects. I tried to explain the best I could and today I was going to write a huge blog post about it. Instead of that, I’ve put 9 minutes of video that show how and why Bruce Ali is organized the way it is.
By the way… choose 720p and full-screen it.
Today was FANTASTIC! A super productive rainy Thursday brought the rewrite of the blit core. Marco complained he can’t see anything… well… debug and tracing is all I can offer right now since textures and blit entities are not working yet, but at this pace a lot of goodies will appear soon.
To celebrate the sensation of being (finally) at full speed, I’ll prepare a sweet thing tomorrow that I hope will be good for new developers and bring a lot of discussion for more experienced ones. Stay tuned!
So I coded and recoded, tested and retested a Object Pool class with a high degree of success and frustration. I wrote and tested three different pool managers, here’s the story…
Objective: Centralized management of pools
This one was easy. There is a PoolManager that has a static method to get a pool for a certain class. If the pool for that class does not exist, it is created, if it does, it is returned. Objective achieved.
Objective: Lightweight pools
I don’t need pools to be amazingly complex, I just need the pools to get the job done, which is: be faster at getting new objects at the expense of memory. That didn’t go very well. The pools were lightweight alright, but I was not able to make it any faster than creating a objective directly.
This lead to the three versions of the pool manager and still the best performance gain is below 5% for any Bold Pixel entity. I was so frustrated, but then I saw the light!
Not my fault really
After testing and more testing I had a epiphany! What if Bold Pixel’s entities are simply too light to make pooling worth. It would not be something I’d consider. It really never crossed my mind that a instancing a object could be faster than getting it from a linked list kind of pool, but it is and the classes I was dealing with are somewhat heavy considering the inheritance and and composition of several.
The highest gain I got was 8ms in 1000 object. Creating 1000 objects took 54ms and getting 1000 objects from the object pool took 46ms.
The unexpected success
So either my classes are very light or flash behaves rather poorly in managing this. So I tested against some movie clip I had around. Creating 1000 movie clips took 102ms, almost doubling the worst case scenario.
Not only I was happy to note that my classes are lightweight, both pool manager and entity type classes, but I also proved that getting movie clips would make a difference.
I’m not happy with the pool manager for now, but I’ll work on it some other day. It gets the job done, but the objects I really wanted to make a better use of pooling are the ones that problably will have less impact.
If I regret anything in this bits of code is that I over engineered it at first. Tomorrow blit engine!