Crossfading between blurred/unblurred might be unnecessary depending on what you're doing.  Is it a one-pass blur or a two-pass blur?

The "cleared" part of the shadow buffer isn't getting drawn.  It's either white or failing the alpha test, which should be off for that part since it doesn't even use alpha.  You're drawing a white-circle-on-black-background sprite on it, and the background part gets drawn in as a shadow.

By the way, try making your light sprite use some greys or a gradient and see what happens.  :D

^ ignore everything he just said.  He's assuming you have the luxuries of a generic object-oriented programming language, which you don't.  (Using Game Maker objects to mimic OO code is almost always a bad idea.)

Explain what you mean by states.

The usual technique for a 2D lighting system like what you're doing is thus:

Create a screen-sized "lightmap".

Each frame:
- Update game logic.
- Draw scene to screen.
- Clear lightmap to black. (or a lighter color for an ambient light level)
- Draw all light sources onto lightmap.
- Draw lightmap, multiply-blended*, to screen.
- BLAMO scene has lighting.

* Multiplicative blending can only darken what's being drawn over, and is useful for shadows, translucent materials (like cellophane or stained glass) and smoke.  The blend function to use is glBlendFunc(GL_DST_COLOR, GL_ZERO);

It could be interesting to take the "civil engineering" mechanics of a game like Dwarf Fortress, expand on them and make a game of that.  For instance, players in that game sometimes create structures like "pump stacks" to irrigate their crops from underground lakes, because it's safer than using surface water.

Anyway it's a neat idea, but please don't make water work like that.  >_<  I really hope it doesn't become an accepted thing that water in videogames should work like that.

It's a train whistle, you uncultured swine!  THE NOBLEST INSTRUMENT, FOLLOWED CLOSELY BY THE OBOE

Uhhhh, I was assuming this was 2D.  Is it 3D?

Camera matrix =

Rotate(-camera.orientation) * Scale(1/camera.areaScale) *  Translate(-camera.position);

The way I like to deal with camera transforms is, I treat the camera as an object with translation, rotation and scale, and I use the inverse transform of that object to derive the camera transform.

DirectX and OpenGL seem to do their matrix multiplication in opposite orders, so be mindful of that...

Expressive gaming has been an interest of mine for a long time, hence my involvement in Infinite Blank and SoundSelf.  I certainly think the Writing forum is an appropriate place for a discussion like this.

A way I've been thinking about it recently is that my job is to make a piece of software such that when a person interacts with it, a game (or something else) arises.  Our creation is an incomplete machine, whose centerpiece is an exquisite and unknowable mechanism.  Our art is in understanding how the two play together.

It's interesting how the "performance piece" created by a player can have different audiences, and how that affects the nature of the performance.  Solitary storytelling experiences are an opportunity for us to make an honest exploration of ourselves in addition to the world we're presented.  More strategic or action-driven games can be an intriguing spectator sport, and being watched or broadcasting our efforts changes how we think.  Multiplayer games that allow limited means of expression give rise to intricate idioms and player-created languages.

My fixation has always been the first case, though.  When I'm playing a single-player game, and I make a choice unencumbered by strategical underpinnings, it's a communication from me, to the game, back to me.  It's a process of reaffirming or experimenting with my own philosophies within the created world.  And the glimmer of humanity that is seen there -- an alien reflection of me, created by me -- is a really special thing.

y = 1 - .1 * x; 

Ah, but that's the killer -- a simple idea has no relation to a simple-to-implement idea.


As an example, let's take Minecraft and make all the blocks smaller so hills can roll a bit more smoothly.  Let's say, rather than one-meter, washing-machine-sized blocks, we use 25cm high blocks.  Okay, simple enough.

Turns out there's a very basic reason Minecraft is a machine hog -- 3D grids of data are BIG.  Even if you can crunch the data down to one byte per block, the equivalent of one 16x16x128-meter "minecraft chunk" is now composed of about 2,000,000 pieces -- 2 MB -- with some 6,000,000 relationships to be analyzed in order to generate the visible geometry.  The increased computational power involved in generation and rendering, memory required for gameplay, and disk bandwidth utilized in storing and retrieving this data is staggering, and some very fancy algorithms would be necessary to minimize these costs.

Game designers should understand programming, even when they aren't programming the games they design, for precisely this reason.  Understanding technical concepts -- which get much more subtle and multifaceted than in the example above -- is necessary for making viable game designs and effectively communicating with programmers about the implementation of those designs.

Addendum: be very wary of academically-developed software.  In my experience a lot of that stuff takes the form of huge, general purpose frameworks built around functionality which is either lacking or heavily over-engineered.  This is perhaps a prejudiced viewpoint, but I've worked in academic software development and it isn't pretty.

In the case of the library you linked, they're employing neural networks for audio analysis.  For something like what you're doing, I wouldn't touch that stuff with a ten-foot pole.  Stick to low-level techniques, which that library also provides.

Also be aware that jMIR's license won't allow you to make commercial use of the library, so you can't sell or otherwise profit from this game.

SoundSelf developer here, also doing freelance on Crypt of the NecroDancer.  I've designed algorithms for pitch and beat detection, as well as lots of generative stuff.  [/streetcred]

Definitely start by thinking about what kind of ties you want between the music and the content generated.  If you aren't creating intuitive relationships, you might as well be using random numbers.

If you're detecting broad frequency ranges, you might have slightly better luck with bandpass + envelope following as compared to a fourier transform.  You're unlikely to have those kinds of options with a Java lib, though, so if you do use fouriers make sure to pick a nice smooth window function like hann-poisson.

There are tons of algorithmic approaches to beat detection; many of them don't handle changing tempos very well, while others struggle with complex rhythms.  I've been dealing with the ins and outs of this for NecroDancer and will actually be open-sourcing the algorithm the game's release.

You can't evaluate the idea's quality until you execute it.  Even as an experienced game designer, thinking about an idea for too long before making it tends to produce extremely underwhelming results.  Invariably iteration is necessary.

For a week's worth of work, assuming an expert programmer, you can expect a voxel world and a first-person character capable of running, jumping, and perhaps destroying or placing blocks.  It won't be a game, and it will take weeks longer to make it a game.  With a novice programmer, you're talking the better part of a month before you even get to that point.  My basis for saying this is watching one of my very competent programmer friends start a minecraft-oid over the course of two weeks.  He was using Unity, which speeds things up, and he's a lot more experienced than anyone you're going to be able to hook up with.


Good game design isn't coming up with high-value ideas.  It's coming up with ideas which have a high ratio of value to difficulty of implementation.  Think smaller, and perhaps you'll be able to tackle bigger projects later.  Remember that anyone you choose to rely on is another chance for your project to fail.

Think of it as selling your credibility.  You then have the option to earn it back by actually completing the kickstarted project.  :/

I think we met at GDC and you showed me the related game.  If that was you, my advice about using palettized color and bitmasks still applies...

Focus on one of your skills, preferably programming.  Consider specializing in something unusual and try to develop a skillset in an area where the demand exceeds the number of qualified and available individuals.

You might be interested in reading up on separating axis theorem collisions.  Check out Raigan Burns' writeup on how they were used in N here.

You're perfectly capable of learning to program.  Your insistence that you can't simply serves to demonstrate your inability to commit to a long and daunting task -- like making a game.  You state that you have an idea, but the idea you present is no more complex than the title of this thread -- make a voxel game.  Perhaps you have more developed ideas you're not sharing, but by doing so you withold all possible credibility.

Essentially, anyone who is naive enough to take you up on this offer to collaborate will be a novice -- unskilled, sloppy, and likely to flake out on you.  If you want to get something made, and you don't have the credentials to attract professional collaborators, I suggest you make it yourself.  Take it from someone who gets things done.

If the array is full of pointers and you set those pointers to NULL, (1) also potentially leaves "lost" objects sitting around in memory.