Mutant Amoeba Development a peek behind the scenes at the MAD lair


Okay, pretty much chose my game now.

Posted by pentaphobe

Choosing is hard.  wahh.

Here's the first page of my morning list:

It's hard to read, but: (A) You're Jesus, burying dino bones for your dad.

General Status

Spent the last hour working out the FlashPunk tile class.  took me an amusingly long time to realise that it actually renders a canvas and isn't re-rendering tiles every frame.

This is a Good Thing, but kind of hobbled me for a while.

Got basic parallax scrolling world working pretty quickly, can't get bogged down in false sense of security though.

Here's where it stands before I go off to work at the bar for the night :{>


It ain't much, but it was easy


I also appear to have roughly arrived at a decision, hard to choose between a few really fun ideas.  So I'm going to join as many of them together as possible.

So yes, unless I get deeply inspired by something else whilst at work, it's fairly locked away.


current mood: I don't wanna go to work!

Filed under: LudumDare #24 3 Comments

The theme for Ludum Dare #24: Evolution!

Posted by pentaphobe

So I spent last night deciding to use FlashPunk which up until about 11pm I'd never used before - seems like it'll be a good fit; most of the good and very little of the bad.

Very very glad I took some time to get the development environment up and running beforehand though.  That's already paid off twice. Once I got everything up and running I set about spending a little time just free form writing to see if I was comfortable enough, this is the result.

my warmup, codenamed "will I be able to use this environment?"

It's now a one and a third hours since the theme was revealed.  I was secretly really hoping against "Evolution" as it's very close to about half a dozen small projects that are currently in progress (and one major one).

However, on SethR's advice I've avoided whinging about the theme and instead have dug forth through the wilderness, coming up with a two page bullet list of potential game ideas.  Some already feel like they'd be fun, but I'm going to now sit with my coffee, digest my eggs and vegetarian lasagne and let the feeling wash over me for a while.

The ideas mostly fall into the "non-groundbreaking mechanic with funny gimmicks" category, so I'd like to give myself a little longer to ponder in case something really awesome occurs to me.


Current Mood: confident and surprisingly relaxed

Filed under: LudumDare #24 No Comments

Tiles as offset lookups into an arbitrary texture

Posted by pentaphobe


This one's been on my mind for a while now, but after seeing its effective use in Dynamite Jack and Prison Architect it's a go-ahead.

note the ground tiles and how they're not constrained to wall size. This could be achieved with multiple wall-sized tiles, but why bother?

The gist is that instead of using a specific image for each grid point in a map, you instead do a wrapped lookup into that texture so that it can be larger (or smaller) than the grid size itself.  Fairly basic stuff.  Just imagine a texture repeated across the screen and then masked so it only shows on tiles that match. (that's not how you'd implement it, but seems like a clearer image)

However there's an implementation detail which I find interesting: originally I was just going to allow images whose dimensions were a multiple of the tile size, this is easy to code and makes wrapping trivial when using a sprite sheet.  We can also render the tile map by having a fixed grid of points already attached in the graphics card and then simply going through and dynamically changing the UVs for each point whenever the map moves by a whole tile or more.

Dynamite Jack

Again note the ground tiles aren't constrained to wall size. Also note that I'm quietly ignoring how similar our games look. Maybe I shouldn't add that flashlight after all? :)

An nice alternative which would definitely help "break up the grid" is allowing completely arbitrary texture sizes, which would be just as easy to implement if we used a separate texture for every tile, but texture changes are horrendously (and notoriously) slow so that's not an option.  However, using sprite sheets means we can't rely on the hardware to automatically wrap tile images (as it'd simply show adjacent images from within the sheet rather than wrapping at the tile boundary).

The only solution which leaps out at me is to implement the whole tile rendering side of things in a GLSL shader so that we can manually wrap texture coordinates at the appropriate tile boundaries.

Seems simple enough, and it'll mean I finally need to learn how to send arrays to a shader from Java..  Something about IntBuffer objects which seem simple enough but are a little odd.  Not sure why it can't just be a reference to a flat array like in C..

Ho hum!

Hands On: Prison Architect | Rock, Paper, Shotgun.


Grappling with logic systems…

Posted by pentaphobe

So I haven't updated in quite a while due to a conglomeration of factors:

  1. I was away for a bit
  2. The Lady is on holiday and deserves more than watching me code
  3. My brain broke (apparently it felt it deserved more than watching me code too)
  4. I got into a beautiful quagmire of how best to generically represent logic in game systems.

I'm going to talk about item 4 here, though the third may get a mention as it's related.
-- page break --

Logic Systems

For the last couple of years, Entity System design has been the fertile topic of many keynotes, articles and assorted head-scratchings.  In particular, Component Entity Systems are, as they say, "all the rage."

A Quick Review

I personally love the component model, I'd been toying with similar systems for a while but never quite got it down to the logical simplicity that others later did - instead always trying a new implementation each time (iterating) in the hopes of finding a good tradeoff between "elegant" and "efficient" (sometimes these are one and the same, but so far they're at the opposite ends of the scale when it comes to entity systems).

Since these topics have been covered elsewhere (extensively), I'll simply summarise the two main popular approaches to entities:


Katamari of Data
The entity contains all possible interfaces (and common data) for any type of object in the game world, different object types are then sub-classed from this base entity. The main caveat with this model is that data and interfaces specific to certain subclasses often end up needing to be moved to the base class and you also end up with code duplication. (See other articles for a more in-depth description of this)
Component System
In its purest form, the component system works by having Entity objects be simply a unique ID.

Data and behaviour are both stored in Component objects which implement a specific, isolated functionality and contain appropriate data and the associated Entity ID.

Components are in turn stored by their respective Component System objects (one per type of component) which do the actual processing.

Again, I haven't covered this in much detail, but that's the gist. There's also a variation on Component Systems which further breaks components into either Attributes or Behaviours - though this is a little of a strange beast.

It's also the main subject of my brain cycles over the last week.

So many questions..

  1. Attributes are data which needs to be accessed by more than one behaviour, but also has event handling and update functions.  Are there any significant differences in interface between these and behaviours?
  2. Should Attributes be objects which abstract data access, just the data itself, or should the data actually be stored in the associated AttributeSystem?
  3. Behaviours are easy to grok, as they're quite literally the same thing as the classic Component model - however, is there a good reason to rethink this?
  4. Which things should be handled by the system, and which should be handled by methods within the respective Behaviour/Attribute object?
  5. How best to include commonly used interfaces without also tying the code to a particular platform?
    ie. we don't want to use the event system for render() or update() calls as that's a large quantity of pointless cycle waste.  But if I define a render interface then surely it must include information about the current graphics context?  (The actual code can be adapted, but the method prototype will still contain a specific object type)
    nb: probably the best way to handle it would be to only have the render component's system know about the graphic context and provide necessary calls to its child behaviours. 
  6. Which things should I abstract completely, and which should be optimised into either the Entity class or Component classes?
  7. How can I minimise memory usage and call overhead?
    eg. do Components hold a reference to their owner System _and_ owner Entity? (memory)
    do Component interfaces take a reference to their owner System? (one extra variable per call)
    do Components actually contain a static reference to their owner System? (kind of strange, hierarchically. mostly works, but when our game object wants to update all systems, how does it know where to find them? nb: could quite easily leave the static uninitialised and have the ComponentSystemManager initialise them upon registration)

And that's really just the surface of the thing.
Those are mostly quite easily resolved (I've done it dozens of times) it's more a matter of finding that nice balance, which I'm struggling with presently.

The real thing

The main thing I've been doing is attempting to reduce ALL possible behaviours of a game engine into a simple system which can produce broad varieties of behaviour with little to no modification.  Ideally most games should be buildable with nothing more than a definition file and some assets.

Plenty of people have addressed this sort of thing, particularly in production of "GameMaker" type programs - but I've always found them a little convoluted, much like my previous attempts.  In both cases you can tell there's some great engineering at the foundation, but iterations have slowly added complexity more broadly than is ideal - often resulting in pointless amounts of boilerplate definitions and then eventually powerful embedded scripting all of which kind of defeats the purpose of having a simple engine in the first place (often it'd be easier to program in the host language rather than build complex functionality out of a slow embedded scripting language)

So I'm aiming for an extremely high-level model which effectively creates a pluggable development environment much like Stencyl or PureData.

The main difference being that implementations like Stencyl allow you to plug in predefined components, or write code using predefined pluggable blocks of code (effectively just removing the typing from normal scripting) - whereas I'm designing a system where it's less about plugging prefabs together and more just about defining the fundamental logical flow of information through a game system.

In other words this is a designer-oriented system, rather than a make-it-easier-for-designers-to-write-code system.



Long post is long.

More on this as it progresses.


Once more, with shadows

Posted by pentaphobe

So the shadows don't appear to work with Slick's VAOGLRenderer, presumably I'm not flushing when I should flush or something.

For now I've rolled back to the immediate mode shadows, which is a major speed hit.

(but boy is it fun hitting things!)

Once more, with shadows - YouTube.

Tagged as: No Comments

better audio big update

Posted by pentaphobe

Quite a few additions to this:


crowbar head bashing and health

Posted by pentaphobe

Unfortunately I still haven't worked out how to get a nice mix of game audio and microphone with Screenflick - I even tried not to mumble this time, but it's still a muffled mess.  Screenflick doesn't appear to allow re-mixing audio levels after the fact either, so we're stuck with this for now :)

Rather largish update today, though with only minor noticeable changes:


zombie kills!

Posted by pentaphobe

(Apologies for the almost inaudible narration - combination of background traffic, gunshots and mumbling makes it almost pointless to listen to me... more so than normal I mean)

It's almost a really basic playable thing that almost entirely doesn't resemble the game but covers a large quantity of the required functionality!



hud and blud – YouTube

Posted by pentaphobe

hud and blud - YouTube.

Tagged as: No Comments

Added some polish..

Posted by pentaphobe

Just a quick overview of what I just added - I'll do a proper video soon (with better sound) covering all of the major changes since the last videos.