1
Programming / Re: Cookie I/O
« on: September 28, 2012, 02:10:22 AM »
You might be able to compile it all to JavaScript with GWT or something.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
Programming / Re: Cookie I/O
« on: September 27, 2012, 08:41:59 PM »
http://docs.oracle.com/javase/tutorial/deployment/doingMoreWithRIA/accessingCookies.html
You have to sign your jar for that to work, though, and it may require that the applet be deployed via JNLP rather than the usual applet tags (but I am not sure!). AFAIK, if you want to access cookies with an unsigned applet, you have to use some JSObject hackery (which will also require you to set "mayscript" in the document where you deploy your applet), which makes it seem a little dumb to not be able to access cookies with an unsigned applet! D:
You have to sign your jar for that to work, though, and it may require that the applet be deployed via JNLP rather than the usual applet tags (but I am not sure!). AFAIK, if you want to access cookies with an unsigned applet, you have to use some JSObject hackery (which will also require you to set "mayscript" in the document where you deploy your applet), which makes it seem a little dumb to not be able to access cookies with an unsigned applet! D:
3
Programming / Re: Lighting Issues
« on: September 26, 2012, 09:30:13 PM »
As for the walls, I had to make every wall adjacent to a "lit" floor space also be considered lit, and not actually cast light on the walls (which makes sense if you think about it: the wall is taking up the whole tile, and no light should be actually "entering" the tile, since it's all full of opaque wall). Even without the lighting issues you are talking about, the player's field of view looked really ugly without doing it that way. I ended up going back through the set of visible cells and adding all of the opaque cells adjacent to visible cells to the set of results, rather than trying to write it into the shadowcasting algorithm.
I do something very similar to what Leaf describes. A solid tile is lit (or not) depending on the light values of its 1 or 2 neighbors in the direction of the viewer. It works for me - good luck.
I did all eight neighbors, as I recall. It makes the player able to "peer" into holes from a distance a little bit too easily, but it made jagged sorts of natural cave walls render much more pleasantly (at least to my mind).
4
Programming / Re: Lighting Issues
« on: September 25, 2012, 11:33:14 PM »
Or precalculate the lighting each time an object moves and store it in some field on the tile, then use that as part of the fov algorithm when the player or a critter or whatever "looks" around themselves, be that for player map updates or monster pathfinding or whatever.
It seems to me like you are recalculating lighting every time a fov is required, which may end up being pretty inefficient. Iunno!
If you don't want to modify your FOV algorithm, you could make it ignore the light level of the tiles and just work on boolean sorts of obstacles, and then walk through the resultant set afterwards and remove all elements that have no light. Edit: Heck, you can't use the lack of light to block vision in the FOV calculation, anyway; otherwise the player won't be able to see things lit by a torch on the other side of a stretch of darkness.
As for the walls, I had to make every wall adjacent to a "lit" floor space also be considered lit, and not actually cast light on the walls (which makes sense if you think about it: the wall is taking up the whole tile, and no light should be actually "entering" the tile, since it's all full of opaque wall). Even without the lighting issues you are talking about, the player's field of view looked really ugly without doing it that way. I ended up going back through the set of visible cells and adding all of the opaque cells adjacent to visible cells to the set of results, rather than trying to write it into the shadowcasting algorithm.
I posted the code in this forum somewhere, if you wanna find it and translate it into the language of your choice. :3
It seems to me like you are recalculating lighting every time a fov is required, which may end up being pretty inefficient. Iunno!
If you don't want to modify your FOV algorithm, you could make it ignore the light level of the tiles and just work on boolean sorts of obstacles, and then walk through the resultant set afterwards and remove all elements that have no light. Edit: Heck, you can't use the lack of light to block vision in the FOV calculation, anyway; otherwise the player won't be able to see things lit by a torch on the other side of a stretch of darkness.
As for the walls, I had to make every wall adjacent to a "lit" floor space also be considered lit, and not actually cast light on the walls (which makes sense if you think about it: the wall is taking up the whole tile, and no light should be actually "entering" the tile, since it's all full of opaque wall). Even without the lighting issues you are talking about, the player's field of view looked really ugly without doing it that way. I ended up going back through the set of visible cells and adding all of the opaque cells adjacent to visible cells to the set of results, rather than trying to write it into the shadowcasting algorithm.
I posted the code in this forum somewhere, if you wanna find it and translate it into the language of your choice. :3
5
Programming / Re: Finishing a Game
« on: September 18, 2012, 01:44:44 PM »
Unless I am getting paid to finish something, I lose steam after all of the interesting stuff is done, and it's time to start making license plates.
7
Programming / Re: Pathfinder + Fog of War
« on: September 12, 2012, 09:34:18 PM »
I think you may have to make the pathfinder consider the fogged areas impassable too, otherwise the player could use it to find cheat paths to areas that seem inaccessable. :3
8
Programming / Re: How about sound effects? Distracting? Fun?
« on: September 11, 2012, 08:41:26 PM »
Even better, make the soundset user-configurable, kinda like OS alert sounds. Then we can turn off the ones we find annoying and leave the rest of 'em on. :3
9
Programming / Re: How taboo is the "borrowing" of public domain tiles?
« on: September 11, 2012, 08:38:30 PM »Just get it working with public domain and change it later to custom tiles in an update if you want to.
What he said.
Most of these sorts of free-time projects lose steam before we finish them. The less work you /have/ to do, the better chance of actually completing something!
10
Programming / Re: How taboo is the "borrowing" of public domain tiles?
« on: September 10, 2012, 11:55:07 PM »
I say use them. That's what they're for! 
11
Programming / Re: Viability of Python
« on: September 08, 2012, 05:06:39 PM »
Python is a great language! I have a little trouble intuiting Python code, because I think my brain has become hardwired to curlybrace languages over the years, but that's my fault, not Python's.
There is probably a roundabout way to get it to work, just like there is for Java and other stuff. But unless you want to have aggrivating hacky stuff on your hands and/or too much work getting something running, I think you're still pretty much stuck with ObjC + XCode for any "real" work on iOS. Apple recently relaxed their insane licensing terms a bit, but as of yet I haven't seen anything else that's really viable yet.
I stick to Android myself. Maybe it's not as cool, but the platform is way, way more open than iOS, and that (in my opinion) makes it a lot easier to develop on.
can Python run on iOS devices (iPad/iPhone)?
There is probably a roundabout way to get it to work, just like there is for Java and other stuff. But unless you want to have aggrivating hacky stuff on your hands and/or too much work getting something running, I think you're still pretty much stuck with ObjC + XCode for any "real" work on iOS. Apple recently relaxed their insane licensing terms a bit, but as of yet I haven't seen anything else that's really viable yet.
I stick to Android myself. Maybe it's not as cool, but the platform is way, way more open than iOS, and that (in my opinion) makes it a lot easier to develop on.
12
Off-topic (Locked) / Re: Mac mini
« on: September 07, 2012, 01:17:53 PM »Finland is the second poorest country in the world after Poland so there is less chance for people to become athletes.
Poland is poorer than Burundi, Congo, and Haiti huh? The recession in Europe must be worse than we realized!
13
Programming / Re: keeping track of multiple enemies health?
« on: September 07, 2012, 08:27:35 AM »
Perhaps this wikibook (which I really ought to get back to work on) will help a bit. It doesn't go as far as making "monsters" per se, though it does roll a couple of characters and have them bash it out over a couple of combat rounds, using the sorts of data structures mentioned above.
http://www.dizzydragon.net/rustybox/book/start
http://www.dizzydragon.net/rustybox/book/start
14
Programming / Re: keeping track of multiple enemies health?
« on: September 07, 2012, 08:14:51 AM »
You need to define a data structure that contains information about a monster, and then instantiate an instance of that data structure for each monster you want to create in the dungeon, and then store those instances in some way that allows you to retrieve them (perhaps a 2d array corresponding to cell locations in the dungeon or something).
If you're using an object oriented language like C++, Java, C#, Python, PHP, etc, you'll want to create a class and instantiate objects with "new". If you're using C, you'll want to create a struct, possibly typedef it to a struct*, and allocate memory with malloc, although that's pretty medieval.
Don't forget to free the allocated memory or delete the instantiated objects when you are done with them, if you are using a language that doesn't do it's own garbage collection.
I hope you are using a language that /does/ do its own garbage collection. That'll make your life a lot easier (most OO languages other than C++).
99% of the challenge of programming stuff like this is figuring out how to arrange your data (we like to call this data arrangement the "object graph" in newer OO-type languages). Once you get that designed, everything else kind of falls into place.
If you're using an object oriented language like C++, Java, C#, Python, PHP, etc, you'll want to create a class and instantiate objects with "new". If you're using C, you'll want to create a struct, possibly typedef it to a struct*, and allocate memory with malloc, although that's pretty medieval.
Don't forget to free the allocated memory or delete the instantiated objects when you are done with them, if you are using a language that doesn't do it's own garbage collection.
I hope you are using a language that /does/ do its own garbage collection. That'll make your life a lot easier (most OO languages other than C++).
99% of the challenge of programming stuff like this is figuring out how to arrange your data (we like to call this data arrangement the "object graph" in newer OO-type languages). Once you get that designed, everything else kind of falls into place.
15
Programming / Re: Importance of persistence
« on: August 31, 2012, 06:37:36 PM »
Was there no way to put RAM in the cartridges of those things?
I think you can do it, though, and have a cool game, but the monsters won't be able to move. :3 And they would be "fresh" again if you ran away and then encountered them again a short time later.
Let's see.... 2 bytes for player's x/y position. If you use a fixed "equipment" list (like in Lawrence's DND), where you have things like "weapon", "armor", "cloak", "boots", "ring", etc, where each "equipment" is just tracked by a "plus", you could get away with a nibble for each item of inventory. Assuming 16 inventory items, that'd be 8 bytes. A byte to store the seed for the level so you can restart the prng. Then maybe.... 16 monsters and 16 loots, as bitfields, that's 4 bytes. That's, what, 15 bytes? Still 11 bytes of ram left for ZP scratch area. Oh, I guess you'd need at least a nibble for the dungeon level, and 6 nibbles for stats (you can fit the 3d6 range into 4 bits if you store the stats as S-3 instead of just S, so there's 3.5 more bytes. Still........
Then just loop through the prng to find values for different parts of the level. The level layout could be generated by the first N bytes returned by the prng. Monsters N+1...n+16, etc etc. Slow, but......
Or you could partition the random number space into "blocks". If your blocks were say, 32 bits wide, you could generate a sequence of random numbers off the level seed up to the number of the block you wanted to access (which you could quickly calculate with a bit shift if the block size was a power of 2). Then reseed the prng with the random number you just got out of it, and generate another sequence up to the byte within the block that you wanted. That'd be much faster than looping through the whole shebang with just one seed....
If you can pull it off, I for one will think it's awesome, given the hardware it is running on!!! Hard to write, without having a stack to call procedures!
I think you can do it, though, and have a cool game, but the monsters won't be able to move. :3 And they would be "fresh" again if you ran away and then encountered them again a short time later.
Let's see.... 2 bytes for player's x/y position. If you use a fixed "equipment" list (like in Lawrence's DND), where you have things like "weapon", "armor", "cloak", "boots", "ring", etc, where each "equipment" is just tracked by a "plus", you could get away with a nibble for each item of inventory. Assuming 16 inventory items, that'd be 8 bytes. A byte to store the seed for the level so you can restart the prng. Then maybe.... 16 monsters and 16 loots, as bitfields, that's 4 bytes. That's, what, 15 bytes? Still 11 bytes of ram left for ZP scratch area. Oh, I guess you'd need at least a nibble for the dungeon level, and 6 nibbles for stats (you can fit the 3d6 range into 4 bits if you store the stats as S-3 instead of just S, so there's 3.5 more bytes. Still........
Then just loop through the prng to find values for different parts of the level. The level layout could be generated by the first N bytes returned by the prng. Monsters N+1...n+16, etc etc. Slow, but......
Or you could partition the random number space into "blocks". If your blocks were say, 32 bits wide, you could generate a sequence of random numbers off the level seed up to the number of the block you wanted to access (which you could quickly calculate with a bit shift if the block size was a power of 2). Then reseed the prng with the random number you just got out of it, and generate another sequence up to the byte within the block that you wanted. That'd be much faster than looping through the whole shebang with just one seed....
If you can pull it off, I for one will think it's awesome, given the hardware it is running on!!! Hard to write, without having a stack to call procedures!