We’re almost into July, which means there are now less than 6 months until Christmas. I’ve been thinking about doing a `christmas game`, based on a kind of puzzle game that I haven’t seen before – inspired by an old Mac classic. I have been researching my competition – there are certainly some christmas themed games out there, although most of them are really just regular games with a few extra christmas-themed graphics thrown in to `christmas-ize` them. The famed `christmas edition`.
I think there could be a good opportunity here for a dedicated christmas-themed game, which really focusses on christmas rather than just some other game rehashed. Also I figure that this short-range timeframe will help me to focus, to put together an initial game framework, and then I can later release another regular game based on the same engine – to `un-christmas-ize` it and turn it into something more suited to the mainstream markets.
So I figure, hey, if I want to get a game out the door for this Christmas’s shopping season, which really means *before November*, then I have about 4 months to put together a game. Obviously I’m not starting from scratch, having already done some useful coding, but there is still much to do to make it a game, and especially all of the graphics.
I was thinking to myself how I would practically pull this off. Since I am doing everything myself, the idea of hand-drawing lots of graphics is not very practical. If I would have to sit and click to draw every little pixel by hand, even at a low 640×480 reslution, that would certainly take a long time.
Then I thought about how my engine so far supports full resolution independence. What that means is it doesn’t matter what screen resolution you choose, the graphics will keep their proportions and can support widescreen or normal screen shapes. To go along with that, you’d ideally either have to hand-craft pixel-perfect graphics for each individual resolution separately, or find a way to `generate` them or scale them in the game.
First of all, the idea of scaling graphics means that, to maintain quality, you have to start with a high resolution image. You can scale it down and still have it look good, whereas scaling it up is really a cop-out and would really invalidate the whole point of being able to run at a high resolution. Unfortunately there is not much you can do to avoid having to scale the graphics somewhere along the line. If you’re going to use any kind of pre-rendered texture at all, or anything hand-drawn, then you’ve got to deal with scaling, or multiple versions of the same image. The multiple versions route doesn’t sound appealing – there are a lot of resolutions out there!
So then we come down to the idea of generating the correct graphics in-game. Instead of drawing everything beforehand and locking it in to a given resolution, let’s have the game re-draw the graphics in the game. That could mean that the game goes and draws a bunch of stuff at a specific resolution and turns it into a fixed-resolution texture – ie matching the current resolution and recalculating it if the resolution changes, or actually redrawing all graphics in realtime on the fly.
Both of these are possibilities, although the latter would require rather more computational power. More likely the regeneration of graphics would have to be done in the background, running on another thread while the user is busy interacting with the game presentation. However, on-the-fly regeneration of graphics would mean you can scale in realtime with pixel-perfect precision and no quality loss/rasterization issues.
So at the very least I am now looking to create an in-game vector-graphics-based image generator. Whether I then use this to generate a resolution-specific version of the graphics in the background, or on the fly as the game screen is built, will be a future decision. What this means is none of the graphics will be pre-drawn outside of the game, except for general-purpose textures. It’s kind of like bringing a vector-graphics editor into the game itself – making the graphics generation a runtime process rather than a develoment-time process.
The great thing about vector graphics is that they are based on mathematical representations of object shapes. Instead of hand-pixelling individual pixels, which you could still do with vector graphics, you instead define shapes like ellipses, rectangles, filled curves, etc and set up a way for them to be filled with gradients and/or textures, plus transparency and blending effects.
Then when it comes time to render the vector graphics, whatever the current screen resolution is, every single pixel in the screen will get it’s own accurate representation of the object. If you were to go high definition 1920×1200 or more, or really low 640×480, you’d still see the same in-proportion shapes and represented with as much precision as possible. Beyond that it may even be possible to also render the vector graphics at a scaled-up size, and then scale it down with filtering to produce anti-aliased images.
What I propose is to build a library of textures – sort of general purpose `materials`, ie like gold, chrome, brushed metal, whatever. Then these would be used to texture the vector objects. The nice thing about vector objects is that the *edges* of shapes remain crisp and accurate, with no blockiness, regardless of how the shapes are filled.
The filling of shapes is a bit of a problem because you have a few technical challenges. Textures still remain bitmap images which really need to be high-resolution in order to scale down well. Also you have the option of gradients which could be precalculated texture images, or somehow calculated in realtime – not sure how I’d do that other than with the CPU with bitmaps. Then you also have vertex colors – if you turn a vector shape into OpenGL geometry, ie triangle trips, then the intersection of each triangle can have different tinting at its corners. Options to think about.
I think that by using in-game-generated vector objects I will be able to a) create decent-looking graphics quickly, b) solve the issue of resolution independence and high-res displays, c) be able to modify parts of the graphics easily, d) alter their appearance on-the-fly in-game e.g. changing to other color schemes, adjusting their size, animating individual parts, etc. If I really need to I can either create a hand-drawn texture, or build a high-detail vector object. When you think about it, if you create an image out of lots of tiny vector-squares you basically have the same thing as an `image`
I will be creating my own OpenGL-based vectorgraphics system. This means that all my games will be OpenGL-only. Is this a wise decision for casual games? I’m not sure. I think it is fine for Mac and Linux, but Windows is a little less reliable. Still, support is always getting better over time. Without being able to create my own GL code, I wouldn’t be able to do vectorgraphics at all utilizing the GPU or in realtime – it’d all have to be done by the CPU, slower and less flexible.
No vector system would be complete without some kind of curves. Some people call them splines. A vector curve is usually based on some mathematics, such as the bezier curve. There are a few different kind of curves and they have different qualities and behaviors. Enjoy playing with some interactive java applets to get a better feel for the different kinds.
One of the simplest is the 3-point bezier curve, also called a quadratic curve, which starts at the first point, is influenced by the second point (but does not pass through it), and ends at the final point. Here is an example:

Then there are cubic splines – more useful in being able to create S-shaped curvs, adjusting the curve with 2 intermediate control points which again are not passed through. It’s also possible to have more control points for a single bezier. Here is an example of a cubic 4-point bezier curve:

Beyond beziers are some other interesting splines – see this wikipedia category.
One of interest is the Catmull-Rom Spline, also known as a cubic hermite spline. Who makes up these names? The nice thing about these is that the curved line always passes smoothly through every control point, so it makes it very easy for drawing `paths` to follow. Objects could move along a path and be sure to always visit every control point, smoothly easing into and out of each point with no sudden corners. This is what they look like:

Different kinds of splines can be useful for different purposes – sometimes you want to visit all control points smoothly, sometimes you don’t, e.g. to represent shapes with both curves and corners. There is also some technical lingo regarding splines such as continuity and order and knots and stuff, but we won’t get into that.
There are also other splines such as the snazzy NURBS (Non-Uniform Rational B-Splines), which have a lot of controllable features for subtle curve generation. OpenGL actually provides a NURBS system to turn NURBS objects into geometry, but I am not going to be using it. NURBS are, however, considered by many to be the nicest to use for things like engineering and higher-end graphic design, 3d modelling etc.
There are other kinds of splines, such as the B-Spline, where multiple control points can be specified which influence the curve but the curve doesn’t go through it. I’ve seen them used in high-end graphics applications like raytracing. For some reason I don’t really like these so much, maybe because, like the NURBS, they are quite complex and I don’t understand the math!
That said, I don’t really understand any of the math for any of the splines, but bezier splines are pretty easy to grasp in terms of source-code. You can get a spline to draw with only a few of lines of code.
So……. I had a play around with cubic bezier splines. They are quite simple to do and easy to adjust. The only issue with them is that usually the curve starts off aligned to the line from the first to the second points, which may not flow into the curve from the previous bezier section. So you get sharp angles inbetween bezier curves. This in some cases is nice to have, but sometimes not. It would be nice to have the seamless continuous splines like the Catmull-Rom.
After some fiddling around I wrote a sort of `wrapper` around cubic beziers which allows me to join two beziers together. The start/end point which they share then forces a straight line from the previous spline’s 3′rd point, through the joined point, to the second splines 2nd point. This produces a continuous curve.
I then looked at some other fancy splines – such as the Kochanek-Bartels Spline. While I do not understand any of the math involved, these splines are quite nice in that they have a `tension` and a `bias` which can be defined for each curve section. Tension is like the ability to pull the curve `tight` between two points, so that it becomes straighter. Bias sort of makes the curve bulge/magnetize towards a given point, sort of like a sharpening/pinching of the curve. I have no clue how to do this.
However, I did come up with an emulation of this which I am very happy with. If they have not been done before, I will call them Subdivision Cubic Beziers. Basically, you start with a normal cubic bezier curve. This has four points. The first and second points form a straight line which may, or may not, be an extension of the line from the previous curve’s 3rd and 4th points. Or in other words, if you want to you can make the curve `continuous`, or have a sharper angle between curves.
Then I noticed that if I draw lines from halfway between the first and second points, across to halfway between the second and third points, and similar from there to halfway between the 3rd and 4th points. .. .. and then divide *those* lines in half and draw a line between them, and then find the middle of THAT line, that exact point will be the exact middle of the bezier curve. The curve always passes through that point under normal circumstances.
* Please note that while I came up with this by myself, as you can see from the cubic bezier curve image above (which someone else created) someone else also thought of/knew about this too. *
What I then realized is that by drawing lines between points, I created basically a sub-bezier – splitting the cubic bezier into two cubic beziers. What I’ve basically done is convert one cubic bezier into two cubic beziers which have exactly the same shape together as the original. You could call that subdivision. I then realized that now I have more control points, and if I move those control points I can shift the curve around.
Moving the mid-point along the line between the 1st and 2nd points attracts the curve towards the first point, or bulges it out way from that point. You could call this `bias`. I can adjust that new control point to adjust the bias of the curve – and you get two bias controls per curve. In addition, the angle formed by two curves next to each other, basically represents a `tension`, ie the change from a continuous smooth curve to a sharp angle. It’s possible to connect the bias from one curve to that at the end of another, so that you can `shift` the bias from one curve over to the other.
All together these subdivided cubic beziers give you full emulation of Catmull-Rom splines, plus emulation of Kochanek-Bartels splines. All using ordinary cubic bezier curves. And the nice thing is, you can actually calculate and draw cubic beziers using subdivision in the same way – just keep on subdividing until you get to a small enough resolution to draw short straight lines (or to turn it into geometry). You can thus produce these cubic subdivision splines just by subdividing the distances between points, recursively, rather than moving along the curve in steps.
Playing around with this, I came up with a little play-editor, as seen in the image below.

It’s not very advanced yet, but I put in some simple keyboard controls to implement some basic manipulation of all of the features of the curves. If you look at the image carefully, the blue lines join the major 4 control points of the original cubic bezier, and then the orange lines show where these have been deconstructed into subdivision curves.
I plan to use these for my game – they give me a lot of control over the curvature and capability to easily create subtle curves which are not so easy when trying to do it with regular beziers. Also it has the possibility that if you want to tweak a section of the curve, you can further subdivide the bezier giving you extra control points – initially exactly copying the shape of the original curve, but letting you then apply additional `local` bias and tension to a section of the curve. The interesting thing is that if you then manipulate one of the higher-level (of subdivision) control points, the whole curve adapts dynamically while maintaining the same sub-level adjustements.
I think I will have to make a proper editor, where I can choose some `tools` to edit the curves, color them, fill them with textures or gradients, apply effects etc. I will then be able to create all of the graphics and animations for the game. If there is time, later, I can come back to the simpler graphics and add extra detailing. Vector graphics are also nice in that you can come back and remove features without messing up all of the other `pixels`. In a bitmap this would require extensive re-touching.
My task now, then, is to create the editor, and the graphics routines, to manage and render vector objects using lines, splines, and other geometry.
Note: After writing this post, I found a nice page online which shows in somewhat more formal terms (including math) most of the insights that I arrived at myself about using subdivision of cubic beziers, here: Rendering Beziers. They refer to the subdivision as a `mid-point method`. One nice touch they added is that you can modify the mid-point method to divide distances between points by an amount other than 2, if needing to find an exact point along the curve. They also mention that if you use integer math, or fixed point math, then you can do fast calculations with binary shifts and additions. Something to keep in mind
Here Here is another site explaining it well, also mentioning adaptive spacing of line segments to compensate for sharpness of corners.


Pardon me!