Skip navigation

Category Archives: General Game Engine

I’ve been getting back into my game engine again.  Shawn Kendall, one of the owners of ZG, has been kind enough to provide me with some tips and pointers for engine design.  Shawn is an incredibly learned man in this subject and used to teach game engine design at Full Sail U here in Florida.  Naturally, this has been an amazing opportunity which I plan to continue to leverage as much as possible.  In any case, the basics of the engine are pretty much planned out by now and I will probably be uploading the images of that sometime soon.  It’s been a lot of work and slow going, but it will be pretty awesome to have an engine of my own to dork around with and gain experience from.

On to the title of this post: the people at the ZG office **LOVE** Magic: The Gathering.  They play pretty much every Friday night, sparsely during the week, and sometimes even during breaks.  They are constantly talking about the new sets that are coming out, the recent deck they built to best so-and-so, and how broken certain cards are.  Me?  I like Magic, but I probably won’t ever get to the level of devotion that these guys have.

However, I have found that MTG is a very solid, well built, and fascinating game.  Since my time this summer has been almost exclusively *coding* games, I figure flexing my design and balancing skills is just as important.  I think Magic is a great place to start with that, so I have come up with a few card concepts that I would love to have feedback about.  I will hopefully be churning out more card concepts over the summer, but we’ll start with these:

Spiteful Visions:  2 Black                                      – Common


Target player discards 2 cards and draws a card.


“Forgetting is as much of a blessing as a curse.” -Iithes

Slash and Burn:  3 Red, 2 Colorless                   – Uncommon


Destroy target green permanent or target basic land unless it’s controller pays 3 Life.

“Take a life to save a life?  Sounds like a fair trade.”

Thriving Sapsire:  5 Green                                    – Rare

Creature – Saproling Ancient


Put a -1/-1 counter on Thriving Sapsire: put two 1/1 Saproling tokens onto the battlefield.

When Thriving Sapsire is placed in a graveyard, put two 1/1 Saproling token onto the battlefield.

Creatures of the forest never die, they simply get smaller.

Inspired Flight:  2 Blue, 2 White                        – Common


Enchant Creature

Enchanted Creature gains +2/+3 and has flying.  Place a -1/-1 counter on enchanted creature.  When enchanted creature is put into a graveyard it’s controller gains Life equal to the number of -1/-1 counters on enchanted creature.

“The best things in life might just kill you.” -Tarr’agun

I decided to go with the maze game for the iPhone/iPod Touch.  It will consist of a target that will either be circular or cuboid that the player must move to the end point using their fingers to guide it.  Touching a wall or object will set the target back to the last checkpoint.  I haven’t decided whether I want to implement lives or a timer.  I will try both and see which one playetesters enjoy more.  I think lives will be best, but that remains to be seen.  Simple game with some decent potential, here’s what I have for the “boring architecture part”:


  • Don’t need texture loading (that I can think of)
  • Simple style of colored shapes
  • View scrolling when the target gets to the edge of a defined area.
  • Will have to rebuild Radiance to make sure all of this works well.

User Interface

  • Basic Cocoa UI elements, using Radiance I can overlay what I need.
  • Want to experiment with different kinds of menus and UI displays.
  • Need to make sure view scrolling is adjustable.


  • Implementing Separating Axis Theorem which requires rebuilding Continuum.
  • Need to detect edge triggers for things like doors and victory conditions.
  • Unit test the crap out of my revamped vector system and rotation implementation.

Game Logic

  • Target resets to last checkpoint after (5) seconds of not being touched.
  • If the target touches an edge or another object, reset.
  • Timer?  Lives?  TBA
  • Later levels will have the target orbit the touch point.
  • Later levels will have multiple targets.
  • Later levels will have multiple targets with independent end points.

Level Builder

  • Grid system to start, build level with “positive” tiles on negative background.
  • Want to implement this in Lua to allow for greatest flexibility.

So, that’s pretty much the gist of it.  I have a lot of work to do.  Already rebuilt the vector class I was using to be a little more friendly.  Looking into SAT implementations.  I understand the concepts, but I’m unsure about implementation.  This is gonna be a lot of work at a difficult time.  Cross your fingers…

I’ve been seriously considering scrapping my current game engine and starting from scratch.  This means that many month’s worth of work will be set aside to start on many more months of work.  However, this also means that I will be able to leverage my experiences a lot better and actually plan the engine out a little better than I did before.  I haven’t come to a decision yet, but it’s something I’ve been mulling over for the last few days.  Decisions, decisions…

Well, turns out that even if I could get this working with Apple’s NSOpenGLView, that I can’t superimpose a button on top of such a view.  So…I will be forced to do my own GUI setup.  I can’t say I’m surprised, but it’s certainly something I wish I didn’t have to do.  Fortunately, I have parts of the Cocoa API to help me out.

First up, however, is to fix texture loading issues.  Who’d have thought that reading in texture data would be so complicated and convoluted?  Oi.  I digress.  Onto GUI programming!

Well, I’m officially at a loss for the particle engine.  I’m going to try finding some help through some forums and articles, but I’ll be changing focus away from it for now.

Instead, I need to tackle a glaring problem that I have been avoiding for quite some time: GUI.  My current implementation does not allow me to add any of Apple’s UI elements to the engine for input, so I need to one of two things: rebuild with Cocoa so that I can use xib files and/or all of Apple’s prebuilt GUI elements OR build my own GUI element implementation.  I bet you can guess which one I’m going to do.  However, you’re probably wrong on this one.  Though I generally tend to do everything the hard way by re-inventing the wheel, I am going to rebuild to allow for Apple’s GUI elements.

This should really help with the usability of the engine, but it’s going to be some hard work for sure.  Keep tuned for developments on this one…

A quick update on my game engine (did I forget to mention: I’m building a game engine) and the particle engine in specific:

My particle engine is not cooperating.  I finally have point sprites working, but loading in new textures for the sources corrupts my particle textures AND the source textures, so I’m at a total loss.  All attempts to start the engine over have failed for seemingly no reason, so I’m chopping up my original test to make it work better.  It seems that I will have to step back and redesign the architecture (again).

On a lighter note, I figure the particle engine is mostly fluff at this point, so game prototyping and stress testing will begin shortly.  I have many things I’d like to get in place before I start building real demo games, but simple prototypes will be small enough and simple enough to be able to ignore many of these improvements.

Wow, I’m really in over my head with this one, but the sense of achievement is unparalleled.  Anyway, I hope to have some news on the engine later (for those of you who care…).

Success! I have **FINALLY** gotten point sprites working correctly. After much struggling, frustration, and a slew of websites that offered little to no help whatsoever here is my answer:

To use textures with point sprites you need to do the following:

  1. Find out the limits of your point sprite implementation by using the glGetFloatv( GL_ALIASED_POINT_SIZE_RANGE, <float[2]>) call. This will populate your <float[2]> with the upper and lower limits for your texture sizes (generally, but not always, 1 and 64).
  2. Load in your texture, enable it’s type (I believe that it MUST be GL_TEXTURE_2D), and bind the texture.
  3. Enable GL_POINT_SPRITE_ARB and set attenuation, fade thresholds, and pass in the min and max sizes.
  4. Set texture coordinate replacement parameters using glTexEnvi( GL_POINT_SPRITE_ARB, GL_COORD_REPLACE_ARB, GL_TRUE).
  5. Specify your point size, using glPointSize(<float>) and (optionally, mostly for particle systems) turn off the depth mask.
  6. Call glBegin( GL_POINTS ), specify 3d vertices, and then glEnd.

Here is the exact code I am using. The loadPoTTextureFromImageNamed: call returns a texture containing GLuint data and a GL_TEXTURE_2D type. Other than that, it’s all pretty self explanatory. Let me know if you find something out of whack. Hope it helps!


//Make space for particle limits and fill it from OGL call.

GLfloat sizes[2];


//Create the texture we want to use.

BBSTexture* t = [BBSTexture loadPoTTextureFromImageNamed:@”Particle1.png”];

//Enable our texture type (in this case, it must be GL_TEXTURE_2D)

glEnable([t type]);

//Bind the texture data.

glBindTexture([t type], [t data]);

//Enable blending and set for particles


glBlendFunc(GL_SRC_ALPHA, GL_ONE);

//Enable point sprites and set params for points.


float quadratic[] =  { 1.0f, 0.0f, 0.01f };

glPointParameterfvARB( GL_POINT_DISTANCE_ATTENUATION_ARB, quadratic );

glPointParameterfARB( GL_POINT_FADE_THRESHOLD_SIZE_ARB, 60.0f );

//Tell it the max and min sizes we can use using our pre-filled array.

glPointParameterfARB( GL_POINT_SIZE_MIN_ARB, sizes[0] );

glPointParameterfARB( GL_POINT_SIZE_MAX_ARB, sizes[1] );

//Tell OGL to replace the coordinates upon drawing.


//Set the size of the points.


//Turn off depth masking so particles in front will not occlude particles behind them.


//Save the current transform.


//Begin drawing points.


//Iterate through our particles, setting the color and specifying their position.

for (Particle* p in particles)


glColor4f([[p color] magnitudeX], [[p color] magnitudeY] – [p lifespan], [[p color] magnitudeZ] – ([p lifespan] * 2), [[p color] magnitudeW]);

glVertex3f([p x], [p y], [p z]);


glEnd(); //Stop drawing points.

//Return to the previous matrix.



You are free to use this code in any manner you see fit.  Have fun with it!