Intel sponsors gamedev.net search:   
Gauntlets of Recursion (+7)By HopeDagger      
-->

Recent Projects:

[Gundown]
[Magma Duel]
[Admiral Overalls]
[Membrane Massacre]

Current Project:



Exceptional Journals (in no order): [Eliwood] [Steve Healy] [Ravuya] [Mark the Artist] [Scet] [Ysaneya] [Mayan Obsidian]

My Personal Website


Wednesday, May 23, 2007
Cheers!

Cheers to Gundown for reaching 400 downloads!

Cheers to Magma Duel for reaching 700 downloads!

Cheers to Admiral Overalls for reaching 700 downloads!

Cheers to Membrane Massacre for reaching 4700 downloads!


Cheers for shameless plugging!

Okay, okay. Mainly I just noticed that my last four games all just passed a 100 mark, so I felt the need to write about it. Far less dry than me writing more on BaseCamp -- people want the beef!


Procedural versus Hand-Made Content

In one of the local threads on the forum I stumbled across this neat article on procedural and hand-made content -- looking in particular at Oblivion.

The focus of the article is partly in showing that a full spectrum exists between pure-procedural and pure-hand-made content, and partly about how Oblivion manages to pull off most of this spectrum. It's interesting how effortlessly the NPCs of most MMORPGs fall into which categories, and also how Roguelikes tend to fit into the mix.

Naturally my interest in the topic was on how procedural content and hand-made content relates to Roguelikes (hint hint!). Roguelikes tend to rely primarily on procedural content: level generation, monsters, items, and some even generate quests. However, too much procedural content makes the game repetitive and eventually boring. A healthy mix of procedural and hand-made material is needed for the optimal experience, which I hope gives a hint in the direction that I'm taking our next project in.

What are your thoughts on procedurally generated content?

Comments: 4 - Leave a Comment

Link



Tuesday, May 22, 2007
Just what does the BaseCamp API look like?

Good question, Billy.

I've been aiming to keep BaseCamp as simple as possible, while still offering plenty of behind-the-scene flexibility -- largely via function overloads and optional parameters. Inspiration for the structure of BCGL has been mainly drawn from libraries like Omega, GTGE, and Slick2D.

For kicks, let's go through a few code snippets.

Let's say we want to go and get a new game started. Maybe draw a primitive or two on the screen for the heck of it. We do this by deriving a class from the Game class, from which all games are base'd (har, pun?) off of.

class MyGame : public Game
{
	void startup()
	{
		getLogger()->write("And so it begins!", LOG_INFO);  // full logging system, including multiple channels and console+HTML output
		
		getGraphics()->setLineWidth(3);
		getGraphics()->setLineAntiAliasing(true);
	}

	void update()
	{
		// Nothin'..
	}

	void render(Graphics *gfx)
	{
		gfx->drawCircle(150,150, 64, Colour::red(), true);  // radius-64 circle at 150,150 that is red and filled-in

		gfx->setBlendMode( BLEND_ALPHA );  // many blending modes
		gfx->drawLine( Vector2D(10,10), Vector2D(350,80), Colour(255,0,255,128));   // Can use X/Y points, or supply vectors
	}
};

int main(int argc, char *argv[])
{
	MyGame *MG = new MyGame();
	MG->launch(640, 480, false);  // screen size 640x480, windowed
	delete MG;

	return 0;
}




I'm naturally biased since I wrote it, but I found this fairly straight-forward to use. A user is to derive a class from Game, and then launch it in the main() method. From there, s/he can override the startup(), update(), render(), and also the shutdown() methods to do their bidding.

BaseCamp uses a Java-like 'Graphics' object, which can manipulate anything from the transformation matrix, to the current colour, to the blending mode, to the clear-screen colour, to the Z-layer, and so forth.

Let's play with some images!

class ImageFun : public Game
{
	Image *thor;
	Image *boxman;

	void startup()
	{
		// Top window text/caption
		setTitle("Fun with Images");
		setVersion("Beta 1");
		
		// Colour masking (using fuchsia here)
		getGraphics()->useColourMasking(true);
		getGraphics()->setMaskColour( Colour(255,0,255) );

		// Load Images, which use Textures automatically for you
		thor = new Image( getGraphics(), "thor.png" );
		thor->setFrameWidth(16);  // Set frame sizes for animations

		// Able to access textures directly for low-level access
		Texture *tex = new Texture( getGraphics(), "box.jpg" );
		// tex->getPixelAt(10,10);  // texture reading (for pixel-based collision);
		boxman = new Image( getGraphics(), tex );		
	}

	void update()
	{
		// Nothin'..
	}

	void render(Graphics *gfx)
	{
		// Draw Thor at 100,100 at Z-layer 25, and have his frame go through each of his 6 frames
		thor->draw( 100, 100, 25, getTick() % 6 );
		// Z-layers use the Z-buffer to make sure that everything gets drawn properly, so you don't need
		// to worry about sorting sprites.

		// Lots of options -- Z-layer, centre-of-sprite coords (for pivoting), scaling coefficients, image tint,
		// and blending style.
		boxman->draw( 300,450, 10, 0.5,0.5, 1,1, Colour::white(), BLEND_ADD );
	}
};

int main(int argc, char *argv[])
{
	ImageFun *MG = new ImageFun();
	MG->launch(640, 480, false);
	delete MG;

	return 0;
}




As you can see, image loading, manipulation, and drawing is fairly straight-forward. There's 8 overloads for draw(), all with optional parameters included, so you should be able to do whatever you need to do.

However, manual image drawing can get a little tedious. And so the Sprite class (and SpriteGroup and SpriteManager) are introduced. These are essentially 'game entities' that have their own set of properties, and handle drawing, updating, and detecting collisions by themselves.

The idea is that the Game class (behind the scenes) has a Sprite Manager that manages all of the Sprite Groups in the game. A Sprite Group is somesort of collection of game entities that have something in common for logic handling, like enemies, players, projectiles, and so forth. Using them isn't mandatory, but used properly they can speed things up.

class SpriteFun : public Game
{

	void startup()
	{
		// Colour masking (using fuchsia here)
		getGraphics()->useColourMasking(true);
		getGraphics()->setMaskColour( Colour(255,0,255) );
		Image *img = new Image("boxman.png");

		SpriteGroup *group = new SpriteGroup();
		group->setName("Box Men");

		for(int i=0; i < 50; i++)
		{
			BoxMan *man = new BoxMan();
			// Handy Utils class for commonly needed functions, like int->string conversions, oscillation, lerp'ing,
			// and others.
			man->setName("BoxMan #" + Utils::IntToStr(i+1) );
			man->setImage(img);
			man->setPosition( Vector2D( Utils::Random(640), Utils::Random(480) ) );
			man->detectCollisions(true);    // By default, bounding box collisions are used
			man->setPixelCheck(true);    // Pixel-perfect collisions can be enabled at any time
			man->setColour( Colour::green() );   // Green Box-men!

			group->addSprite(man);  // Add this sprite to the group
		}

		group->addCollisionGroup( group );  // Add itself to its collision list, so collisions will be checked for
		                                    // within the group
		getSpriteManager()->addSpriteGroup(group);  // Add group to the game
	}

	void update()
	{
		// Nothin'..
	}

	void render(Graphics *gfx)
	{
		// Draw Thor at 100,100 at Z-layer 25, and have his frame go through each of his 6 frames
		thor->draw( 100, 100, 25, getTick() % 6 );
		// Z-layers use the Z-buffer to make sure that everything gets drawn properly, so you don't need
		// to worry about sorting sprites.

		// Lots of options -- Z-layer, centre-of-sprite coords (for pivoting), scaling coefficients, image tint,
		// and blending style.
		boxman->draw( 300,450, 10, 0.5,0.5, 1,1, Colour::white(), BLEND_ADD );
	}
};

int main(int argc, char *argv[])
{
	SpriteFun *MG = new SpriteFun();
	MG->launch(640, 480, false);
	delete MG;

	return 0;
}




There's a lot to digest here -- hopefully the comments are somewhat helpful.


Anyways, I'm mostly curious how you generally find the intuitiveness of the library. Obviously I'm throwing a lot around in these examples, and I'm quite biased, so I'd like to know how others see it, and where I can improve on the functionality and user-friendliness. Thanks!

Comments: 2 - Leave a Comment

Link



Monday, May 21, 2007
Low Activity

I've noted that this is only my fourth entry this month, which just might be a universal low for me. Just remember that low post frequency does not imply little development. Very much the opposite!




3D Fun

As a side project, I've been working on a 3D software renderer. One of my resolutions for this year was to get into 3D programming, which I've decided to kick-start by learning how it's really done -- mathematically. I've taken APIs like OpenGL and Direct3D for granted, so I'm really interested in how much work is really going on under the hood..

..and after a couple of weeks of work, I can say without hesitation: a lot! It's been both an extremely challenging and rewarding experience. I've gone from having a handful of vertices rotate around a point, to simple flat-filling triangles, and now to gouraud shading and triangle interpolation. Optimizing has been one of the most difficult portions, which is where AMD's handy profiler came in handy. I haven't looked at its more intricate features, but at the quick-use level it's been great. (I can't believe how much _ftol2 is sucking up!)



(Not beautiful (to most), but hopefully you can see the sweat dripping from the edges of the window. )


The key features you're seeing are:

  • Matrix-based transformations (translations, rotations, scaling).
  • Orthographic projection. (ie. non-perspective)
  • Line-intersection-based triangle filling.
  • Triangle point interpolation (for colours and z-values).
  • Gouraud shading (ie. the way the colour fades across each triangle).
  • Z-buffering (ie. nearer objects obscure further objects).
  • Far too many hours of hard work.


Luckily, since my day job is at the Ministry of Education, there's a nice math teacher across the hall from me that enjoys helping me out with my tougher math-related problems regarding the renderer. Another person worth kudos is Jason Z and his software renderer adventures, who helped inspire me to write my own.




BaseCamp and "The New Game Project" (tm)

While I've been sworn to secrecy by Draffurd, I assure you that we're working very hard on our next game project. We decided to keep things under the radar until we have something to show (read: Milestone One), so I intend on keeping it that way. Hopefully this should be ready within the coming weeks.

Overall, I'm thrilled about this game. It will definitely be the most complex and detailed project yet, but is still manageable. Draffurd's art abilities have improved greatly since our last project, and I've got a number of tricks up my metaphorical sleeves as well.

Up until now, we've mainly focused on fairly 'shallow' games. By that, I mean we've written arcade-style games that aren't particularly deep in terms of gameplay. We expect the average player to dive in, get a few kills, then climb back out into the real world again. To date I've never created a game with a persistent world, with real mounds of content, with anysort of non-simplistic AI. I'm extremely excited at the thought of being able to take a jab at a lot of fascinating new challenges that await me with this genre that we're tackling, and how much I'll get to learn.

The secondary plan is to keep writing and building upon BaseCamp as I go, eventually creating a finished game library which I'll be able to base future games off of -- thus hugely speeding up development start-up time. This is another first: I've never written a library in the general sense of the word. I've always custom-tailored my work to a certain game, so this has been a great experience as well so far.

The tertiary plan is to work on a set of articles as I write this game. I intend to start off with my "2D Game Development with OpenGL" article I've been planning *forever*, and move onto more theoretical and deep topics as I tackle them in the game project itself. I've been dieing to give back to the community, and I figure that if I write these articles as I learn and hone the material myself, I'll retain the knowledge much better than if I were to try and recall it long after the game is completed (like Membrane Massacre and it's "post mortem" *cough*).

In summation, I'm thrilled to be working on this upcoming game project, and I'm sure it'll be received with equal enthusiasm once I tear the mask off of it. I'll try to keep the updates coming as frequently as I can -- I'm getting better and better at juggling my free time with my job.

Comments: 2 - Leave a Comment

Link



Sunday, May 13, 2007
Library Development

BaseCamp (now officially called "BaseCamp Game Library" (BCGL) for copyright conflict reasons) is moving along steadily. Reporting progress about internal library stuff is dreadfully boring to talk about, so I'll spare you all the details. Most of the repetitious groundwork is done, so it's just a matter of implementing the more interesting subsystems now (particle engine, scripting engine, etc) before the library is usable, and my next project can finally commence.

The slow progress lately entirely stinks, but I'm hoping that as I get more and more adjusted to the 'fulltime job' mode of living, I'll keep on getting more work done daily. I've been making daily progress on the train each day -- it's either code or stare out the window -- so I definitely get at least 2 hours of developing per day in. It's just a matter of time!

I'll be posting in fair detail about the inner workings for the particle and scripting engines once I get to them, since I find them to be a bit more of an interesting topic than wrapping SDL/OpenGL function calls or creating animation structures. I'm unsure whether the particle engine will use the scripting engine, but the idea is to have a flexible particle 'AI' format that will allow for tons of interesting particle effects. As for the scripting engine itself, I hope to create a more imperative C/Python/BYOND-like language than my previous Scheme/Lisp scripting experiment.

It's been far too long since I've posted a screenshot, so I'll post an image containing a bit of code, a bit of console, and well, the 'testbed game' that I'm using to test library features as I go. Don't be surprised that things look a little odd.




What you're seeing:

  • Ugly JPEG compression.
  • Usage of the 'Sprite' object (about 50 of them) to make a bunch of spinning Box-Men.
  • Blending (the box in the middle); alpha, additive, subtractive, etc.
  • The code shows the Graphics class, using the Sprite class, a SpriteGroup, and how new games are derived from the base 'Game' class.
  • The logging system, which logs message types to either the console or an HTML file (or both).
  • A nifty little spring-rope system (the blue lines with aqua nodes), to test primitives (ranging from lines to circles to rectangles).
  • Lots of other stuff, like the Vector2D+Colour+Utils helper classes, colour masking, and so forth.

It's a lot of work to do, and feels particularly strange since I've never really written "just a library" with no game attached directly to it. But I'm positive that this will save me a bundle of time down the road for both my next game and future ones.


Invasion: Fall of Man

Programmer16 has been working really hard lately on his game project, Invasion. He has a demo out, so go give it a looksee!

Comments: 5 - Leave a Comment

Link



Wednesday, May 9, 2007
Mobile Gamedev

For some reason I still can't seem to make myself sit down on a worknight and work on a game -- the motivation just never comes. Realizing that this was just plain Not Good(tm), I decided to try taking my laptop with me today to work. Since I already have a fairly lengthy/boring train ride to work and back (one hour each way), I figured this might be a nice time to fit in some game development. Simply put, it worked!

For whatever reason, I'm incredibly motivated to work on my game in the mornings and afternoons, but as soon as I get home it's gone (sans weekends). This isn't as nice as being able to use my evenings to code, but even a solid two hours of game development a day during the week is nothing to complain about.


BaseCamp

Although it's certainly pending a more interesting name, 'BaseCamp' is the name of the pseudo-library that I'm developing for usage as a base for my future games. Reinventing the wheel no longer amuses me, so the intention is to build up a solid and simple (2D) game framework using SDL/OpenGL. It's going to probably take another week or two before it's ready to go, but it will save me loads of hours in the long haul when I use it to create future games.

I don't have any grandiose ambitions for BaseCamp. It won't be anything large-scale like ClanLib or Ravuya's Propane Injector. The emphasis will be on strength and great simplicity. I have no real plans for creating documentation/examples/tutorials, so I doubt it will ever reach the realm of public consumption.


Hitting HTML

I have never had my own website. Ever. I've always really wanted a nice website to display my programming/gamedev portfolio, and other personal whatnots. So my (other) goal over this summer is to brush up on my HTML/CSS and see what I can put together. I've not much experience, so I don't expect anything too too attractive, but hopefully the locals around here will be able to offer constructive tips when I get something up and running.

Comments: 3 - Leave a Comment

Link



Sunday, May 6, 2007
Work Continues

With the first week of my co-op job completed, the weekend certainly felt nice. I feel refreshed enough to endure another five days, and made plenty of gamedev progress during the weekend.


Metaballs!

I've been really interested in this effect for quite some time. It's been scattered about in demos and CGs here and there, but I never really took the time to sit down and read about how it works.

The idea behind metaballs is to have an imaginary 'electrical field' around each ball, which is basically "1 / distance-to-metaball-centre", which you sum up for each pixel on the screen. Every pixel whose sum passes an arbitrary threshold receives the privilege of being rendered.

My first attempt isn't efficient at all (almost purely brute force), but with the ideas I now have I've got some future optimizations planned. This would have made a neat effect in Membrane Massacre, but it has plenty of other cool applications, like blood/water droplet particles that merge together with others as a visual effect.

Kudos to Ryan Geiss' article, which was of great help.


Download Metaballs Demo


(Metalicious!)



Other Adventures

I've also been working on a few other educational experiments behind the scenes lately, such as software-based 3D rasterization and rigid body dynamics. Although I have nearly demo-worthy material to show, I'd like to learn more before I try to talk about the topics around here with any sort of semblance of authority.

Lastly -- and not leastly -- I've been working hard on my game development project for the summer. It's not Skirmish, but it's very promising. I've decided to first develop a flexible library on top of OpenGL+SDL beforehand, since it feels like I've written the basis code for it a million times. I might as well wrap it up for future use in upcoming games. Talking about engine internals isn't very exciting stuff for a journal, so I'll leave it at that, and start posting screenshots as soon as things develop further.

Comments: 3 - Leave a Comment

Link


All times are ET (US)

"Good night, Monster Land." "Good night, brave warrior."
 
S
M
T
W
T
F
S
1
2
3
4
5
7
8
10
11
12
14
15
16
17
18
19
20
24
25
26
27
28
29
30
31

OPTIONS
Track this Journal

 RSS 

ARCHIVES
August, 2009
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
December, 2008
November, 2008
October, 2008
September, 2008
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
October, 2005
September, 2005
July, 2005
June, 2005