Cloud Castle 2 : It still exists!
This d-mod has taken far too long, but I feel it is now starting to really come together. Arik has made some amazing bosses, and the d-mod is unrecognizable compared to the rather awful BETA I released a while back.
Whilst the d-mod has a strong storyline (although the details of this are never clearly known by either me nor Arik!) it does not have an especially large amount of map to wander about in, getting lost.
In fact, Arik pointed out to me recently that the majority of the map screens used were for dungeons... and there are some mean dungeons is this d-mod (You have Arik to blame for that)!
Though progess on it has always been jumpy, it is at a lull presently until my exams are finished. Then comes the summer where this d-mod MUST be finished. I'm confident it will be, as most of the game is intact now, with just a few plotpieces, a few sidequests, and a helluvalotta beta-testing needed!!
Just so people know where this d-mod is (approximately) at...
**Features**
- CC2 "Party" System.
- MIDI's from all sources. 16bit to 32bit consoles, films, to original compositions.
- A few "Arcadey" sections.
- New Items (FeatherFeet potion, Nightmare Sword, Homing Crystal etc)
- New Enemies (Bane Bonca, Scarab, Fusion Slimes etc) (Some enemies are mild variants of the original games monsters)
- New Magic (Fissure, Multi-Hellfire, Rupture)
- Multiple Endings.
**Credits**
Story + Scripting: SabreTrout, Arik (Paul Pliska)
Graphics: Bruce Harrison, Striker, Simonk, Bin, SabreTrout
Map Design: SabreTrout, Arik
**Progress**
Graphics: 80%
Sound: 85%
Story: 87%
Scripting: 68%
Map: 82%
Total: 80%
Planned release: Q3 2004
If you have any questions.queries etc, please don't hesitate to ask, either by posting here or e-mailing me at JamestheTrout@aol.com.
Whilst the d-mod has a strong storyline (although the details of this are never clearly known by either me nor Arik!) it does not have an especially large amount of map to wander about in, getting lost.
In fact, Arik pointed out to me recently that the majority of the map screens used were for dungeons... and there are some mean dungeons is this d-mod (You have Arik to blame for that)!

Though progess on it has always been jumpy, it is at a lull presently until my exams are finished. Then comes the summer where this d-mod MUST be finished. I'm confident it will be, as most of the game is intact now, with just a few plotpieces, a few sidequests, and a helluvalotta beta-testing needed!!
Just so people know where this d-mod is (approximately) at...
**Features**
- CC2 "Party" System.
- MIDI's from all sources. 16bit to 32bit consoles, films, to original compositions.
- A few "Arcadey" sections.
- New Items (FeatherFeet potion, Nightmare Sword, Homing Crystal etc)
- New Enemies (Bane Bonca, Scarab, Fusion Slimes etc) (Some enemies are mild variants of the original games monsters)
- New Magic (Fissure, Multi-Hellfire, Rupture)
- Multiple Endings.
**Credits**
Story + Scripting: SabreTrout, Arik (Paul Pliska)
Graphics: Bruce Harrison, Striker, Simonk, Bin, SabreTrout
Map Design: SabreTrout, Arik
**Progress**
Graphics: 80%
Sound: 85%
Story: 87%
Scripting: 68%
Map: 82%
Total: 80%
Planned release: Q3 2004
If you have any questions.queries etc, please don't hesitate to ask, either by posting here or e-mailing me at JamestheTrout@aol.com.
I liked the demo of cloud castle 2,but if this is better i will like this a bit more

Indeed, I may send out a version for some testing/feedback soon, though I'll have to confer with Arik first. Of course Tal, you are #1 on our Beta-tester list (this time maybe I'll wait until you've finished before I upload the d-mod!).
Though I should mention that there are a few graphics that are still "needed" for the d-mod. I asked Bruce about some of them a while ago, but haven't heard from him since. Anywho, if anybody is interested in making some Dragonesque decorations for the d-mod (such as new fireplaces, some wall hangings etc), I would be VERY happy!

Though I should mention that there are a few graphics that are still "needed" for the d-mod. I asked Bruce about some of them a while ago, but haven't heard from him since. Anywho, if anybody is interested in making some Dragonesque decorations for the d-mod (such as new fireplaces, some wall hangings etc), I would be VERY happy!

I'm actually mildly excited by this. It's probably the longwinded description that got my hopes up for another good d-mod to come out.
Better not disappoint me Sabre!
Better not disappoint me Sabre!
I'll try not to! What with Redinks "Hype" post, I felt It had been too long since I had talked about the d-mod in depth (For example, we currently have 362 scripts).
Though I have to tell you, this d-mod is going to be hard! "Cloud Castle" itself wasn't a stroll in the park, but this... well I can't kill Arik's Uber-Fiendish Ancient, and I don't think I ever will!
But will you all be disappointed if there are no burnable cacti?
Though I have to tell you, this d-mod is going to be hard! "Cloud Castle" itself wasn't a stroll in the park, but this... well I can't kill Arik's Uber-Fiendish Ancient, and I don't think I ever will!

But will you all be disappointed if there are no burnable cacti?
Well, while it will mean going through EVERY single map screen and changing millions of cacti... burnable things are worthwhile.
Any other requests?

Any other requests?
Now that's a very optimistic appraisal of the game. Especially those percentage figures - I'd LOVE to see the formula you used to come up with those
I don't think that it has changed all THAT much since the Beta - there are more/more working NPCs, it's further into the plot, there are new items etc, but if you played the early version don't expect a FIAT 0.99 to FIAT 1.00 leap.
I'm quietly optimistic about the game too, though. I'm certainly optimistic about meeting my own personal target of making it the Friends Beyond 2 to Cloud Castle's FB1 - larger, more ambitious, not necessarily better in every respect and not necessarily completely successful in everything it sets out to do, but a definite step forward. Even if we've only done an hours work on it every couple of months
Just a note to those who played the original. My intention with the difficulty level in Cloud Castle was to provide a challenge to experienced players - my reasoning being that people who are still playing Dink Smallwood are probably pretty hardcore. This was a probably a little elitist, though. My intention when balancing this, so far, has been to make the game generally easier, so it won't be too hard unless you've missed a lot of potions. HOWEVER, if we didn't make some of it difficult then it wouldn't be a true sequel to Cloud Castle, so we've set aside a special dungeon (the Temple of the Ancients) which will be on ridiculous levels of difficulty.
If you think that that reasoning is dumb, then I'm open to feedback. Burnable cacti would certainly add to the game, too - all feedback is welcome.

I don't think that it has changed all THAT much since the Beta - there are more/more working NPCs, it's further into the plot, there are new items etc, but if you played the early version don't expect a FIAT 0.99 to FIAT 1.00 leap.
I'm quietly optimistic about the game too, though. I'm certainly optimistic about meeting my own personal target of making it the Friends Beyond 2 to Cloud Castle's FB1 - larger, more ambitious, not necessarily better in every respect and not necessarily completely successful in everything it sets out to do, but a definite step forward. Even if we've only done an hours work on it every couple of months

Just a note to those who played the original. My intention with the difficulty level in Cloud Castle was to provide a challenge to experienced players - my reasoning being that people who are still playing Dink Smallwood are probably pretty hardcore. This was a probably a little elitist, though. My intention when balancing this, so far, has been to make the game generally easier, so it won't be too hard unless you've missed a lot of potions. HOWEVER, if we didn't make some of it difficult then it wouldn't be a true sequel to Cloud Castle, so we've set aside a special dungeon (the Temple of the Ancients) which will be on ridiculous levels of difficulty.
If you think that that reasoning is dumb, then I'm open to feedback. Burnable cacti would certainly add to the game, too - all feedback is welcome.
Arik has a better way (apparently), dear Redink.
As for those percentages... they aren't THAT optimistic are they? Well... here are the originals and some altered ones...
Graphics: 80% -- 150% If Arik had his way about having NO new GFX at all!
Sound: 85% -- 75% at least.
Story: 87% -- I see story as the plot we have figured out... and the lowest that could possibly be is 85% I'm sure. Well... unless you throw all my ideas out again Arik. Bah!
Scripting: 68% -- Hmmm... depends how much more stuff we need. Surely the most we could possibly require would be another 100 (and thats including all the stuff I wanna put in to make it super replayable).
Map: 82% -- Maybe this could be cut down to 65 - 70%. Perhaps many, many, many more underground areas could be added?
Total: 80% -- Let's bring that down to 75%. It is AT LEAST that far done.
But yeah... Arik is right in the most part. It's not THAT different to the BETA, apart from the eradication of most of the terrible bugs, the addition of the party system (it was always there but... it's actually quite good now, not the shoddy thing we had before), the far superior scripting that Arik is slowly replacing mine with... the list goes on.

As for those percentages... they aren't THAT optimistic are they? Well... here are the originals and some altered ones...
Graphics: 80% -- 150% If Arik had his way about having NO new GFX at all!
Sound: 85% -- 75% at least.
Story: 87% -- I see story as the plot we have figured out... and the lowest that could possibly be is 85% I'm sure. Well... unless you throw all my ideas out again Arik. Bah!
Scripting: 68% -- Hmmm... depends how much more stuff we need. Surely the most we could possibly require would be another 100 (and thats including all the stuff I wanna put in to make it super replayable).
Map: 82% -- Maybe this could be cut down to 65 - 70%. Perhaps many, many, many more underground areas could be added?
Total: 80% -- Let's bring that down to 75%. It is AT LEAST that far done.
But yeah... Arik is right in the most part. It's not THAT different to the BETA, apart from the eradication of most of the terrible bugs, the addition of the party system (it was always there but... it's actually quite good now, not the shoddy thing we had before), the far superior scripting that Arik is slowly replacing mine with... the list goes on.

So you make a statement and come right back and contradict yourself? Nice.

Arik has a better way (apparently), dear Redink.
Eh, what could that be? I can't fathom anything that would be more efficient, sans CANCELLING THE D-MOD! BUAHAHA! I can read Arik like a book!
Eh, what could that be? I can't fathom anything that would be more efficient, sans CANCELLING THE D-MOD! BUAHAHA! I can read Arik like a book!
Can i beta test for you? Only this time i actually will! I promise.

Of course it's a better way, Sabre, it's the way that you're SUPPOSED to implement burnable plantlife! Assuming that I've got it right, of course.
And, of course, once I've CANCELLED THE D-MOD, we can redo everything from scratch, and then it really will be completely unrecognisable compared to the "beta". Mwahaha!
And, of course, once I've CANCELLED THE D-MOD, we can redo everything from scratch, and then it really will be completely unrecognisable compared to the "beta". Mwahaha!
Considering Scarab (if you include the original d-mod... the first I ever made) has already been re-started at least 4 times, I will cry if we start again now!
I just wanna get to work on CC3... I've had enough of deserts. Ugh.
(BTW, don't hold me to any release date I "announce" for CC2!!)
I just wanna get to work on CC3... I've had enough of deserts. Ugh.

(BTW, don't hold me to any release date I "announce" for CC2!!)
For example the projected release date of Cloud Castle 2 of EARLY 2003(as seen in cc1)?!
Er, you're not SUPPOSED to implement burnable plantlife that way. Don't take the way Seth did things as the one true way
Modifying the fireball script whenever you want to burn something else just seems... silly. What if you only want one log to be burnt? Then you'd put some &player_map checking in there, and maybe checking the sprite number too. And it just becomes on big jumbled mess when someone else goes to look at your D-Mod... what the heck, how does that log burn? It doesn't have a script?
The problem also lies in if you have different magic that can burn things, ala Fireball and Hellfire in the original. You basically have to duplicate the code (copy and paste), which isn't a very good idea because you'll make a bug fix in one version whilst forgetting the other. There were a couple bugs with Hellfire burning down trees with scripts attached in the original game due to this very reasoning.
The way I prefer to implement it is weird. Basically I'll give the sprite that is burnable a script that sets a sp_gold value unique to burnable objects, say, 80. As sp_gold isn't used by any of the original game objects, you can be fairly safe to assume that it will be ok to just claim a number for burning things. I then add a 'fire' function/method into the script, which will then activate whenever a fireball hits it.
How? In the fireball script(s) I have it check the sp_gold value of the sprite that it damages, and if it is 80 I do this:
int &junk = is_script_attached(&missile_target);
run_script_by_number(&junk, "fire");
Tada, it runs the 'fire' subroutine of the burnable sprite that the fireball hits.
The sp_gold nonsense is requred because if you use run_script_by_number and the subroutine you specify is undefined, then it will run an existing subroutine anyway.
But this method is actually kinda cool in that it supports weird things happening. You could easily have something like an enemy shooting some weird fire magic at Dink, and add in the sp_gold checking above, and then it could set all burnable objects on fire just like *that*.

Modifying the fireball script whenever you want to burn something else just seems... silly. What if you only want one log to be burnt? Then you'd put some &player_map checking in there, and maybe checking the sprite number too. And it just becomes on big jumbled mess when someone else goes to look at your D-Mod... what the heck, how does that log burn? It doesn't have a script?
The problem also lies in if you have different magic that can burn things, ala Fireball and Hellfire in the original. You basically have to duplicate the code (copy and paste), which isn't a very good idea because you'll make a bug fix in one version whilst forgetting the other. There were a couple bugs with Hellfire burning down trees with scripts attached in the original game due to this very reasoning.
The way I prefer to implement it is weird. Basically I'll give the sprite that is burnable a script that sets a sp_gold value unique to burnable objects, say, 80. As sp_gold isn't used by any of the original game objects, you can be fairly safe to assume that it will be ok to just claim a number for burning things. I then add a 'fire' function/method into the script, which will then activate whenever a fireball hits it.
How? In the fireball script(s) I have it check the sp_gold value of the sprite that it damages, and if it is 80 I do this:
int &junk = is_script_attached(&missile_target);
run_script_by_number(&junk, "fire");
Tada, it runs the 'fire' subroutine of the burnable sprite that the fireball hits.
The sp_gold nonsense is requred because if you use run_script_by_number and the subroutine you specify is undefined, then it will run an existing subroutine anyway.
But this method is actually kinda cool in that it supports weird things happening. You could easily have something like an enemy shooting some weird fire magic at Dink, and add in the sp_gold checking above, and then it could set all burnable objects on fire just like *that*.
Kool! Similarly, one could make a script for when ever an enemy is attacked by a fire ball or other similar attack, therefore they could react to different attacks in different ways, like shooting a fireball back.
>Er, you're not SUPPOSED to implement burnable
>plantlife that way. Don't take the way Seth
>did things as the one true way
Don't worry, I'm not assuming anything about the best way to implement things here. The reason I think that this is the most sensible way of going about it is because:
>What if you only want one log to be burnt?
Thankfully, this won't be an issue - and also, I'm not entirely sure that doing something like this is a good idea. If the player can destroy one log with fire, surely they'd expect to be able to destroy all of them? It would seem inconsistent.
>how does that log burn? It doesn't have a script?
Although this is a very good point - I spent an absolute age trying to figure out why the trees burnt. Still, if people try looking at my scripting for example, they're screwed whatever, so it's not something I'm inclined to fix
>There were a couple bugs with Hellfire burning
>down trees with scripts attached in the >original game due to this very reasoning.
Yeah, I think I read about this. Pretty much all I'm going to do to the existing code is copy, paste and change a few numbers, though, so I don't see this being a problem.
>The way I prefer to implement it is weird.
Actually, it's quite interesting, although it wouldn't make a lot of sense to implement it in Scarab, as it would involve attaching scripts to all the cacti, etc (easier with the sprite replacer, but still not exactly worthwhile when a copy/paste will do). It definitely has potential, though.
>plantlife that way. Don't take the way Seth
>did things as the one true way
Don't worry, I'm not assuming anything about the best way to implement things here. The reason I think that this is the most sensible way of going about it is because:
>What if you only want one log to be burnt?
Thankfully, this won't be an issue - and also, I'm not entirely sure that doing something like this is a good idea. If the player can destroy one log with fire, surely they'd expect to be able to destroy all of them? It would seem inconsistent.
>how does that log burn? It doesn't have a script?
Although this is a very good point - I spent an absolute age trying to figure out why the trees burnt. Still, if people try looking at my scripting for example, they're screwed whatever, so it's not something I'm inclined to fix

>There were a couple bugs with Hellfire burning
>down trees with scripts attached in the >original game due to this very reasoning.
Yeah, I think I read about this. Pretty much all I'm going to do to the existing code is copy, paste and change a few numbers, though, so I don't see this being a problem.
>The way I prefer to implement it is weird.
Actually, it's quite interesting, although it wouldn't make a lot of sense to implement it in Scarab, as it would involve attaching scripts to all the cacti, etc (easier with the sprite replacer, but still not exactly worthwhile when a copy/paste will do). It definitely has potential, though.
If the player can destroy one log with fire, surely they'd expect to be able to destroy all of them? It would seem inconsistent.
Yeah, I did notice that it would be inconsistent, but there are some valid inconsistencies. Say you want Dink to be able to light a log on fire that is below a pot to boil some water. The log would visibly be dry, and would most likely have to have a script in order to tell the pot sprite that it should be boiling. But what if you want to use logs in the river as well? You wouldn't want Dink to light those logs on fire.
The other valid inconsistency that I can think of is when you want to have a secret, i.e. burning some of the trees in the game reveals a secret passage. With the sp_gold technique you could easily set it to appear in the fire subroutine, whereas with Seth's technique the fireball checks to see if *any* script is attached and then decides to run the die procedure (maybe, or something like that). Not very elegant.
Yeah, I did notice that it would be inconsistent, but there are some valid inconsistencies. Say you want Dink to be able to light a log on fire that is below a pot to boil some water. The log would visibly be dry, and would most likely have to have a script in order to tell the pot sprite that it should be boiling. But what if you want to use logs in the river as well? You wouldn't want Dink to light those logs on fire.
The other valid inconsistency that I can think of is when you want to have a secret, i.e. burning some of the trees in the game reveals a secret passage. With the sp_gold technique you could easily set it to appear in the fire subroutine, whereas with Seth's technique the fireball checks to see if *any* script is attached and then decides to run the die procedure (maybe, or something like that). Not very elegant.