Hi LD25!

This time I don’t have any new hardware to learn and I’m not really interested in HTML5 games – right now – and I don’t want to mess with Angie – it would produce a lot of bugs and code mess. However in the last weeks I used Processing a lot so that will be my tool for sure.

code: Processing
gfx: Gimp2
sound: sfxr, musagi – never done any sound before though…

I’ll reuse code from my previous game GotEL if needed – not likely though. You can find it at StaticVoidGames.com.

I’ll certainly try to use my NES Framework  - for Processing – made during the CharityGameJam. Sadly no game was made based on it then but it developed more since so if you want then feel free to download the latest version here: YouTube video of it. Read the description for updates!

I wish lots of fun and plentygood experiences for the weekend!

p.s: My internet connection having problems in the past weeks and my PC does wierd things so I’ll may not be overly social during this jam.

Hi,

I am a developper from the 90sml team. We’re going to participate to the next Jam … That’s pretty exciting.

If there are here some Python language Fans. I’m working on an open source game framework. It’s based on pygame & box2d.

Hope you’ll like it : https://github.com/dawicorti/bloodyhell (work in progress)

-> Feel free to use it, fork it, ignore it ^^ …

 The Aftermath

Not quite sure if I should call it a ‘post-mortem‘. There are hundreds of these already there. It’s not about what I think went right or wrong. It just … did. Generally I’m glad the way it turned out. However, since I want to keep working on this game I’ve decided to make a list of changes I want to apply to it. That’s why I called the post ‘The Aftermath‘.

The main purpose is to expand it and make the framework more flexible. Then I will extract it and use in future compos.

So, here it goes:

Level entities’ management. Every object in a level is derived from a CEntity class. The examples are mainly … blobs. The pointers to the entities’ instances are stored in a globally-accessible array, which can be accessed at any time. When an entity is no longer needed – it gets deleted and the array is rearranged, getting rid of an unnecessary pointer ( it’s a C++ vector container ).

What if we want to store the reference to the entity and use it on later occasion? For instance, a blob chasing another blob could save a reference to its target and update its position every tick based on that. Storing a raw pointer to the data in memory is risky – we are not able to check whether the entity has been already deleted and the memory’s been freed. Trying to use such a pointer would result in very pesky and hard to track down bugs.

That’s why I came out with the idea of … IDs. An entity’s ID is an index at which it can be accessed in the main entity array ( the STL vector mentioned earlier ). When an entity is about to get deleted, the memory is freed, but the pointer in the array is set to NULL. That way it never gets overwritten and we can check if the object is available, or not. An ID would be an unsigned integer, so it could range from 0 to over 4 000 000 000! The free IDs will never get depleted and the entities themselves will be getting deleted from memory at a constant rate.

The array itself could be though great in size after a while. Every frame each entity needs to receive a tick. Iterating the entire array will be getting more and more time-consuming with the number of the array members growing in size. So … what about a second array? It would contain the IDs of non-deleted entities – that way only the valid members will receive a tick every frame without iterating through the NULL-ed entries.

Although it looks complicated compared to the previous system, it seems that it’s worth a try. Did anybody run into similar, or other worthy conclusions on that matter?

The level editor. Because of a lack of time, I had a really tough time designing the levels. A level editor and an external level file format could really get in handy in this case. Running a game, writing down coordinates and typing them in manually in a source code doesn’t sound appealing, especially when you’ve got dozens of objects which need to be somehow adjusted. I have really no idea how I’ve managed to put all of these blobs in place manually in 48 hours.

The scenes. The hardest thing to think through than the levels themselves. I’m talking here about an intro and ending scenes. Naturally, when you have an idea, you write it down as following: “It fades in within the first 2 seconds. Then it plays the sound X, waits another 2 seconds, shows a few lines of text slowly and gradually fading in …” etc. Not a tough job. It gets complicated, when you only have a level tick method called every frame to put these things in.

Let’s say you want an entity to play an animation after 2 seconds after the beginning of a scene. In the level you’d have to write an if statement which will be called each frame. It’d have to check, whether the time from the beginning of the scene was greater than 2 seconds and if it hadn’t been already greater that 2 seconds the frame before ( starting playing a sound every frame wouldn’t sound pretty – it must be called once and left alone for it to play along ). If there’s many of such ‘timed events’, we need a lot of variables. And now, if not the static variables available in C++, I’d find myself in the dead end. Although the scenes work pretty well, the code itself is a massacre and I was really confused which if statement was responsible for what event.

The threading system could be excellent here. Unfortunately I did attempt this concept few months ago and failed tremendously. Maybe because I used very unfriendly Windows API, who knows? But what other alternatives do I have?

And that’s when I thought of … Lua. I never had the opportunity to work with Lua and so I don’t know its specifications. Hopefully it allows for such maneuvers. I’ll have to dig into it. Is it possible to use threading in Lua?

That’d be it I suppose. There’s a lot of other points in my list but these are regarding either entities’ classes in particular or their implementations. Anyways, after polishing out the game itself, I will add more enemies and more levels, scenes. Hopefully it will come with a great ease. Greater than previously, that’s for sure. Eventually I will publish it.

If you have any suggestions, I’d appreciate if you shared them! I don’t want to implement a total bummer and base the upcoming code on that

Cheers! Thomas

What framework are you going to use for LD23? Why not try Pixelizer?

Pixelizer is an AS3 entity and component based game framework and today I pushed version 0.4.2. This version holds mostly fixes and tweaks to the 0.4.0 version, but a few new things as well, e.g. visualising colliders.

In order to make it easy and fast to use I’ve written a lot of components already so it should be super easy to get started. The whole thing also comes with a lot of examples that show you how to work with components. Read all about Pixelizer here.

I’ll also take the opportunity to say that Pixelizer is now on GitHub. Join the fun!

First, I want to thank for all the good feedback I got since last release. It’s been really helpful, so keep it coming!

Now then, with version 0.3 Pixelizer is really starting to shape up IMHO. Switch scenes, play sounds, add components and entities like there was no tomorrow. Feature list now looks like this:

• easy extendable component based framework
• nestable entities for easy manipulation of groups
• lots of premade components and entities
• fast 2D rendering
• automated collision detection and response
• spritesheets, animations and tilemaps
• automatic panning and volume of moving sounds
• exact mouse and keyboard input
• fancy text rendering
• handy math routines
• effective object pools
• useful logging

Code, docs, examples and all you need available on the project page: http://johanpeitz.com/pixelizer

And if you have any thoughts, feedback, or ideas. Let me know! Thanks!

I just released version 0.2 of my framework Pixelizer:

Pixelizer is a component based framework for writing games in AS3. That means that you have base entities and that you write little behaviors for them. Behaviors can be anything from game logic to rendering to whatever you can imagine. As most standard behaviors are already in the package, it is very easy to get started and getting your game on to the screen should be a breeze. I am aiming to make it really flexible, reusable and extendable. The main rendering technique in Pixelizer is currently blitting. Blitting is a fast way of displaying hundreds of objects with virtually no slow down.

I’ve been inspired by Unity3D, Flash Punk, and Flixel and added a my own philosophy into it all.

Code, example, and even a demo on the project page.

I would very much appreciate feedback on the whole thing. Very much! Thanks!

Now ladies and gents, pleeeeeease be nice.

<rant>

This is my baby. My cumulative game developing experience distilled into one sugary goodness. My 1/8 complete Mona Lisa(M?). I’ve developed more than a few finished games, and abandoned WAY more games than I care to think about. This .dll contains solutions to problems that haunted me for literal weeks.

And now I share them with you. All I ask is that if you do use it, PLEASE TELL ME WHERE I CAN IMPROVE IT. Like I said, this is nowhere near finished. In fact, it will most likely change by the time Ludum Dare gets here! In fact I can guarantee it will, I still need to add in my flexible animated texture stuff…

</rant>

What it does:

-Circle and Convex Polygon Collision

-Rotations

-Complex transformations

-Pathfinding

-Common texture stuff (animation, atlases, particle engines, etc.)

Have questions? Ask. It is very well commented, and has all the appropriate XML documentation for Visual Studio.

Happy Game Dev!

EDIT: The link was incorrect, but has now been fixed.

Getting ready for Ludum Dare!

I’ll be using AS3, like I’ve done for previous Ludum Dares. Unless somehow I get an idea that would be better in 3d, in which case I will go with Unity.

Music: Coding theme song. Level design theme song. Gaps filled by Pandora.com.

Food: It has become part of my Ludum Dare ritual to go nuts buying snacks before LD weekend.

Framework: Stego, the as3 framework that’s been grown out of the reusable parts of previous compos.

IDE: FlashDevelop.

Graphics: I’ll be doing pixelly sprite stuff in a copy of Photoshop CS 1 which as far as you know was obtained completely legitimately. I’d like to start doing more vector-based stuff, but I figure for LD I’d better stick with what I’m used to.

Music: I will probably mess around with GreaseMonkey’s music generator like I did for LD19. I’ve also used Wario Ware DIY and Wolfram Tones in the past and those kind of worked, so if for some reason I’m not liking what I’m getting out of one tool, I’ll switch to another.

Sound Effects: SFXR and/or BFXR.

Timelapse: Keeyai’s Chronolapse. It’s worked great so far.

Sauce Control: Mercurial, pushed to a repo on Bit Bucket.

Twitter: @ExciteMike

Interweb pagesite: http://excitemike.com/ Has my games and stuff.

Plan: At present, I am leaning toward doing something extremely simple, even for an LD game, but then have lots and lots of levels. I’d also love to make something multiplayer, but I don’t think people tend to have friends nearby when they go to play or rate LD games. Hmm, that sounds kind of sad when I say it that way. Point is, while multiplayer is often super fun, fewer people will be able to enjoy my game if it needs two willing people in the same room.

Framework:  This Stego AS3 framework thing that I’ve accumulated over the last several months:  http://bitbucket.org/excitemike/stego/

IDE: FlashDevelop. compiling with mxmlc.

Music: I’m thinking WarioWare DIY, then recorded and edited in GoldWave.

Graphics: A copy of Photoshop CS 1 which as far as you know was obtained completely legitimately.

Sound Effects: I bet you can guess this one.

Will be listening to: Switching Pandora between a DragonForce station and a station based on music from movie montages (on which the Transformers: The Movie (animated) soundtrack comes up often! ).

For timelapse: I will be using Keeyai’s Chronolapse on account of it’s awesomeness.

Desk:

The Brachiosaurus will be relocated before the compo begins.

Refridgerator:

In case you wondered whether I like bottled water.

Additional foodstuffs:

crunchy munchies

Inspiration:

I should be playing the GameCube version with bongos.

Projector + FC Twin + Super Game Boy + Game Boy Donkey Kong = Heaven!

Sauce Control: Mercurial, which I love.

Twitter: ExciteMike

Favorite Dinosaur: Microraptor gui

And actually I may use Unity, depending on what kind of ideas I get once the theme is announced, but the above is most likely.

I need to get a decent camera.  The webcam built into the cheap laptop is kind of a pain to use.

Well, it’s a start. Uploaded for reference. Less than 5min to go!

Well, it means that OpenGL is working (2D ortho), along with texturing, mouse interaction, and a bunch of other stuff. Normally I wait until after the theme is announced to get this stuff working, so hopefully it’ll help with my reduced time budget!

But it’s not exactly impressive to look at.

Hopefully this is my Black Triangle, or at least something 80% there. Still need to add rotation support, but that’s not too bad.

This is how it turned out. For anyone who hadn’t played the games from the last miniLD, or if you missed any or just want to play all of them over again, here they are, all bundled together in a neet package. You need python 2.6 and pygame to run on windows, plus wine for running on linux.

link

Enjoy.

PS: It’s still buggy.

Not sure if I’ll participate in Mini-LD5 yet or not, but just in case, here’s an alpha release of my ‘simplemenu’ library. It could well be the simplest GUI framework you can imagine. It barely deserves the title of GUI, actually. It’s intended to make it easy to add clickable “Start”, “Options”, “Quit” buttons to the title screen of a game. It works for me, but it’s far from finished.

(Also, sorry to release code so close to the start time … won’t do it for a ‘real’ LD … but for a mini-LD … well … better lateish than neverish).

Here‘s my custom python + pygame framework for the mini LD. It’s little more than the pyweek skeleton with image and sound loaders and a barebones state system. Consider it public domain so feel free to do anything you want with it.