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. also, imageshack no longer accepts animated gifs? ... bye-bye imageshack. hello tinypic.
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 Next step is allowing particle emitters to be attached to things.
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 more or less finished my particle system now, by making Particle-Types fully user defined. Here is a variation of the previous emitter, seen here emitting a user defined particle-type. Again, sorry I have no proper video. It's perfectly okay to attach multiple emitters to the same object, say if we want to combine this new emitter and the previous emitter as one effect.
On Sunday I worked on the dungeon monsters. 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. Image #3: I've not seen such bravery!
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.
Nice work Jadzia! Can't wait to play it when it's finished! 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!
I like PyGame, although it's dreadfully slow for certain applications. Save yourself some trouble and make sure you learn how to use surface/pixel arrays rather than directly manipulating a surface with get/set calls (which are very slow.)
^^ I'm still learning how to set up a global variable! Lord help me when I get to the stuff you're talking about!
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.
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. 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'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.
Unity has 3 different programming languages. The main two are C#, and Javascript (it's not technically Javascript, but close enough). I use Javascript because it's easier. I'm not really familiar with XNA, but I'd call Unity a pretty solid engine, rather than just a framework. I could try to explain its features, but wiki does it more justice that I could. http://en.wikipedia.org/wiki/Unity3D I plan to hopefully have a gameplay video up next month some time.
My idea has worked, and collision detection has been reduced to O[n] because the monsters now select paths that won't collide with other monsters. They do this by calling dibs on a square on the map, so that other monsters don't go there. Diagonal paths made for a special case. Also, I've changed the way monsters face when they are stationary, which is subtle.
Here is an example of a logic problem I've run into with my game, to give you an idea of what they look like. This evening I've written a routine which tests for missile-monster collisions. If one is detected, then we can go about killing the monster. Sounds simple, yes? Monsters are in a list/array/class called unit[], which has various properties. And because the list of monsters in game could be very large, I've created a second list of on screen monsters in an array uonscr[]. Some commercial games use a similar setup, by having one list of units and one list of active units. For example, complicated AI scripts don't need to be run for all units in an FPS game when only 1% of them are in your vicinity. While in RTS games, a trigger may still need to refer to units removed from the playing field. The way these two lists are linked is like this: If unit i is on screen, then unit->onscreenindex holds the index in the uonscr array corresponding to this unit. Similarly, the j'th unit on screen is unit number uonscr[j]->unitindex. The problem is this: If unit i is killed, how should these two lists be updated? Unit i may or may not be on screen. As with many of these logic problems, I don't immediately know how to solve this. In time I will work it out, but it will require some thought. This is what game programming is mostly about.
Wouldn't this be a matter of keeping two lists of references? Either memory pointers or object references, but the basic idea is the same: there is a "master list" of the items, then an "active list," but both point to the same actual program entities, so if you kill one it should delete it from both lists. Or, rather than "delete" it, set a "killed" bit and just have a periodic cleanup function that runs every so many cycles to get rid of anything with a "killed" bit. That way, you'd not have any null pointer exceptions and be able to defer removing killed units while not having a lot of wasted cycles. I can't imagine "if not unit.killed" would chew up too many cycles versus actually dereferencing it in real-time.
The unit[] array contains the actual program entities, so uonscr[]->unitindex points to it. That deletion involves rearranging both lists, which can create problems with the references then pointing to the wrong things... so the references need to be rearranged at the same time as the lists are rearranged. There's some kind of juggling that needs to be done to make sure the books stay straight, it's just a matter of working out exactly what and in what order. .