Please note: we have been online over ten years, and we want The Trek BBS to continue as a free site. But if you block our ads we are at risk.Please consider unblocking ads for this site - every ad you view counts and helps us pay for the bandwidth that you are using. Thank you for your understanding.

Welcome! The Trek BBS is the number one place to chat about Star Trek with like-minded fans. Please login to see our full range of forums as well as the ability to send and receive private messages, track your favourite topics and of course join in the discussions.

If you are a new visitor, join us for free. If you are an existing member please login below. Note: for members who joined under our old messageboard system, please login with your display name not your login name.

This evening I've been improving the particle system by adding particle emitters. These are objects that produce particles, to create specific particle effects.

Here is my first particle emitter, that creates a fire effect wherever it is positioned. This one has a three second life.

Particle emitters can be statically planted in the gameworld, or can be attached to moving objects, like projectiles. So a wizard's fireball might have a particle emitter attached to it while it is in flight, so adding low level detail to that projectile.

That looks pretty slick! Are you planning to charge for this game or what?

I wasn't planning to.

Game programming is just a pastime for me ~ a reward in itself. It's complex enough to be mentally stimulating and creative enough to be enjoyable, but I don't consider myself to be skilled enough to produce games of salable quality.

From a couple of my past games, friends have told me that I should put them on steam. I did join the indiegamer forums (which is a networking forum for many of the people who author games for steam and bigfishgames) but wading through the elitism and bitterness there, the message I kind of got was that most independent games make peanuts.

The only games to reliably make more than peanuts are match-3 games. Only very rarely does a game do well, and for no rational/imitable reason, it's popularity then grows exponentially and it goes global, like minecraft is doing now and plants vs zombies and world of goo did before it.

I've made my particle emitters with similar customization to the sprite emitters in ActiveWorlds, but with added damping terms that can be used together with acceleration to simulate wind acting upon the particles, a la Stokes Law.

My particle emitters can now also be formed from particle emitter types (eg pre-defined fire effect), so avoiding the need to specify all of an emitter's variables each time one is spawned.

So now let me see what I've got...
Particles
Particle-Types
Particle-Emitters
Particle-Emitter-Types

Particle emitter attachments have worked first time, which doesn't often happen. I was a bit undecided how I was going do them last week: As emitters/units/missiles are destroyed, emitters have to be updated so that they stay attached to the correct things. I thought this would involve an increase in computational complexity to process that extra subroutine loop, but I've managed to do it with some clever cross referencing, and keep the complexity the same, so am happy.

A wizard's fireball

Sorry for the choppy animation (I can't be bothered grabbing a proper video), but it illustrates the effect.

- First emitter is created with the missile, and is attached to the missile, adding a fire/trail effect.

- Second emitter is created when the missile is destroyed, and is attached to the ground, adding a blast effect.

//edit: I've changed the emitter slightly so that particles take the motion of their owner missile into consideration, making less of a fire-trail and more of a fire-ball. It looks ten times better. The fireball feels cohesive, making it seem hotter, and feels quite fluidic and sloshy because it splashes up against the walls on collision. You'll have to wait for the beta to see it

I've posted an image already showing monsters in the game, albeit with a placeholder graphic.

First thing I did yesterday was to begin writing the AI routine for the monsters. Here you can see an acquisition behaviour, where the monsters move to intercept the player, while respecting collision detection with one another and with respect to the maze walls.

Image #1: Attack of the mutant jello moulds.

Here is the same behaviour after I added monster sprite sheets instead of a placeholder graphic. These are animated.

Image #2: Red Wizard is about to die.

After slowing the monsters down to sensible speeds, here you can see Red Wizard shooting a fireball towards one of the Blue Wizard mobs. Now that the particle system is done, it's easier to refine the appearances of things. I feel this is a better looking fireball than those I've posted previously.

How did I manage to miss a game programming thread? Great to see some people interested in making games!

Looking good so far, and I can see a lot of work going into the fundamentals of the gameplay and engine. It looks like it's all paying off nicely too.

I'm making my own little game right now. A 2.5D platformer (actual 3D graphics, not 2D sprites), in a program called Unity, designed specifically for 3D games, and the base version is completely free. I might publish my game on the App Store at some point, although at the moment I'm just messing around with it as a PC game.

I've decided to learn Python and eventually move up to PyGame. Seeing what you've accomplished has inspired me quite a bit. Good luck!

__________________"Good grief. You guys sure know how to make something out of nothing. And then take sides about whether or not it's nothing, and then change your minds and discuss why you thought it was something." - Kestra

I'm still learning how to set up a global variable! Lord help me when I get to the stuff you're talking about!

__________________"Good grief. You guys sure know how to make something out of nothing. And then take sides about whether or not it's nothing, and then change your minds and discuss why you thought it was something." - Kestra

I think Python is a good choice as a language to learn programming with, but PyGame is not the easiest toolkit to work with. It requires some understanding of general game programming concepts. I'd be happy to help you out if you run into any trouble, though.

I've decided to learn Python and eventually move up to PyGame. Seeing what you've accomplished has inspired me quite a bit. Good luck!

Good luck to you too! Game programming is as much an art as it is a science. It can be mentally demanding, but is also very creative and expressive. It's always a good feeling seeing your game slowly emerging, and realising that all it's doing is juggling this big set of numbers according to the commands you've written down.

I haven't had much exposure to python, but I believe Basic has always been the easiest language to learn.

As for games, you really need to be able to program before you can make games, as it's an order of magnitude more complex.

Computer games are mostly mathematics, physics, logic, and drawing.

- The mathematics is usually no more complex than school geometry, algebra, a bit of calculus, and a bit of numerical analysis.

- The physics is of the classical mechanics variety. You can often make this as complex as you want to, or as simple as you want to, and will determine how advanced your game engine is. You'll probably find this part straight forward if you have a science background.

- The logic in games is almost always quite involved. You can rack your brain trying to work out what is needed, and making it fit nicely with the rest of your project. This is a programming skill that you learn over time, and it can take many years to get good at it.

- Also, without keeping your project organized the logic can easily get messy and you can lose track of how it all fits together. It's hard to explain what this being organized is, but it may involve keeping functions pure and resisting temptations to kill two birds with one stone. I personally find it the most tedious part of programming.

I have some adjustments to make to the monsters, because I don't like the O[n^2] collision detection I have at the moment. I may introduce spatial partitioning, but I have another idea I'd like to experiment with first.

BlobVanDam wrote:

How did I manage to miss a game programming thread? Great to see some people interested in making games!

Looking good so far, and I can see a lot of work going into the fundamentals of the gameplay and engine. It looks like it's all paying off nicely too.

Thanks I've always felt that feeling is as important as function, so I'm prone to scrapping ideas and changing my plans if I don't like the feel of how something is turning out. The end result can be quite different from my initial design.

I'm making my own little game right now. A 2.5D platformer (actual 3D graphics, not 2D sprites), in a program called Unity, designed specifically for 3D games.

I've heard of Unity, but I've never looked at it. What language is it based upon/similar to? Is it a complete engine, or is it just a framework similar to XNA?

Good luck with your game. You'll have to show us some snapshots sometime.