View Full Version : Planar Depths
Thaumaturge
23-12-2007, 03:03 AM
Planar Depths, pre-alpha 2 (http://www.gamedev.za.net/filecloset/download.php?id=520)
http://img120.imageshack.us/img120/9324/planarscreenshotmq3.th.png (http://img120.imageshack.us/my.php?image=planarscreenshotmq3.png)
~
Prototype links:
Prototype 1 (http://gamedev.openhazel.co.za/filecloset/download.php?id=299)
Prototype 2 (http://gamedev.openhazel.co.za/filecloset/data/files/301/Planar_prototype_2.zip)
Prototype 3 (http://gamedev.openhazel.co.za/filecloset/download.php?id=307)
Since the development of Thaumatomech and The Forest is currently delayed, I began, about a week ago, I think, work on something fairly simple, in order to amuse myself and satisfy to some degree my desire to develop.
The game in question is Planar, a simple top-down fantasy "space"-shooter, set at the moment in some outer plane or set of planes.
http://img160.imageshack.us/img160/9141/stormru5.th.png (http://img160.imageshack.us/my.php?image=stormru5.png)
Older screenshots:
http://img254.imageshack.us/img254/1586/enemyandemitterer3.th.png (http://img254.imageshack.us/my.php?image=enemyandemitterer3.png)http://img212.imageshack.us/img212/2326/powerupandweaponsfirede0.th.png (http://img212.imageshack.us/my.php?image=powerupandweaponsfirede0.png)
At the moment there isn't much actual gameplay - as I write this, one can fly about, fire projectiles, and be fired upon by a stationary enemy, into whom one can bump. I'm currently working on a basic ray-casting system for use in determining weapon impacts - once I have something interesting happening (such as the destruction of enemies), I may post a demo, should there be interest. ^_^
The graphics aren't perfect, and nor do I intend on doing everything in a way that would provide. The trails, for example, use a fairly simple, but quite imperfect, system - instead of defining points that fit the curves to either side of the trail of points created, I'm simply using rectangular sections, producing some breaking in turns, and especially when the frame rate lags. However, this doesn't seem to be terribly noticeable in motion - against such a background as this, at least - under what seems to be a reasonable frame rate, and so I don't intend on worrying about it - this project is primarily for fun. ^_^
I don't yet know how to make a fun game out of this - I imagine that I'll want to include obstacles of some sort, in order to provide cover, obstruction and interest in the levels, but beyond that I'm not at all sure.
I do have one problem on which I am particularly hoping for suggestions:
At the moment, the background is a single, large quad which is textured with a 3D texture map which contains 3D Perlin noise. This is fine, and works reasonably well... but is generated a little slowly (it seems to take more than a quarter of a minute for the game to start up using this system). Does anyone know of an interesting-to-look at, fairly simple, fairly fast technique that I might use instead of Perlin noise to generate my backdrop? I've looked at Simplex noise, and while I feel that I understand it, I don't really feel like going into it for this project. ^^;
The Perlin noise texture is being generated at a size of 512x512x8.
I'm open to both pre-generated and real-time methods.
Nandrew
23-12-2007, 03:19 AM
Might we have a look at the prototype? See it in action, so to speak? It looks rather pretty.
Regarding the background: I'm assuming it's static once you apply the noise? Are you sure you can't achieve something similar with a little Photoshop magic and a suitably hi-res image?
Thaumaturge
23-12-2007, 03:56 AM
Might we have a look at the prototype? See it in action, so to speak?
Not a problem - here you go. ^_^
Planar early prototype (http://gamedev.openhazel.co.za/filecloset/download.php?id=299)
It looks rather pretty.
Thank you very much. ^__^
Regarding the background: I'm assuming it's static once you apply the noise? Are you sure you can't achieve something similar with a little Photoshop magic and a suitably hi-res image?
Actually it's animated - I simply cycle the background quad through the texture's depth coordinate to produce a looping "animated" backdrop - which I hope makes it a little less obvious that the backdrop isn't actually changing.
Gazza_N
23-12-2007, 09:19 AM
Neato! Very purty and smooth so far! I especially like the enemy homing missiles - loopy transparent red ribbons of death twisting through the ether to meet your ship and... do nothing at all. ;)
Tr00jg
23-12-2007, 11:22 AM
Looks neat so far. I just had trouble loading and closing (ie no "close" buttong) it, but that's kinda expected from an early early prototype.
Cyberninja
23-12-2007, 11:28 AM
Very cool Thaum. Those red homing missiles are win. Reminds me of Robotech. :) This could develop into something really awesome. ^_^
|-|1Pp13
23-12-2007, 12:27 PM
looks like a realli awsome game!!
Thaumaturge
24-12-2007, 07:05 AM
Thank you very much, everyone! I really appreciate your comments. ^_^
I've uploaded a new demo (linked-to in the first post, along with the original prototype), which includes a simple progress bar on loading, weapon collision detection (which may or may not be updated to identify a point of impact, instead of having the collision appear at the weapon's current position), health loss for both the player and the static enemy, destruction of the enemy, and a simple game loss dialogue.
Looks neat so far. I just had trouble loading and closing (ie no "close" buttong) it, but that's kinda expected from an early early prototype.
Heh, indeed. ^^;
Did you have any problems with loading and closing other than the wait involved in loading and my not having indicated the appropriate button to use in order to close?
Gazza_N
24-12-2007, 07:57 PM
Better and better. :) The loading screen and exit dialog are nice touches, as well as the ability to blow things up. ;)
Quickie: Would it be possible to zoom the view out a little? I had trouble keeping the enemy ship in visual range while ducking and dodging those exceptionally pretty missiles.
Thaumaturge
27-12-2007, 06:16 AM
Thank you, Gazza. ^_^
Blowing things up can be fun, can't it? ;P
As to zooming out, I had been thinking of doing so, and have now altered the zoom level to allow visibility to a greater distance.
I imagine that I'll upload a new prototype in the near future, which should hopefully include something that begins to appear similar to real gameplay. ;)
Thaumaturge
01-01-2008, 04:17 AM
First of all, a very happy new year to all! ^_^
I decided that I wanted my first post on this forum to regard a new version of Planar, and so bring to you prototype 3.
(Look to the first post for the download, of course.)
Since prototype 2, I've added:
A simple HUD (which is unfinished, in that it doesn't yet indicate the current weapon)
Variables to hold the colour and opacity of the HUD
(The HUD colour and opacity may be set via the text file "HUD.txt" in the game directory; the numbers give the red, green, blue and opacity components from top to bottom, in the range 0.0 to 1.0)
A HUD-based direction indicator, giving the direction to the nearest enemy
A new weapon, which can be switched to or from via the right mouse button
Simple (opaque) portals (coloured in a minor homage to Portal)
Gravitational sources (with either normal or negative gravity)
"Storms", which are dangerous to both the player and enemies
Player avatar "death"
For this prototype, I have placed the player amidst four static enemies, with a single health powerup to be found above the topmost enemy.
To quit, hit the escape key and select "Yes" in the dialogue that should appear.
I still intend to implement:
Better weapons collision (looking ahead to the intended implementation of beam weapons)
A main and options menu (the latter allowing one to set the v-synch and fullscreen options, and the HUD colour and opacity)
Exiting to said menu on loss or win conditions
I'm also toying with the idea of simple randomised level goals, such as "collect this" or "destroy that".
I am a little stuck on something, however. The portals, gravitational sources and storms are all intended to add interest to what could otherwise be a rather boring expanse of nothingness. At the moment, the player is more or less free to fly about at will - there is no outer wall. This, however, makes placing "scenery" problematic, in that it means creating it as the player flies and, depending on the objects created, keeping track of it indefinitely. I could restrict the player in one of a few ways, but am worried about that removing the feeling of being on an endless plane.
Does anyone have any suggestions, and if so, what are they?
Nandrew
01-01-2008, 12:58 PM
Hmm, with regards to an endless plane ... great idea, and I can understand your problems.
My best suggestion for your object creation / tracking problem is (and this is considering that you want the "random" approach) is to set a SEEDED random number generator that is guaranteed to generate the same sequence of random numbers every time it gets put to use.
The system then takes a look at some other variables which will frequently change, but ultimately repeat themselves. I'm thinking, for example, the x,y co-ordinates of the player on a "grid" you make -- player's initial position (0,0) -- and then making those into an algorithm of sorts which the random seed generator can use to place objects around the player. For example, grab the value floor(random(x*100)+random(y*100)). If a MOD 3 function returns 0, place a ship at a specified grid co-ordinate relative to the player. Failing that, if a MOD 4 function returns 0, place a gravity well at another set of co-ordinates, etc.
Objects which fall out of a certain radius of the player (say, 1500 pixels) can then simply be destroyed, because they'll be guaranteed to be generated again in the same place if the random seed is regularly reset before the random function takes place.
My thoughts. Gonna take a look at the new proto now. :P
(EDIT) It's NOT going to work out as neatly as this, btw. There's quite a few more obstacles that I can already think of which will need to be overcome. But I reckon something along these lines could work. ;)
Nandrew
01-01-2008, 01:17 PM
Bugger, so I actually got around to running Planar for the first time, and it doesn't seem to like my laptop.
With all three prototypes, I get a cute little white block in the middle of my screen, and a cute little box with the yellow-triangle-exclamation-mark-of-doom which declares "ERROR! -" and nothing else, forcing me to do some Task Manager magic to escape from the program.
I don't know whether this is because you're attempting a bunch of calls which my in-built Intel graphics card doesn't understand, or because I'm running Vista, but I got the same problem across the board for all three prototypes. :(
Thaumaturge
01-01-2008, 06:46 PM
Urk. >_<
On the plus side, I seem to have used that error format only twice in my code, and both times with regards to the setting on or off of v-synch. Perhaps your card doesn't support v-synch being disabled, which is default that I have been using, or perhaps your card doesn't support the function in question at all?
I would appreciate it if you would try this version, in which I specify that v-synch should be enabled, and let me know whether it works: Planar prototype 3, v-synch enabled (http://gamedev.openhazel.co.za/filecloset/download.php?id=308)
If not, it may be that your card doesn't like my attempted use of the v-synch function, in which case I should alter my error-handling procedure, I think.
As to your suggestion for feature placement, thank you very much! ^_^
I had been thinking of such a system, but I think that I had been stuck on the matter of tracking - for which I feel a little silly now, given that I already destroy the storms when they find themselves too far from the player. ^^;
(The storms are currently generated using a random "die-roll", and placed based on the player's position and velocity (the latter being used to reduce the probability of the player speeding past them before they have properly manifested). When they are too far from the player's position, they are summarily destroyed. Note that they are intended to be slightly ephemeral phenomena, and so the player should hopefully not be too jarred if they turn back to find that a storm has disappeared.)
If I understand you correctly, I would essentially be chunking space up into large "tiles" (albeit not in memory), seeding a random number generator based on their tile coordinates, and using that to generate objects surrounding them. Is that correct?
Hmm... I do use the standard random number generator for a number (so to speak :P) of decisions in my game - how would frequent re-seeding, as it seems to me would be occurring in this system, affect that?
I suppose that I could always look up and implement a separate generator for the purposes of feature placement.
Nandrew
01-01-2008, 08:59 PM
Hmm, still seem to be having issues, even with this new version. Much the same error.
With regards to random numbers: I'm not sure what you're working in, but almost any language should easily support switching between specific random seeds and less predictable randomisation.
I'd imagine that if you simply put your randomisation code into a function that begins with something along the lines of randseed(1) and always ends with randomise(), you'll be able to get a consistent set of results within the function while making sure that everything outside it remains more "random".
And yeah, spot on with the tiles thing. Just write some code so that the game can intelligently figure out which new tiles will come into range when the player makes a movement, and run the function on those tiles.
Something else you may want to consider is giving objects some sort of tile_own variable to ensure that no new doodads will be generated in their tile until the old object is first destroyed.
Thaumaturge
01-01-2008, 10:58 PM
Hmm...
It could be that I'm in error in the function that I'm accessing in order to set the v-synch state, or perhaps your card doesn't support the extension that I'm looking for.
This version (http://gamedev.openhazel.co.za/filecloset/download.php?id=309) should provide more information, if you wouldn't mind trying it out please - and even if it doesn't, I've provided a means to circumvent the v-synch setting code. I've included a text file called "Synch_method.txt"; as long as it reads "ON" (case-insensitive, I think), as it initially does, the v-synch code is run. Simply changing this (or, I think, deleting the file) should allow you to run the game without the v-synch code being run.
As to the randomisation, I seem to recall reading somewhere that repeated re-seeding can reduce the apparent randomness of the results, which is why I was concerned - I'm happy to be corrected, however!
As you say, however, calls (I suspect that repeated calls would improve the results) to randomise() should at least help top alleviate the problem, if it does indeed exist.
Something else you may want to consider is giving objects some sort of tile_own variable to ensure that no new doodads will be generated in their tile until the old object is first destroyed.
That's a good idea, thank you - I may well end up doing that. ^_^
Nandrew
01-01-2008, 11:13 PM
As to the randomisation, I seem to recall reading somewhere that repeated re-seeding can reduce the apparent randomness of the results, which is why I was concerned - I'm happy to be corrected, however!
Oooh, watch it, I could well stand to be corrected in turn if you got that from an authoritative source.
I'll try this demo now.
Nandrew
01-01-2008, 11:19 PM
Okay, regarding the error, we've got something. ;)
"Error message: WGL_EXT_swap_control not found!"
This is with the aforementioned switch ON.
When I disabled it (by replacing it with "woof", of course), I managed to run the game ... *except* that the background was completely white and obscured some of the doodads and suchlike. There were small patches of dark clouds which occasionally granted relief from this and allowed me to see all graphics contained within them just fine.
Well, that's something.
Chippit
01-01-2008, 11:27 PM
As to the randomisation, I seem to recall reading somewhere that repeated re-seeding can reduce the apparent randomness of the results, which is why I was concerned - I'm happy to be corrected, however!
You are correct in this regard, I believe. What I would suggest is, if you cannot instantiate a completely different instance of the randomizer (to use for your other random calls), that you retrieve the current seed value from the randomizer before reseeding it for level building purposes. You can then restore the previous seed value to the randomizer, returning it to its previous state, once you're done.
Okay, regarding the error, we've got something. ;)
"Error message: WGL_EXT_swap_control not found!"
This is with the aforementioned switch ON.
When I disabled it (by replacing it with "woof", of course), I managed to run the game ... *except* that the background was completely white and obscured some of the doodads and suchlike. There were small patches of dark clouds which occasionally granted relief from this and allowed me to see all graphics contained within them just fine.
Well, that's something.
It seems that your graphics card simply doesn't suppose that specific OpenGL extension.
Thaumaturge
01-01-2008, 11:50 PM
Indeed, it would appear that the extension that I look for in order to alter the v-synch state isn't supported by your card, Nandrew.
In future version I may allow it to simply fall through without producing an error message - the game should still work, in theory at least.
Oooh, watch it, I could well stand to be corrected in turn if you got that from an authoritative source.
Heh, it was some time ago, as I recall, so I honestly don't know how authoritative the source was, nor whether or not it might have changed in the interim. ^^;
What I would suggest is, if you cannot instantiate a completely different instance of the randomizer (to use for your other random calls), that you retrieve the current seed value from the randomizer before reseeding it for level building purposes. You can then restore the previous seed value to the randomizer, returning it to its previous state, once you're done.
That's an interesting thought - thank you for it. ^_^
I might just do that. I'm not sure how one goes about retrieving the seed from the standard "rand()" function, but I imagine that I can find the answer, and if not, I should be able to find or put together a new generator function, I imagine.
I managed to run the game ... *except* that the background was completely white and obscured some of the doodads and suchlike.
Very odd... o_0
It sounds as though the Perlin noise that I'm using for the backdrop is either not being generated correctly or is being rendered incorrectly.
Aah, but wait - if your card doesn't support the v-synch extension, perhaps it doesn't support the 3D texture extension - the backdrop is a 3D texture rendered to a quad, whose depth texture coordinate is cycled to produce an animated appearance.
I take it that the backdrop (or at least the darker parts of it) didn't animate?
If I'm correct, then the behaviour is odd - perhaps it's rendering the entire thing over itself - all layers at once. o_0
Perhaps the 3D texture mapping is something to take out, or another thing to make optional...
Thank you for trying out the game, and for finding these problems, Nandrew! ^_^
When I disabled it (by replacing it with "woof", of course)
Of course. What else would you replace it with? ;P
Nandrew
02-01-2008, 05:26 PM
My graphics card is an in-built Intel accelerator. If you want to stress-test for compatibility, that'll be some good trial hardware. :P
Also, I've looked quickly through the thread. What are you developing in? You don't seem to have mentioned, and it would be a lot easier to give my thoughts on stuff like randomisation if I knew what language was used.
Thaumaturge
02-01-2008, 08:03 PM
My graphics card is an in-built Intel accelerator. If you want to stress-test for compatibility, that'll be some good trial hardware. :P
*chuckles* I see. Well, it could indeed be useful for such testing, at that, if you're willing. ;P
Also, I've looked quickly through the thread. What are you developing in? You don't seem to have mentioned, and it would be a lot easier to give my thoughts on stuff like randomisation if I knew what language was used.
Aah, my apologies - it seems to be something that I tend to not think to mention. ^^;
I'm developing this using C++ and OpenGL (I haven't yet started work on sound, although I suspect that I'll end up using FMod - I would like to actually have sound in this game... <_<; ), coding and compiling in Microsoft Visual C++ 6 (one of the reasons that I started in on this project was a delay in getting started with Visual C++ 2005). I'm also making use of the Fox-GUI toolkit (http://www.fox-toolkit.org/).
At the moment I use a random value function that uses rand() and RAND_MAX to generate a random floating point value between an upper and lower bound. The generator is seeded using the time within the "World's" constructor.
dislekcia
07-01-2008, 02:05 AM
Regarding all the random talk: You're all right.
Let me explain: Most languages tend to have a random command built into them which returns a random number (or at least something that looks like it to us humans). Exactly how that number is returned and what format it's in is completely irrelevant, but lets assume that we get back a float between 0 and 1. Most random number generators are actually highly complex mathematical sequences, often using strange-attractor-like mechanics to produce numbers that don't seem to follow a logical pattern - despite being completely logical on a more complex scale.
To prevent it looking like the exact same sequence is always appearing every time you start your program (old versions of pascal had this problem very visibly) there's usually some sort of seed input option. The given seed value then becomes a starting point for the sequence, which then uses it's previous value as the seed next time it's called, etc. This means that the seed value is actually a far more random source of entropy in the system, as long as it is somehow made different every time a seed is provided. One of the easiest ways to do this is to pull a seed directly from the machine's system clock, which is exactly what a traditional randomise() function does...
The best seeds (for more "random" behaviour) are often user-supplied... Take the differential of the first 10 or so mouse movements when the game is begun, perturb that by the system clock to prevent users figuring out how to scam the system, and you've got a rather robust random sequence. However, if you want a known progression of random values, simply seed with a known number and make sure that you're always executing the same sequence and number of random calls. As long as your random function is time-independant, you'll get the same sequence every time :)
More modern languages often have a random generation object that you need to initialise. Why not have two random generators: One for inconsequential random needs (like random offsets on visual effects) and another for meaningful pseudo-random numbers that are needed for game logic.
Though, having read through the thread, I don't really understand what the predictable random function would be good for... If you need to ensure a huge playing field, simply go a tiled route and store tile contents in a collection of 4 data structures. As the player's ship nears the edge of one data structure's collection of tiles, write the "furthest" data structure's batch of tiles to disk then simply check to see if the next "batch" of tiles has already been generated or not. If it has, load them from disk, if not it's time to generate all those tiles from scratch.
Your disk-paged files should never get too huge, plus you can ensure non-conflicting file names really easily. If you delete them when you're done with a play session, life is happy. Plus you've also got a reasonably "free" way to save your game state for later save/load functionality ;)
-D
Nandrew
07-01-2008, 02:37 PM
I like dislekcia's way of handling the problem, but I still feel there's merit in predictable randomisation. I guess it would depend on your own specific desires and criteria.
Also, his randomisation spiel makes me wonder if we shouldn't have some sort of "Programming Demystified" section in Dev.Mag.
Heck, it would be really easy, even. People just have to keep an eye out on the forums and wait for dislekcia to say something smart that's +-300 words long, then bring it to my attention.
Easy money, as they say. :P
Thaumaturge
09-01-2008, 02:28 AM
dislekcia, thank you for the extended description of the use of random number generators, and especially for the implementation suggestion. ^_^
I am at the moment just using the result from a clock function to seed the generator that I'm using (the basic "rand()" generator). I've heard of methods that use user input (funnily enough, that idea turned up in a thread on GameDev.net recently, as I recall), but I don't think that it's really necessary for the sorts of things that I'm doing at the moment, as you point out.
I like the idea of combining user input and clock result in determining the seed for "more random" purposes, however (and it may turn out to be rather useful for better environmental feature generation) - thank you for it. ^_^
I don't think that I've come across random number generator objects, at least as standard inclusions in C++ - but then, I haven't really worked with random numbers beyond their fairly basic use, I don't think. Is there a standard C++ random number generator object? If not, do you think that I should look around for one, or would a function put together by myself (using 'net-based references - I'm sure that I recall seeing random number generator code around, such as in an article on Perlin noise) be likely to produce useful results for less time and effort?
As to your level-content-handling suggestion, I really like it - thank you very much. ^_^
Hmm... so instead of re-generating objects that go out of range, simply save to file and load from there if the region in question is re-approached, am I correct? Would that be faster than re-generating them on the fly? I would have thought the hard disk read to be likely to be slower than the processing involved in creating the objects anew...
I do like that it produces a means towards a save system, however, which might well be very useful...
You mention four data structures, however - what would those be? ^^;
~
In other news:
At the moment I'm primarily held back by an uncertainty on the means of representing the "islands" that I want to implement - I have two ideas offhand for logical representation, but am not sure how I might generate reasonably efficient and decent-looking visuals for them. ^^;
I have, however, now come up with what I think is a decent gameplay concept: a supernatural "space"-based roguelike (http://en.wikipedia.org/wiki/Roguelike). The environmental features would stand for rooms (albeit operating in a much more open manner than such rooms), and distance from the origin would stand for the levels of the dungeon. The further that one ventures from the origin, the more and more powerful the monsters become. I even hope to come up with a full twenty-six monsters including, hopefully, some form of analogue for each of Aquators, Giant Flytraps, Ice Monsters, Phantoms, Dragons and perhaps Xerocs. I'm considering the random generation of weapons, and perhaps a form or "armour" (which the Aquator-analogue would of course drain instead of health ;)). I don't intend to implement analogues of the special abilities of the Wraiths, Vampires, Nymphs, Leprechauns or Medusae, however, largely because these can be rather annoying, I feel.
I don't yet know what the object of the game would be - I'm considering a quest for an item or items (as in Rogue), a search for an exit, or simply trying to reach deeper and deeper regions of the plane.
dislekcia
09-01-2008, 12:20 PM
Void Escape - Dream Build Play Competition Entry
================================================
By Danny "dislekcia" Day
dislekcia@gmail.com - http://www.gamedotdev.co.za
Controls:
---------
Left Stick = Movement + Strafing.
Right Stick = Turning.
Left Trigger = Activate module - default weapon.
Right Trigger = Activate module.
X = Activate module.
Y = Activate module.
B = Activate module.
A = Interact (when possible).
Left Shoulder = Open inventory.
Void Escape is a free-roaming top down shooter
roguelike. You control your ship with the two
analog sticks and trigger your various equipment
with the left and right triggers, X, Y and B.
A is reserved for interaction...
IMPORTANT!: The left shoulder button brings up
your inventory, which allows you to equip and
upgrade the weapons, engines and various other
loot that you pick up.
Platform:
---------
The game was designed on Xbox 360.
Hehe ;) I love the idea of a space-based roguelike. Go for it!
-D
Thaumaturge
10-01-2008, 12:11 AM
Void Escape - Dream Build Play Competition Entry
================================================
By Danny "dislekcia" Day
dislekcia@gmail.com - http://www.gamedotdev.co.za
...
Void Escape is a free-roaming top down shooter
roguelike.
...
Noooooo! And here I thought that I had something original! T-T ^^;
Hehe I love the idea of a space-based roguelike. Go for it!
Thank you very much - I think that I will. ^_^
I'm currently undecided on the matter of equipment other than weapons and perhaps some sort of supernatural "armour" - I've decided to see how I feel about it once the game as envisaged at the moment is more or less complete.
Thaumaturge
26-03-2008, 11:20 PM
*casts Animate Thread*
Believe it or not, this project is not dead - although it did admittedly stall (along with a few other things ^^; ) during my brief absence from the forum.
In fact, I have a new version to share (which will hopefully make up, to some degree, for the idea-in-search-of-gameplay that was Inevitability ^^; ):
Planar Depths, alpha 1. (http://www.gamedev.za.net/filecloset/download.php?id=412)
Lasers are fun!
http://img141.imageshack.us/img141/3332/capture26032008182700nk4.th.png (http://img141.imageshack.us/my.php?image=capture26032008182700nk4.png)
... Although the enemy sometimes gets them too...
http://img177.imageshack.us/img177/493/capture26032008182738co5.th.png (http://img177.imageshack.us/my.php?image=capture26032008182738co5.png)
Pretty green light. ^_^
http://img137.imageshack.us/img137/2842/capture26032008182848gl0.th.png (http://img137.imageshack.us/my.php?image=capture26032008182848gl0.png)
~
The further you travel from the origin, the more and more dangerous your foes become (although at the moment I have only two enemies implemented, so it's more the former than the latter ^^; ).
Unfortunately, I have yet to implement enemy AI (although I have a tentative plan for that), so the two opponents available just sit there and fire at the player.
Killing an opponent produces "powerups" of a few types - weapons, shields, health and points ("star shards"). Note that all items of a particular type look the same - it is only on picking one up that any differences are apparent. Another powerup type, "item", is not yet fully implemented, and so no enemies yet produce that type of powerup. (In the final version, I intend to make the specific item or weapon collected be apparent on pickup.)
Pressing the 'l' key should open a portal; flying into this portal should take you to a new "level" of the plane (although at the moment there is only one type of level other than the initial level, which should be reached on the second jump).
~
A fair bit has changed "under the hood" - in particular, I've moved away from the subclassing-and-virtual-functions and generally hard-coded design that I seem to recall that I had originally intended when this was to be a smaller project. The result of this in the weapon design is a more flexible system that has produced a few rather cool weapons (I think); the array of weapons available in this version does not, I'm afraid, represent the full range of the system. Of perhaps particular note in their absence are seeking weapons and weapons that fire more than one shot per firing, both of which are possible.
~
Known issues:
- The current weapon is not yet depicted
- Enemy AI has not yet been implemented
- The trails could use replacing - the current system is inefficient, and shows its seams under certain conditions.
- The island seed calculation should, I think, be improved - it currently produces unwanted symmetry about the axes.
- The score section of the HUD isn't always terribly readable - this would seem to largely be the result of my having switched from blending the HUD additively to blending it "normally", and the score display not having a darker outline to allow it to stand out against some backgrounds.
FuzzYspo0N
27-03-2008, 12:03 AM
wowo lol...i got really surprised by the speed, maybe a sorta slow to really fast acceleration would be easier...
Also, i like the style. as uv mentioned most things, the only thing is i went to see how far out i cud fly and after a short while i got some EPIC lag, and then more and then it crashed. also,
half way thru my second time, i was accelerating. i alt tabbed, or clicked outside (iv tested this bug a lot in games) and clicked back and it was permanently accelerating mode. like it just flies and flies in the direction i was going already. dunno if its a code thing or what :)
Cool progress
Thaumaturge
27-03-2008, 02:03 AM
wowo lol...i got really surprised by the speed, maybe a sorta slow to really fast acceleration would be easier...
Heheh, perhaps - although I'll wait for further opinions on this, I think. Naturally, I'm quite used to the speed at which it runs... unless, of course, a CPU-speed bug has crept into the works (although I doubt that).
Ironically, it's probably playing less fast than you think - I seem to recall that when I set the background to "move" at the pace at which the player actually moves, the game seemed rather slower. ;P
At the moment, as I recall, the background actually "scrolls past" faster than you're really moving, although islands and enemies should move properly relative to you.
Also, i like the style.
...
Cool progress
Thank you very much! I appreciate that. ^_^
the only thing is i went to see how far out i cud fly and after a short while i got some EPIC lag, and then more and then it crashed.
*hisses* That's probably either a memory leak or my threads or islands not being cleaned up properly - I've made a note of that, and intend to attempt to replicate the error and try to hunt down the bug. Thank you very much for pointing this out!
also,
half way thru my second time, i was accelerating. i alt tabbed, or clicked outside (iv tested this bug a lot in games) and clicked back and it was permanently accelerating mode. like it just flies and flies in the direction i was going already. dunno if its a code thing or what
Heh, yes, I'm pretty sure that I know why this would be.
Simply put, (and barring a few individual cases,) when a key press of interest is detected, an appropriate flag is set to "true". When the same key is released, that flag is set again to "false". Within the game logic, the states of the flags of interest are checked and appropriate action is taken.
If, however, you alt-tab out of the game while a key is held down and release the key while outside of the game, the "key released" message is not delivered to the game, and so the flag is not set to "false" again, and your avatar keeps going.
I daresay that had you simply pressed and released the direction keys that had been held down when you alt-tabbed (I presume that you had at least one held, since you say that you were accelerating) you would have stopped accelerating. ;)
I believe that I know how to fix this, although I'm not sure that it's serious enough to warrant it. Thank you, however, for pointing it out! ^_^
Thank you very much for all of your feedback. ^_^
FuzzYspo0N
27-03-2008, 09:32 AM
I believe that I know how to fix this, although I'm not sure that it's serious enough to warrant it. Thank you, however, for pointing it out! ^_^
if gameplay is completely halted and i cannot play after it happening, it certainly warrants fixing in my view.
Especially with the controls how they are, it was all too easy to hit outside the window with my mouse. Once that happened, i was no longer able to play because i was no longer playing, it was playing without me. it is weird but it sucked, i can guarantee not a sinlge player wud carry on playing if the game "broke" like that.. :)
Thaumaturge
27-03-2008, 03:42 PM
But it should work again if you alt-tab back to the game. :P
(I presume that we're talking about the control glitch that occurs when the game loses focus.)
Admittedly, the fact that it occurs when one clicks out might be disorienting, and I find that for some reason simply clicking on the window again doesn't work - it seems that alt-tabbing back in is required.
That said, I do intend to have it run in full-screen mode eventually (windowed mode is more convenient for testing), with windowed mode as an option; running in fullscreen mode should dramatically reduce the problem.
Nevertheless, I will attempt to fix it, then - it should be a quick-enough fix, in any case.
FuzzYspo0N
27-03-2008, 09:30 PM
no whati meant is if im outta focus the player can move sure, thats normal. but when back in the game its permanently in moving state STILL , no matter what im pressing
Thaumaturge
27-03-2008, 11:46 PM
Heh, I know - that's what I mean. It seems that simply clicking back into the game didn't give the game keyboard focus; alt-tabbing into it, or (I think) clicking on its tab in the taskbar should return keyboard focus to the game, allowing you to control the avatar again.
Note that this is under Windows XP; I don't know how it might react to other versions of Windows, I'm afraid.
That said, I believe that I have the bug fixed for the next version (I want to be confident of the lag and crash bugs being dealt with before posting a new version, however, and might want to add in a new feature or two as well).
[edit] On re-reading my previous post, I can see that I might have been ambiguous - my apologies. ^^;
FuzzYspo0N
27-03-2008, 11:52 PM
cool, keep it coming :)
i get ya now. i tried the alt tabbing thats a bit of fail :P but its cool, shud be easy enough to work around
Thaumaturge
27-03-2008, 11:55 PM
Indeed, and thank you. ^_^
As I said, I believe that I have it fixed now, to be released in the next version.
Thaumaturge
20-05-2008, 02:38 AM
*checks his available mana, then casts Animate Thread on this one too*
I considered starting up a new thread - the title of this one is now inaccurate, and the game has changed somewhat since the state as of the first post - but I felt that this was a better idea.
Dislekcia, would you please change the title of the thread to simply read "Planar Depths"? (Unless, of course, the ability to edit thread titles has been added, of course, although a quick look didn't reveal it to me, I'm afraid.)
Anyway, on to the game, and my reason for this post.
At the moment, the game is pretty much entirely action, something that I'd like to break up a little. Specifically, I want two things: "safe" levels, and, perhaps, puzzle levels. Both would fall into the new, limited-range levels that I intend to introduce (becoming present alongside the "normal", "infinite" levels, not replacing them).
My problem, then, is in what I might place in these levels.
I want the "safe" levels to include something for the player to look at, preferably something strange and, hopefully, in some way "aetherial". Furthermore, they should be procedural, allowing for variation between encounters. At the time of typing, I think that I have only two ideas:
Shoals of harmless creatures (which some may have noticed in the last prototype), perhaps including points of interest for them to move between, and perhaps some basic, again procedurally-produced, interaction with their environment.
Cellular-automaton-like "creatures", that expand from a central point according to rules, hopefully making interesting patterns as they do so.
Unfortunately, I don't seem to have even that many ideas for puzzle levels. Again, the puzzle specifics should be procedurally-generated, but I would like them to also be reasonably brief in at least most cases, and all interaction should be available via firing at "trigger" objects (buttons, for example).
Does anyone have any ideas for these levels, and if so, what are they? I could really use some inspiration, I think. ^^;;;
dislekcia
20-05-2008, 04:36 AM
Ooh, I like the harmless creature ideas. The cellular automata one in a doozy... What about creatures that react to the music in the game (in the final version) and follow related paths and/or form patterns accordingly? There's also the idea of creature swarms that trace the paths of strange attractors and/or form fractal shapes, that would be awesome...
-edit- In an action game, bosses are typically puzzles. I would suggest trawling shmups for good boss ideas. As well as thinking about ways that a player could affect 2D space with their ship, smacking asteroids around, protecting weak areas/units from harm, moving a shield around, creating chains of tractor beams, maybe even some sort of limited turret defense mode.
However, there's nothing wrong with action for action's sake. Safe levels to sell stuff or refit equipment are cool, but I would consider those almost inbetween session menus to get the player ready for the next round.
-D
P.S. Renamed :)
Thaumaturge
20-05-2008, 06:28 AM
Those sound like some good ideas, Dislekcia - thank you!
I very much like the ideas of tying creature movement into such things as strange attractors and fractals and having them react to the music being played. I'm not sure how well I'd handle the music idea - I feel that such things are a bit of a weak point of mine ^^; - but it may well be worth trying. ^_^
As to the utility of safe levels, I'm thinking of them more as places to take a bit of a break between action stretches, and in which to look at something pretty - at the moment my "infinite" levels are a little same-y - seemingly endless expanses of Perlin noise, cluttered with semi-transparent anti-gravitational "islands" and populated by ubiquitously antagonistic monsters (http://tvtropes.org/pmwiki/pmwiki.php/Main/EverythingTryingToKillYou). :P
As to the action levels:
Hmm... Bosses might be a good idea... I was already planning on having some levels be "lairs" for the most powerful of the creatures that I have planned (which was directly inspired by Rogue's dragons) - perhaps I could upgrade them a little, giving them more complex natures that call for some strategic thinking, perhaps even procedurally-driven weaknesses and abilities...
The other ideas, too, sound interesting - I should think on them more, I believe.
Of course, all of this probably bears more thinking on once I've had some sleep - I've spent quite some time tonight looking through the forums of a handful of engines that I'm considering for a large project that I want to take on. I've gathered a little more information, I think, but not an awful lot.
Thank you again, and thank you for the rename - I appreciate it. ^_^
Gazza_N
20-05-2008, 10:05 PM
smacking asteroids around, protecting weak areas/units from harm, moving a shield around, creating chains of tractor beams, maybe even some sort of limited turret defense mode.
Win!
As to the utility of safe levels, I'm thinking of them more as places to take a bit of a break between action stretches, and in which to look at something pretty - at the moment my "infinite" levels are a little same-y - seemingly endless expanses of Perlin noise, cluttered with semi-transparent anti-gravitational "islands" and populated by ubiquitously antagonistic monsters (http://tvtropes.org/pmwiki/pmwiki.php/Main/EverythingTryingToKillYou). :P
Being far more artistic than me, you've probably considered this already, but a change in background colour goes a long way to break monotony. Space sims do it all the time with nebulae, differently-tinted suns, etc. You may not have to do anything overly elaborate with your Perlin backgrounds to keep things visually dynamic, although varying styles of free-floating doodads and creatures would obviously add to that.
Thaumaturge
20-05-2008, 11:52 PM
Being far more artistic than me, you've probably considered this already, but a change in background colour goes a long way to break monotony. Space sims do it all the time with nebulae, differently-tinted suns, etc. You may not have to do anything overly elaborate with your Perlin backgrounds to keep things visually dynamic, although varying styles of free-floating doodads and creatures would obviously add to that.
Examples of things that have been possible for some while now: ;)
http://img504.imageshack.us/img504/8845/redsm2.th.png (http://img504.imageshack.us/my.php?image=redsm2.png)http://img171.imageshack.us/img171/5003/bluecu1.th.png (http://img171.imageshack.us/my.php?image=bluecu1.png)http://img241.imageshack.us/img241/6932/rainbowdd8.th.png (http://img241.imageshack.us/my.php?image=rainbowdd8.png)
Similarly, I'm pretty sure that my implementation should successfully allow me to specify the creatures available in a given level, as well as weighting the probability of their appearance (although they are still weighted by their danger level). I don't have many enemy types implemented yet, I don't think, so the system hasn't been terribly well-tested, but initial results seem to indicate that it works.
Are there improvements that you suggest? I'd prefer to not change the algorithm too much, but I am open to suggestions. ^_^
The main problem, I think, is that these colours extend over the entire level. If I were to find a way to encourage players to change levels fairly often, this would be less of an issue, however, I suspect.
Oh, and I forgot to include one planned idea in my previous post. I want to include what I call "sage spirits" - essentially pale blue-white star-like entities that sit stationary in levels. When the player stops on one, they produce a line of text - a saying, perhaps, or piece of advice, or pithy remark, or humorous line - and deactivate (that is, you get only one line per "spirit").
Thaumaturge
27-06-2008, 02:03 AM
A new version is available: ^_^
Planar Depths, pre-alpha 2 (http://www.gamedev.za.net/filecloset/download.php?id=520)
http://img120.imageshack.us/img120/9324/planarscreenshotmq3.th.png (http://img120.imageshack.us/my.php?image=planarscreenshotmq3.png)
(My description of the previous version being an "alpha" was, I realise now, inaccurate, since it remains feature-incomplete.)
In this version:
More enemies (including, should you get that far, some rather nasty ones...), and some fairly minor alterations to the familiar red-and-black enemy.
Portal powerups - collect these to allow you to open portals with which you can move to other planes.
Loss and win conditions, and accompanying screens (okay, there was a loss condition in the previous version, but it didn't do much - you just sat there and stared at the "fire" where your avatar had once been.
Basic menu system.
A variety of weapons (all but two acquired by killing enemies, although not all enemies drop weapons).
Limits on the number of enemies that may be present at a time (to prevent the player being swarmed too badly).
Not much in-game guidance. :P
There are, I'm afraid, still bugs, including a crash bug or two and an odd "disappearing islands" (and possibly enemies too) glitch.
On a more positive note, I've decided on a story for the game (although it hasn't been properly incorporated into the game), which also explains why the player is collecting "star shards". It seems that the character's material world lacks a moon or stars, and thus has nights that are deep, pitch black without he itervention of some other light source. The player's goal is to enter the planes, in which an aetheric artefact has been detected. Specifically, a moon.
Yes, you're going to collect a moon and, incidentally, stars, wth which to light your world's night-time sky.
My plans for this game have been somewhat revised. I've decided to largely drop the puzzle idea, but am now looking for some way to provide some sense of progression, and, preferably, more incentive to engage with enemies. One idea that I'm considering, in terms of progression, at least, is reviving an element from an earlier game of mine that was very much like this (very much indeed; although the main gameplay and story was different, it was also an action-based game in a space-like aetherial world): planar "cities" along the way. I don't know what gameplay purpose I'll give to them, or how they'll be accessed, but I'll probably keep them fairly small and simple, using the "pocket plane" system that I already have in place and still intend to use for fairly minor "rest stops".
The names of these "cities", by the way, were (and are intended to be) something along the lines of "spiritsflow", "heartsglow" and "mindsturn". :P
Powered by vBulletin® Version 4.2.4 Copyright © 2019 vBulletin Solutions, Inc. All rights reserved.