 |
Castle Paradox
|
| View previous topic :: View next topic |
| Author |
Message |
Kizul Emeraldfire
Type: Cyber Dragoon
Joined: 26 Mar 2004
Posts: 229
|
 Posted: Sun Oct 12, 2008 7:34 pm Post subject: Quick question (making some'n' different for the OHRRPGCE) |
 |
|
Now that the O.H.R.RPG.C.E.'s WIP builds have 'plot-sprites', in addition to custom menus and other spiffiness, it will be easier to make games that it's not supposed to be able to make, like what I'm about to explain below.
I'm going to go a little beyond what I think anyone's done before and make an adventure RPG, in similar style to Willow (NES), and The Secret of Mana/Sword of Mana (SNES/GBA, respectively), using the O.H.R. and a ton of plotscripting, tags, and NPC manipulation.
Now, to get to the point of this thread: would it be better to make this game by coding the whole thing from scratch in something like C# or C++ or whatever, or would it be better/easier (if not wholly recommended) to make it with the O.H.R.?
If the latter, how do you recommend scripting enemies, as far as 'hit detection' goes for different levels for the hero? >.> I'm wanting to try and do something with variables and/or actual enemy stats instead of tags, since you only get 998 to work with (and I get the feeling I'm going to run out of those tags very quickly), but I'm not sure how to proceed with it. :/ That, and collision detection on walls and with other sprites and things completely baffles me. Enemy AI might also, but I at least have an idea how I'll do it.  |
|
| Back to top |
|
 |
NeoSpade
Of course!
Joined: 23 Sep 2008
Posts: 249
Location: Wales GB
|
| Posted: Sun Oct 12, 2008 10:03 pm Post subject: |
|
|
umm, not sure if this is handy, but try looking up the 2006 collab game, chapter 1 has a kinda cool system, that (I belive) TwinHamster used the other hero stats for the enemy stats, you should really direct this question at him. Also you might wanna look here: http://moogle1.castleparadox.com/zelda.php by using all this info you should have no trouble at all, I was actually thinking about doing a game that used this, but I haven't came 'round to it yet, maybe next year eh?
EDIT: Kinda cool system isn't the word actually, I fell in love with it...TwinHamster is using it on bubble breaker aswell so I belive. |
|
| Back to top |
|
|
TwinHamster
♫ Furious souls, burn eternally! ♫
Joined: 07 Mar 2004
Posts: 1352
|
| Posted: Mon Oct 13, 2008 5:52 am Post subject: |
|
|
Someone doing research into my work? This is awesome.
The game would be easist to make in whichever system you are most familiar with.
If you know enough C to pull it off, then go for it.
Otherwise, it is possible to pull off such a project with the OHRRPGCE.
Moogle1's Metamorphosis also used a SOM-esque system and is kind of neat.
He was also nice enough to include the script that he used!
As for your other questions:
Hit detection: In Chapter 1 of the Collab Game, I just checked the tile position that my hero was directly facing, put a sword animation there, checked to see if the sword was on top of an enemy, and pulled off the enemy hurting script if it was.
This pretty much only works on a tile-system, and it was pretty buggy.
Foe Stats: I think that in the same Chapter 1, I made every enemy have one hit point, so that they all died in one hit (For my convenience).
However, for the boss of the game, I gave him a custom set of stats because he was a unique copy of that enemy.
In Bubble Breaker, all battles are fought in duels, so I can conveniently put all of an enemy's stats inside of a dump hero, as Neospade mentioned.
This technique would probably not work very well with multiple copies of an enemy, so a couple of good global variables can be thrown into the batch.
Collision detection should only be taken into effect if you're using a custom pixel-movement system as opposed to the default tile-movement system.
It may be a good idea to check out *Worthy's* tutorials:
http://castleparadox.com/search-usersgames.php?u=292
They are awesome.
Last edited by TwinHamster on Mon Oct 13, 2008 6:21 am; edited 1 time in total |
|
| Back to top |
|
|
Rya.Reisender
Snippy
Joined: 18 Jan 2008
Posts: 821
|
| Posted: Mon Oct 13, 2008 6:05 am Post subject: |
|
|
Writing a graphics engine yourself is a pain. Either use OHRRPGCE, some other RPG Maker or at least a good graphics engine + pure programming.
_________________
Snippy:
"curt or sharp, esp. in a condescending way" (Oxford American Dictionary)
"fault-finding, snappish, sharp" (Concise Oxford Dictionary, UK)
1. short-tempered, snappish, 2. unduly brief or curt (Merriam-Webster Dictionary) |
|
| Back to top |
|
|
Moogle1
Scourge of the Seas
Halloween 2006 Creativity Winner
Joined: 15 Jul 2004
Posts: 3377
Location: Seattle, WA
|
|
| Back to top |
|
|
Kizul Emeraldfire
Type: Cyber Dragoon
Joined: 26 Mar 2004
Posts: 229
|
| Posted: Mon Oct 13, 2008 8:49 am Post subject: |
|
|
| NeoSpade wrote: | umm, not sure if this is handy, but try looking up the 2006 collab game, chapter 1 has a kinda cool system, that (I belive) TwinHamster used the other hero stats for the enemy stats, you should really direct this question at him. Also you might wanna look here: http://moogle1.castleparadox.com/zelda.php by using all this info you should have no trouble at all, I was actually thinking about doing a game that used this, but I haven't came 'round to it yet, maybe next year eh?
EDIT: Kinda cool system isn't the word actually, I fell in love with it...TwinHamster is using it on bubble breaker aswell so I belive. |
| TwinHamster wrote: | Someone doing research into my work? This is awesome.
The game would be easist to make in whichever system you are most familiar with.
If you know enough C to pull it off, then go for it.
Otherwise, it is possible to pull off such a project with the OHRRPGCE.
Moogle1's Metamorphosis also used a SOM-esque system and is kind of neat.
He was also nice enough to include the script that he used!
As for your other questions:
Hit detection: In Chapter 1 of the Collab Game, I just checked the tile position that my hero was directly facing, put a sword animation there, checked to see if the sword was on top of an enemy, and pulled off the enemy hurting script if it was.
This pretty much only works on a tile-system, and it was pretty buggy.
Foe Stats: I think that in the same Chapter 1, I made every enemy have one hit point, so that they all died in one hit (For my convenience).
However, for the boss of the game, I gave him a custom set of stats because he was a unique copy of that enemy.
In Bubble Breaker, all battles are fought in duels, so I can conveniently put all of an enemy's stats inside of a dump hero, as Neospade mentioned.
This technique would probably not work very well with multiple copies of an enemy, so a couple of good global variables can be thrown into the batch.
Collision detection should only be taken into effect if you're using a custom pixel-movement system as opposed to the default tile-movement system.
It may be a good idea to check out *Worthy's* tutorials:
http://castleparadox.com/search-usersgames.php?u=292
They are awesome. |
O.H.R. it is, because I haven't the foggiest inkling of anything other than PlotScripting! (which is probably bad, in this day and age, but alas — what can I do?)
Yep — I checked out Chapter 1; it's pretty cool, though the attack-style is a bit different from what I'm wanting to make. Yours was tile-based, and only hit on the tile in front of the hero. What I'm wanting to do is make two types (for swords, among other weaponry I plan to include): one for a 'stab' attack (similar to Zelda 1, but more like the NES Willow), and a 'slash' attack (like the GameBoy Zelda games, or Willow's 'B button' attack).
I think I checked out Metamorphasis; I don't really remember much of how it played, but I do remember that it looked quite cool, though my hero was twice as tall as everyone else. o.O Which was a little weird, but hard to help with the OHR… ^^'
Yes, I noticed the bugginess a little — it wasn't too bad, though. By the way (off-topic), I like your NPCs — they say weird stuff. It's fun. 
Well, I was sorta wanting the enemies to have multiple hit points. >.> And, for some reason, when I played Chapter 1 — it seemed your enemies had multiple hit points as well. It was annoying having to hit 'Enter' to get rid of the text box that came up telling me that <enemy> had taken <damage>, and had <health> left. Would've been less annoying if it'd used strings instead, I think. xD
*ahrm* I was thinking of using actual enemy data for checking how many hit points (and other points) an enemy had, using this method:
- Create monsters.
- Subtract appropriate stats from whatever monster's getting attacked
If enough points are gone from a stat (excluding HP), then the monster is hindered by whatever stat is at 0. If HP is at (or less than) 0, then it's dead.
- Check to see whether or not monster is alive. If yes, go to the beginning of the loop. If not, then delete the monster's NPC copy and reset the monster stats it was using.
This would work, yes?
For the hit detection, I was thinking of using Weapon NPC-over-Enemy NPC or Weapon NPC-over-Hero Walkabout Sprite detection, as my game will be using pixel-based movement.
| Moogle1 wrote: | http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php/Zelda-style_games
Metamorphosis was created shortly before the advent of pixel-based movement, so the code is needlessly messy. But it's worth checking out at least, if only to see a sample of what's been done. Ditto for Smokey McGoo. |
I also played Smokey McGoo! It was fun, but alas, like your Metamorphosis, I cannot remember much of how it played. o.o' I shall look at it again, though.
For my game, I was also thinking of implementing a sort of 'layered plot-sprites' thing — not sure exactly what to call it — but basically, I was going to have the hero be a plot-sprite layered on top of the Hero Walkabout Sprite (which would be invisible), and the different equipment (Weapons, Shields, Additional Armor (things like rings, capes, chestplates, etc.), and Boots) linked to different other plot-sprites and layered into different 'slots', like so (from the 'top' layer to the 'bottom' layer):
- Weapon
- Additional Armor
- Boots
- Hero Sprite
- shadow sprite
- Hero Walkabout Sprite
Of course, when the hero attacks, the weapon plot-sprite would become an NPC instead…
The Shield that the hero has equipped will also be shown, but I think I'll be making that an NPC so that it can deflect/negate/lessen hit/spell damage from enemies and stuff.
Oh, uh — sssssorta related to this thread of discussion, is it possible to use variables in place of tags? Or no? <.<
I ask because there are (currently) only 998 tags, and I think I'd be hard-pressed to finish making this game with just that many. :/ It MIGHT be possible, though, which is why I think I'll just use 'variable tags' as a last resort. Though I did look at the PlotScripting Dictionary, and there seems to be no command to check the value of a variable…
Also, what are 'one-time use' tags, and how do I use them? >.> I asked both of these on the O.H.R. FAQ page, but there's not been an answer yet, so I thought I'd ask here, too.
</reallylongpost> |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Mon Oct 13, 2008 9:19 am Post subject: |
|
|
If you want to make a Non-RPG, and the limitations and difficulties of programming in plotscripting get to be too much for you, I always recommend Python+Pygame. http://python.org http://pygame.org
If you decide to try pygame, feel free to ask me questions about pygame, python, or object-oriented-programming. I would enjoy answering such questions.
| Kizul Emeraldfire wrote: | Also, what are 'one-time use' tags, and how do I use them? >.> I asked both of these on the O.H.R. FAQ page, but there's not been an answer yet, so I thought I'd ask here, too.
</reallylongpost> |
Check the wiki, I added an answer -- but the short version is that you definitely don't want to be using them in plotscripts. |
|
| Back to top |
|
|
Camdog
Joined: 08 Aug 2003
Posts: 606
|
| Posted: Mon Oct 13, 2008 10:08 am Post subject: |
|
|
If you're going to do custom collision detection with pixel-based movement, I recommend using bounding-boxes to detect collision, as this is a relatively simple algorithm. It's what I'm using for a side-scroller I'm putting together.
| Code: | #check for any npc collision, and run a script if applicable.
#also handle text box display related to npcs
plotscript, check npcs, who, begin
variable(npcId, numRefs, curRef, i, collision)
curTextBox := false
#loop through all possible NPC ids
for(npcId, 0, 35, 1) do(
numRefs := npc copy count(npcId)
for(i, 0, numRefs -- 1, 1) do(
curRef := NPC reference(npcId, i)
collision := false
#collision detection
if ((npc pixel x(curRef) >= hero pixel x(who)) &&
(npc pixel x(curRef) <= (hero pixel x(who) + 20)) &&
(npc pixel y(curRef) >= hero pixel y(who)) &&
(npc pixel y(curRef) <= (hero pixel y(who) +20))) then(collision := true)
if (((npc pixel x(curRef) + 20) >= hero pixel x(who)) &&
((npc pixel x(curRef) + 20) <= (hero pixel x(who) + 20)) &&
(npc pixel y(curRef) >= hero pixel y(who)) &&
(npc pixel y(curRef) <= (hero pixel y(who) +20))) then(collision := true)
if (((npc pixel x(curRef) + 20) >= hero pixel x(who)) &&
((npc pixel x(curRef) + 20) <= (hero pixel x(who) + 20)) &&
((npc pixel y(curRef) + 20) >= hero pixel y(who)) &&
((npc pixel y(curRef) + 20) <= (hero pixel y(who) +20))) then(collision := true)
if ((npc pixel x(curRef) >= hero pixel x(who)) &&
(npc pixel x(curRef) <= (hero pixel x(who) + 20)) &&
((npc pixel y(curRef) + 20) >= hero pixel y(who)) &&
((npc pixel y(curRef) + 20) <= (hero pixel y(who) +20))) then(collision := true)
if (collision) then(
if (read npc(curRef, NPCstat:script) >> 0) then(
run script by id(read npc(curRef, NPCstat:script), read npc(curRef, NPCstat:script argument))
)
)
)
)
if (curTextBox == false) then(advance text box)
end |
Basically, every element in your game has four points that make up a box (upper left-hand corner, upper right, lower left, and lower right). If any of those points are inside the 4 points of another element, there is a collision. The code above runs through every npc on the map and checks it for a collision with the hero sprite whose id == who. If there is a collision, it runs the NPC's on use script.
(You can ignore the text box stuff, suffice to say curTextBox is a global variable that can be manipulated by some of the NPC's on use scripts defined in my game.)
The neat thing about this method is that it isn't restricted to NPC and hero walkabout collisions. In fact, you can detect collisions based on bounding boxes defined as any 4 arbitrary points. Try:
| Code: | plotscript, check npcs, x1, y1, x2, y2, begin
#etc.
end |
Instead to check npc collisions based on any bounding box you define. (just make sure you check the smaller box against the bigger one, otherwise the smaller box could be completely inside the bigger and you wouldn't register a collision)
As far as wall collisions go, check out Jame's excellent Baby Bob sidescrolling script for a good example of that. It is in fact the skeleton upon which I'm basing the game the above code is from.
In terms of dealing with complicated data structures, I like to treat the global variable array as simple memory locations, and then use other variables as pointers. In this way, you can simulate classes using Hamsterspeak! Here's an example from a mini-game I'm working on:
| Code: | #class Room
define constant(7, ROOM_SIZE)
define constant(0, ROOM_ID)
define constant(1, ROOM_EXIT_1)
define constant(2, ROOM_EXIT_2)
define constant(3, ROOM_EXIT_3)
define constant(4, ROOM_HAS_PIT)
define constant(5, ROOM_HAS_BATS)
define constant(6, ROOM_HAS_WUMPUS)
define constant(100, ROOM_ARRAY_START)
define constant(240, ROOM_ARRAY_END)
plotscript, new Room, id, exit1, exit2, exit3, pit = false, bats = false, wumpus = false, begin
write global(ptr + ROOM_ID, id)
write global(ptr + ROOM_EXIT_1, exit1)
write global(ptr + ROOM_EXIT_2, exit2)
write global(ptr + ROOM_EXIT_3, exit3)
write global(ptr + ROOM_HAS_PIT, pit)
write global(ptr + ROOM_HAS_BATS, bats)
write global(ptr + ROOM_HAS_WUMPUS, wumpus)
ptr := ptr + ROOM_SIZE
end
plotscript, get Room(id), begin
variable(i, ret)
ret := false
for(i, ROOM_ARRAY_START, ROOM_ARRAY_END - ROOM_ARRAY_SIZE, ROOM_ARRAY_SIZE) do(
if (read global(i + ROOM_ID) == id) then(ret := i)
)
return (ret)
end
plotscript, Room_getExit1, id, begin
variable(curRoom)
curRoom := get Room(id)
return (read global(curRoom + ROOM_EXIT_1))
end
plotscript, Room_getExit2, id, begin
variable(curRoom)
curRoom := get Room(id)
return (read global(curRoom + ROOM_EXIT_2))
end
plotscript, Room_getExit3, id, begin
variable(curRoom)
curRoom := get Room(id)
return (read global(curRoom + ROOM_EXIT_3))
end
plotscript, Room_hasPit, id, begin
variable(curRoom)
curRoom := get Room(id)
return (read global(curRoom + ROOM_HAS_PIT))
end
plotscript, Room_hasBats, id, begin
variable(curRoom)
curRoom := get Room(id)
return (read global(curRoom + ROOM_HAS_BATS))
end
plotscript, Room_hasWumpus, id, begin
variable(curRoom)
curRoom := get Room(id)
return (read global(curRoom + ROOM_HAS_WUMPUS))
end
plotscript, Room_setHasPit, id, flag, begin
variable(curRoom)
curRoom := get Room(id)
write global(curRoom + ROOM_HAS_PIT, flag)
end
plotscript, Room_setHasBats, id, flag, begin
variable(curRoom)
curRoom := get Room(id)
write global(curRoom + ROOM_HAS_BATS, flag)
end
plotscript, Room_setHasWumpus, id, flag, begin
variable(curRoom)
curRoom := get Room(id)
write global(curRoom + ROOM_HAS_WUMPUS, flag)
end
#end class |
As you can see, I have set aside a section of "memory" (global variables 100 through 240) and a series of helper functions that help me easily access this data in a way that makes sense for my data structure. With this code, I can do neat things like this:
| Code: | plotscript, initialize, begin
ptr := 100
#set up room definitions
new Room(1, 5, 2, 8)
new Room(2, 1, 10, 3)
new Room(3, 4, 2, 12)
new Room(4, 3, 14, 5)
new Room(5, 4, 1, 6)
new Room(6, 5, 15, 7)
new Room(7, 6, 17, 8)
new Room(8, 7, 1, 9)
new Room(9, 8, 18, 10)
new Room(10, 9, 11, 2)
new Room(11, 10, 19, 12)
new Room(12, 13, 3, 11)
new Room(13, 14, 20, 12)
new Room(14, 15, 4, 13)
new Room(15, 14, 16, 6)
new Room(16, 15, 20, 17)
new Room(17, 16, 7, 18)
new Room(18, 17, 9, 19)
new Room(19, 20, 11, 18)
new Room(20, 16, 13, 19)
#hazards and wumpus
Room_setHasBats(random(1, 20), true)
Room_setHasPit(random(1, 20), true)
Room_setHasWumpus(random(1, 20), true)
end |
Then, I can check stuff easily based on player location:
| Code: | | if (Room_hasWumpus(playerLocation)) then(#do wumpus stuff) |
Developing an easily extensible way of handling complex data structures is important in projects like the one you're describing, as Hamsterspeak only supports integers and strings, and it will become difficult to squeeze all sorts of custom data like hp, mp, attack type, etc. into your heroes and monsters without it.
Sorry if this is a huge amount of information, but your question relates very nicely to some of the stuff I've been working on lately, and I thought I'd share some of the code. If none of this makes sense to you, I'd suggest reading some programming tutorials and even considering doing your project in some pure-programming environment. The OHR is great for simplifying some tasks, but it does require some trickery to do stuff that is far from it's original design. |
|
| Back to top |
|
|
Moogle1
Scourge of the Seas
Halloween 2006 Creativity Winner
Joined: 15 Jul 2004
Posts: 3377
Location: Seattle, WA
|
| Posted: Mon Oct 13, 2008 10:23 am Post subject: |
|
|
| James Paige wrote: | If you want to make a Non-RPG, and the limitations and difficulties of programming in plotscripting get to be too much for you, I always recommend Python+Pygame. http://python.org http://pygame.org
If you decide to try pygame, feel free to ask me questions about pygame, python, or object-oriented-programming. I would enjoy answering such questions. |
Hmm!
Not to derail this thread, but is there a simple program whose source is available that I could look at? I'd look into it myself, but I'm at work. I find I have a much higher tolerance and learning rate with real code than long, dry tutorials.
Also: HUNT THE WUMPUS
Back on topic: You should really replay Metamorphosis.
_________________
|
|
| Back to top |
|
|
Kizul Emeraldfire
Type: Cyber Dragoon
Joined: 26 Mar 2004
Posts: 229
|
| Posted: Mon Oct 13, 2008 10:33 am Post subject: Augh, I botched the quoting in this post. XP Fixed now. |
|
|
| James Paige wrote: | If you want to make a Non-RPG, and the limitations and difficulties of programming in plotscripting get to be too much for you, I always recommend Python+Pygame. http://python.org http://pygame.org
If you decide to try pygame, feel free to ask me questions about pygame, python, or object-oriented-programming. I would enjoy answering such questions. |
Aye, I have Pygame's things and resources bookmarked. If ever I make anything with them, I believe you shall be the first person (after their mailing list) that I shall contact with questions.
| James Paige wrote: | | Kizul Emeraldfire wrote: | Also, what are 'one-time use' tags, and how do I use them? >.> I asked both of these on the O.H.R. FAQ page, but there's not been an answer yet, so I thought I'd ask here, too.
</reallylongpost> |
Check the wiki, I added an answer -- but the short version is that you definitely don't want to be using them in plotscripts. |
Ahh, I see now — however, if I were to avoid using one-time use tags* completely, would it be possible to just use the one-time use tags like regular tags via the Set/Check Tag commands?
Would that work?
*For example, instead of using a one-time use tag on an NPC for a treasure chest, what if I just had the NPC trigger a script when talked to? One that, specifically, would:
- Check the direction of the NPC (set not to change direction or move, ever) being talked to — if South, kick up an "Open chest? [Y/N]" text box.
- After opening the chest, change the NPC's direction from South to either of North, East or West (and make it invisible, because I wouldn't bother drawing graphics for the other views), and then give the hero the item, showing a "Got <Item>!" textbox.
- If the NPC is facing any direction but South, then simply give a text box saying "Chest empty."
Last edited by Kizul Emeraldfire on Mon Oct 13, 2008 2:43 pm; edited 1 time in total |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Mon Oct 13, 2008 12:49 pm Post subject: |
|
|
| Moogle1 wrote: | | Not to derail this thread, but is there a simple program whose source is available that I could look at? I'd look into it myself, but I'm at work. I find I have a much higher tolerance and learning rate with real code than long, dry tutorials. |
Hmm. You might want to check out the source code for Stringrolled, which was the winner of the Pyweek 7 competition in the "Individual" category.
http://media.pyweek.org/dl/7/Rambo/Stringrolled_4.zip
it is certainly more complicated than what you would find in a beginner tutorial, but the code is pretty clean and well organized.
| Kizul Emeraldfire wrote: | | If ever I make anything with them, I believe you shall be the first person (after their mailing list) that I shall contact with questions. :) |
I'm a regular reader of the pygame mailing list, so that will save a step :)
| Kizul Emeraldfire wrote: | Ahh, I see now — however, if I were to avoid using one-time use tags* completely, would it be possible to just use the one-time use tags like regular tags via the Set/Check Tag commands? :)
Would that work? :D |
Yes, it would work, but depending on how 'Plan for increasing available tags' works out, your scripts might break in a future update. (Hopefully not, I just say that because I am not sure)
| Kizul Emeraldfire wrote: | *For example, instead of using a one-time use tag on an NPC for a treasure chest, what if I just had the NPC trigger a script when talked to? One that, specifically, would:
- Check the direction of the NPC (set not to change direction or move, ever) being talked to — if South, kick up an "Open chest? [Y/N]" text box.
- After opening the chest, change the NPC's direction from South to either of North, East or West (and make it invisible, because I wouldn't bother drawing graphics for the other views), and then give the hero the item, showing a "Got <Item>!" textbox.
- If the NPC is facing any direction but South, then simply give a text box saying "Chest empty." :)
|
That would work fine, but what about when you re-load the map? The NPC directions would all get set back to how they started. You could use the feature to save NPC state, but that doesn't get saved in the SAV file. |
|
| Back to top |
|
|
Kizul Emeraldfire
Type: Cyber Dragoon
Joined: 26 Mar 2004
Posts: 229
|
| Posted: Mon Oct 13, 2008 2:42 pm Post subject: |
|
|
| Camdog wrote: | If you're going to do custom collision detection with pixel-based movement, I recommend using bounding-boxes to detect collision, as this is a relatively simple algorithm. It's what I'm using for a side-scroller I'm putting together.
| Code: | | Edited to make short. |
Basically, every element in your game has four points that make up a box (upper left-hand corner, upper right, lower left, and lower right). If any of those points are inside the 4 points of another element, there is a collision. The code above runs through every npc on the map and checks it for a collision with the hero sprite whose id == who. If there is a collision, it runs the NPC's on use script.
(You can ignore the text box stuff, suffice to say curTextBox is a global variable that can be manipulated by some of the NPC's on use scripts defined in my game.)
The neat thing about this method is that it isn't restricted to NPC and hero walkabout collisions. In fact, you can detect collisions based on bounding boxes defined as any 4 arbitrary points. Try:
| Code: | plotscript, check npcs, x1, y1, x2, y2, begin
#etc.
end |
Instead to check npc collisions based on any bounding box you define. (just make sure you check the smaller box against the bigger one, otherwise the smaller box could be completely inside the bigger and you wouldn't register a collision)
As far as wall collisions go, check out Jame's excellent Baby Bob sidescrolling script for a good example of that. It is in fact the skeleton upon which I'm basing the game the above code is from.
In terms of dealing with complicated data structures, I like to treat the global variable array as simple memory locations, and then use other variables as pointers. In this way, you can simulate classes using Hamsterspeak! Here's an example from a mini-game I'm working on:
| Code: | | Edited to make short. |
As you can see, I have set aside a section of "memory" (global variables 100 through 240) and a series of helper functions that help me easily access this data in a way that makes sense for my data structure. With this code, I can do neat things like this:
| Code: | | Edited to make short. |
Then, I can check stuff easily based on player location:
| Code: | | if (Room_hasWumpus(playerLocation)) then(#do wumpus stuff) |
Developing an easily extensible way of handling complex data structures is important in projects like the one you're describing, as Hamsterspeak only supports integers and strings, and it will become difficult to squeeze all sorts of custom data like hp, mp, attack type, etc. into your heroes and monsters without it.
Sorry if this is a huge amount of information, but your question relates very nicely to some of the stuff I've been working on lately, and I thought I'd share some of the code. If none of this makes sense to you, I'd suggest reading some programming tutorials and even considering doing your project in some pure-programming environment. The OHR is great for simplifying some tasks, but it does require some trickery to do stuff that is far from it's original design. |
Hrm — this shall be of much help! Thank you! Of course, I'm currently still in 'pre-production', so to speak — the story's not even completely formulated yet, so I'm not quite up to where I need scripting JUST yet — I have to do all the graphics first, but that requires the story, and I also need to figure out what to do for dungeon-levels and things like that.
Fortunately, I have someone making maps of some (probably going to be most) areas for me, so you won't be cursed to peruse a world containing towns that are perfectly symmetrical.
Thanks for posting the code, though — do you mind if I use it in my game? I'm planning on selling mine (once it's (eventually) made — I'm hoping that this game will be awesome enough to make some money, at least), but I'm going to be listing in the credits of my game the names (at least the screen-names) of everyone who's helped me out — it wouldn't be right not to.
P.S.: I would've posted this several hours ago, but I had to call India to find out why my internet was down. ¯\(º_O)/¯ Oddly enough, I forgot to ask the tech support guy what exactly the problem was… |
|
| Back to top |
|
|
Camdog
Joined: 08 Aug 2003
Posts: 606
|
| Posted: Mon Oct 13, 2008 5:32 pm Post subject: |
|
|
| Kizul Emeraldfire wrote: | | do you mind if I use it in my game? |
Not at all. |
|
| Back to top |
|
|
Kizul Emeraldfire
Type: Cyber Dragoon
Joined: 26 Mar 2004
Posts: 229
|
| Posted: Mon Oct 13, 2008 6:20 pm Post subject: |
|
|
| James Paige wrote: | | Kizul Emeraldfire wrote: | | If ever I make anything with them, I believe you shall be the first person (after their mailing list) that I shall contact with questions. |
I'm a regular reader of the pygame mailing list, so that will save a step |
Indeed!
| James Paige wrote: | | Kizul Emeraldfire wrote: | Ahh, I see now — however, if I were to avoid using one-time use tags* completely, would it be possible to just use the one-time use tags like regular tags via the Set/Check Tag commands?
Would that work? |
Yes, it would work, but depending on how 'Plan for increasing available tags' works out, your scripts might break in a future update. (Hopefully not, I just say that because I am not sure) |
True, but if that happens, I can just ask you for directions on rolling back revisions with Subversion and just develop it with the revision JUST BEFORE the one that breaks my scripts. 
…until the O.H.R. gets a feature I've been dying to have, then I'll be un-lazy and edit the scripts so that they're not broken. :p
| James Paige wrote: | | Kizul Emeraldfire wrote: | *For example, instead of using a one-time use tag on an NPC for a treasure chest, what if I just had the NPC trigger a script when talked to? One that, specifically, would:
- Check the direction of the NPC (set not to change direction or move, ever) being talked to — if South, kick up an "Open chest? [Y/N]" text box.
- After opening the chest, change the NPC's direction from South to either of North, East or West (and make it invisible, because I wouldn't bother drawing graphics for the other views), and then give the hero the item, showing a "Got <Item>!" textbox.
- If the NPC is facing any direction but South, then simply give a text box saying "Chest empty."
|
That would work fine, but what about when you re-load the map? The NPC directions would all get set back to how they started. You could use the feature to save NPC state, but that doesn't get saved in the SAV file. |
…hrm, you're right — I hadn't thought of that, actually. :/ In that case, I dunno, lol ¯\(º_O)/¯ I'll think of something, though — I can be rather ingenuous.
| Camdog wrote: | | Not at all. |
Cool! Thanks! ^^ |
|
| Back to top |
|
|
Camdog
Joined: 08 Aug 2003
Posts: 606
|
| Posted: Tue Oct 14, 2008 7:36 am Post subject: |
|
|
Why exactly do you think you'll need so many tags? 999 is quite a lot in my estimation, especially if you use the one-time-use tags for things like treasure chests.
For the record, you can use variables instead of tags. They'll have to be global variables, though, as local variables won't be saved. Checking them is as simple as writing their name; you don't need a special plotscript to do it. For example, if you have a global variable called 'foundTheMaguffin", you can update it like so:
| Code: | | foundTheMaguffin := true |
and check it like so:
| Code: | if (foundTheMaguffin) then (#do something appropriate)
else (#do something else) |
The only problem with this is that custom has all sorts of built in ways of interacting with tags, whereas you'd need to use plotscripts to do any kind of checking or assigning with global variables. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
