I've heard of it, but I think that's a turn based game. Real time games can be quite a bit different to make because the game (rather than the player) sets the pace, which means I have to manage the timing/delays between everything that happens in the game. One aspect of time management is animation. Also in real time games, things have velocity, and positions of characters and projectiles are generally not aligned with the tile grid. So the simulated physics is another aspect of time management. What I like most is that it supports a good number of file types, so I can mix together compressed/uncompressed/samplebank audio, and they can be buffered to memory or streamed on the fly. I just hope my sound functions work properly when it all comes together. Also, I don't have a 3D sound system, so I have no idea if/how much sounds are being moved along the forwards-backwards axis.
Yes, Nethack is turned based. However the reason I suggested it is because of the head crushing depth it possesses. There's a phrase called "The DevTeam thinks of everything." If you put on a silver ring and punch a werewolf, it counts as a silver weapon and does extra damage to them. If you throw a cockatrice corpse at a monster, and it hits, the monster will turn to stone. Ditto for wielding it as a weapon (with gloves, of course!) If you are levitating and you fire something, Newton's second law sends you backwards in the air due to lack of friction. So, there's a lot of neat ideas in there. Just thought I'd throw that out in the open.
Okay. Thanks for your suggestion. I'll consider some of those things, but they do sound best suited to turn based rpg where the player has time to manage an inventory and think about their options. In contrast, the arcade game formula is something like 75% reflex + 25% working knowledge.
Have you actually considered some sort of background story so far, or have you been purely coding? Because although I may be rather useless about every other aspect of designing video games, most of the people I share my writing with seem to think I'm a pretty decent writer.
I haven't considered a background story at all. I normally leave that kind of detail until the end. The main reason being that the design may be revised, and I wouldn't want to feel obligated to fit in with a story. I'll admit that I haven't been devoting as much time to this project as I could have, because I need to feel in the right mood for it. Yesterday evening I began making a map editor. This will enable me (and others) to construct maps by hand, rather than relying on procedural generation. I'm leaning towards having two play modes - a normal dungeon, and a procgen dungeon. Software development involves more than just programming. My project time in the past has broken down something like this: 25% designing / planning / coordinating / decision making / technical content / problem solving 40% art 25% programming 10% other
One editor. Download link at bottom of post. Quite basic, but it's enough to design and edit levels. What is best is that the maps are text encoded so you can open the map files and copy&paste them straight in the forum using code tags. Modding community FTW! Code: 01Yayyyy!! 2B10010101010101010101010101010101010101010101010101010101010101010101010101010101010101010100000000000000000000000000000000000000000000000000000000000000000000000000000000000101000000000000000000000000000000000000000000000000000000000000000000000000000000000001010000000D0D0D0D0D00000D0D0D00000D0D0D0D00000D0D0D0D0D000D0D0D0D0D00000D0D0D00000000010100000000000D0000000D0000000D000D0000000D000000000D000000000D0000000D0000000D000000010100000000000D0000000D0D0D0D0D000D0000000D0000000D00000000000D0000000D0D0D0D0D000000010100000000000D0000000D0000000D000D0000000D00000D0000000000000D0000000D0000000D00000001010000000D0D0D0000000D0000000D000D0D0D0D00000D0D0D0D0D000D0D0D0D0D000D0000000D000000010100000000000000000000000000000000000000000000000000000000000000000000000000000000000101000000000000000000000000000000000000000000000000000000000000000000000000000000000001010000000000000000000000000000000000000000000000000000000000000000000000000000000000010100000000000000000000000000000000000000000000000000000000000000000000000000000000000101000000000000000000000000000000000000000000000000000000000000000000000000000000000001010000000000000000000000000000000000000000000000000000000000000000000000000000000000010100000000000000000000000000000000000000000000000000000000000000000000000000000000000101010101010101010101010101010101010101010101010101010101010101010101010101010101010101
UPDATE: I haven't abandoned this project! I've just had a break from it, and am on a go-slow anyway. Over the weekend I did some of the main programming. The player is fully controllable and 8-way animated, and can fire projectiles. There is also a particle system which I can use to create particle effects when things are destroyed. Walls block sprite movement correctly. The player can slide along a wall by pushing diagonally while against one (doesn't happen automatically in programming!), and my map scrolls smoothly as I walk about. The monsters don't do anything at the moment. The red monster blobs are just a placeholder graphic. The map is limited to 200x200 tiles at the moment, which feels bigger than it sounds. I also have an 'arcade' screen for showing high scores & credits. The snapshot for it isn't very exciting. The rectangle thing is 3D, it spins about and changes shape. There are a few things I'm undecided about - whether to have a stats system and character development, or just collectable power-ups. - whether or not characters can have special skills associated with their class. In Gauntlet, the potions hurt all monsters on screen, independent of character class. - because my maps can be much bigger than Gauntlet, I'm considering if there could be an objective in each level, besides getting to the exit. eg, some special monsters to find and kill before the level is considered complete. - whether exits are two way, so we can move up or down between dungeon floors. This would allow a non-linear structure to how levels are arranged, and levels could be given names rather than numbers. It would also allow for small optional "side dungeons", which the player can raid for specific items/upgrades.
Tonight I've been exploring some different shooting methods. (1) Fixed delay between successive shots. This permits multiple projectiles on screen at once depending on the reload time and the missile flight time. In many ways this is logical for weapons like a bow and arrow, but in gameplay terms feels very metronomic, which I feel is bad. (2) Fixed delay with an energy bank that is depleted with exertion. This is used in Diablo-II. It means that initially the player character can output shots quickly, but after a few seconds becomes tired and fire rate slows. I didn't really like this. The slowing down breaks flow, whereby you have to run away and wait for energy to regenerate. (3) Reload time tied to missile flight time. The reload timer only begins once the projectile impacts something. This means that your player character can have only one missile active at a time, but the reload time is much shorter if you're shooting at something close by. This is how Gauntlet worked. It doesn't feel too bad in my trial, but I remember finding this frustrating in Gauntlet -- If you miss a ghost with your shot, you had to wait for the shot to impact the far wall before you could fire again. It's conceivable that I could use different methods for different character classes. My idea is to have five classes: Knight (tank) -- High HP -- Normal Damage -- Slow Movement -- Short range missiles -- defensive/heroic spells Rogue (melee dps) -- Normal HP -- High Damage -- Normal Movement -- Short Range missiles -- Short range spells Hunter (pull) -- Normal HP -- Normal Damage -- Fast Movement -- Long Range missiles -- Various spells Mage (ranged dps) -- Low HP -- High Damage -- Normal Movement -- Long Range missiles -- AOE spells Priest (ranged healer) -- Low HP -- Normal Damage -- Normal Movement -- Long Range missiles -- Healing spells Any other ideas?
#1 seems most logical, with options to power up the speed, damage, and radius of projectiles as you advance through the game. Classic shmup design.
I did a couple more hours for this game at the weekend, and made a program that generates tilesets from textures. These wall tiles are essentially 3D objects, which are textured, illuminated and antialiased with supersampling. I'm quite pleased with it, especially my blue brick tileset, which is enlarged for your viewing pleasure. See how the textures all line up correctly and line up with the ends of the walls, even though the walls are tapered. Blue Brick Red Block Brown Stone
This evening I've added a proper level loader, rather than keep with the hackish thing I've been using up to now. And this marries the game engine with the procgen algorithm I developed a couple of months ago. For the first time, it actually feels like a game now, as there's something to explore In the level seen here, I've decreased the room size to 5x5. The 16x16 room size felt ridiculously large. With this update I've also discovered my first bug. In game coordinates were originally programmed as single precision, but quite early on I decided to change this and do all game physics in long integers, so converted that code. Obviously something was overlooked because setting a player starting location>(256,256) now crashes the game, but <(256,256) places the player character within the top left wall tile. I will have to investigate this. edit: Bug is solved. As I suspected, it was introduced in the conversion to long integers. As the game begins, the engine has to pre-render the whole screen for double buffering, but as the camera coordinates were set to these new long integers, it was addressing out of bounds, causing a crash. It doesn't apply to a scrolling camera, which is why it hasn't cropped up before.
I'm using visual basic. I'm not using any toolkit. How are you getting on with your world creator thing, Robert? .
I've been a total slacker. It only does the following up to this point: 1. Generates a world heightmap. 2. Distributes terrain types. 3. Generates rivers. 4. Distributes climates. 5. Distributes biomes (based on terrain, rivers, and climate, so this is done last.) I'm basically done with the physical generation of the world, but I'm struggling with defining how plants/animals should be generated. I'm working out a simple DNA format but making it "simple" is not exactly easy, and I've been stuck on it for a while.
One game idea I planned a couple of years ago was based on genetics and evolution, which might be of interest to you. Here's how I designed it: -Define a graph of all life form species. Pure species appear on graph's nodes. Points on the graph's edges can correspond to intermediate forms. So a specific lifeform would be a point on some edge. eg, three nodes might be connected like this: Bears -------- Dogs -------- Cats - Also have 10-20 more variables that allow you to add variation to an organism, such as it's height, or the size of it's wings, thickness of it's fur, or the colour of it's fur. - Evolution allows things to slowly drift around the graph, and that drift happens slowly over many generations. Reproduction can only occur between nearby points on the graph (eg within 1/3 of an edge length). The variation variables allow for quicker adaptation, and get mixed through reproduction.
Well, the way I was going to deal with it was to have a bit string that defines the DNA for a given species. What I had so far were a few bits: 1 - Plant/Animal (for simplicity's sake, I'm not simulating anything else at a species level) 2 - For Animals, determines vertebrate/invertebrate. For plants, determines trunk/no trunk. 3 - Reproduction is sexual/asexual. 4 - For Animals, denotes live birth/eggs. For plants, denotes spores/seeds. It's essentially a phenetic approach rather than a cladistic/phylogenetic approach to classification. I was thinking it would work best logically if every 2 bits represented a specific category of attributes. So, 1 and 2 denote the basics--kingdom and body plan. 3 and 4 denote reproductive traits. 5 and 6 could denote, perhaps, whether the life form is land/water based, and nocturnal/diurnal. 7 and 8? I dunno, perhaps what they eat (and how.) I just need to give it a lot more thought. I want enough bits that there is a lot of possible variation, but not so many it's unmanageable. Since we're talking bits, the number of possible permutations will be 2^(number of bits). If I have just 10 bits, that's over a million combinations! For simplicity's sake, I wouldn't simulate every possible combination, but generate a set number of species, establish food chains, then let the "unfit" ones die off in a "preliminary" simulation. Since the crux of the whole simulation is to get to human civilization, I don't want simulating animals and plants to be any more complicated than necessary. Just enough that they work adequately as finite resources for humans to use/exploit (or be threatened by.)