ID:194571
 
So we rolled out DragonSnot and announced the Deadron Development Team: Gazoot, Guy and myself will be co-developing some games, starting with DragonSnot. (Doh, DDT.com is not being used but is owned by some guy who took it out in college in 1994...well maybe he'll let us have it...)

For a roll-out it went about as good as is possible I guess: I only had to fix one major bug after we started, and got some suggestions for improving things (especially figuring out which dragon is which!)

I sure love that music.
For a roll-out it went about as good as is possible I guess: I only had to fix one major bug after we started, and got some suggestions for improving things (especially figuring out which dragon is which!)

It may have been more successful than you realize... we didn't leave off playing until about 12:30 Eastern time!


I sure love that music.

Yes... I'm quite impressed. It's very well done, it suits the game, and after another session or two I'll have it playing in my head for a week. Or maybe that's already started...
In response to Guy T.
It may have been more successful than you realize... we didn't leave off playing until about 12:30 Eastern time!

That pretty much summarizes it for me too. This is a great game.

Dagnabit. Once again, I had written a very lengthy response here and my stupid Linux Netscape crashed before I posted it. I'll give you the abridged version:

Good stuff:

* Very attractive interface, intutitive playability, nice artwork. How did you get the snot to flow so smoothly?

* Excellent music. Kudos to Gazoot. I'll have to contract him to do stuff for my own game when I finally write one in 2005 or so.

* Addictivity! Probably the most important thing in a puzzle game, and you did it well. I played until I won a game, which took about two hours.

(I wrote a lot more praise last time, but I'll stop here since you should get the point that I really enjoyed this game. I think some of these things you all have created in the last few months beat the pants off anything at Yahoo).

Suggestions:
(for this section dragon snot = "juice". It just reads better)

* You should be able to override any of your own trenches, regardless of how the juice is flowing, so long as they do not currently have juice in them. My game ended prematurely on a number of times because I or someone else had blocked my trench entirely. That's no fun. This was my only real problem with the game playability.

* Related: you probably shouldn't be able to place a piece directly connected to someone else's trench (or at least not when the juice is flowing toward it). It's just too open to malicicious attack. Or maybe if the above rule is introduced this won't be an issue.

* The selection-highlight box should be more noticeable. And perhaps you could add a little "click" or "clunk" when you select a piece (I think Z does this in Sheep, and it works nicely). Occassionally I would think I had selected a piece and realized too late that I hadn't.

* There's some sort of bug in the restarting-game code, but I think you already know about that. Sometimes we couldn't restart the game without logging back in. We didn't seem to get this problem in the last hour of play, so maybe you fixed it or something.

* I take back the notion that the exits should be evenly matched up. After playing for a while, it didn't seem like this was even much of a factor.

* This isn't so much an improvement, but a query (or perhaps a mode of play). What if you made it so that the juice flowed everywhere you had a trench? So if you had one of those four-way deals, it would go out the other three ways. Any juice hitting the ground would be "out of play" (so you couldn't stall it), but you would only lose when all the juice was out. Would this make it too easy? (it's never too easy for me .. I suck). The four-way trenches would be very powerful. You could also add in three-way trenches. Perhaps this is too much to ask for something that might be hard to implement. I think Spuzz had some thoughts on this too.

* Here's a long babble on something that might be out of your control. We experienced occassional client-side "freezes" (especially right when the game started) They wouldn't have been a big deal, except in a game of this sort a one second delay can kill you. After some diagnosis, we concluded the obvious: when Spuzzum played, we froze, and he won; when he didn't it ran as smooth as silk. Thinking that this might be scientific (and a bit curmudgeony), we decided that the problem actually only occurred when there were larger numbers of people playing. With two or three people, I never had a problem, but with four or more, I was getting the freezes. I am convinced that the problem is that the client is getting too much data that it knows how to handle in the split second required. It's not a server or network thing because the client literally freezes-up, not allowing access to the command prompt or menus for that tiny moment. I think this means that we have to buffer the data a bit better, but that will take some testing. I've seen this in other games too (most notably in L&D when Lwen takes over).

You could try experimenting with the tick_lag (making it a little bigger, perhaps based on the world.cpu?) An easier idea would be to go with a design solution, perhaps not moving the snot until the player had laid down a single tile (or some noticeable time had passed). Or you could just put this one to the wayside, since this only factored in a few games.

Out of curiosity, how is the trench placement working? Are you literally placing objects on the map? That would be the most efficient way of doing things, I believe. The alternative approach of using image() would probably be comparably slow, and not at all recommended, since image() is an inefficient mechanism not really suited for world broadcast.

Yikes. I guess this turned out to be unabridged after all. Well, I only babble about stuff I enjoy, so congrats to DDT for a job well done.
In response to Tom H.
On 10/20/00 1:43 am Tom H. wrote:
* Very attractive interface, intutitive playability, nice artwork. How did you get the snot to flow so smoothly?

All I did was use your suggestion of rapidly changing icon states, and took a guess that moving the flow two pixels per cycle was about right. As I mentioned online, all the non-dragon art and animation was done in the icon builder, which I'm happy about because it saved me a LOT of cut and pasting and reworking time. Congratulations on evolving to a nifty little icon tool -- the flipping and rotating commands and the ability to shift the image pixel by pixel (something that is actually harder to do in PSP) made that possible.

The thing I'm happiest about is the selection area. There is one set of selection objects shared by everyone (as required by the design of BYOND) -- but it feels like it is "your" part of the interface, because the selection objects show each player a different image and keep track of who is clicking on them. I think there is lots of potential in this idea for other games to use -- imagine a whole Heads Up Display (HUD) portion of the map for a military game!


* Addictivity! Probably the most important thing in a puzzle game, and you did it well. I played until I won a game, which took about two hours.

Best thing I've heard so far! And I think I can say you haven't seen anything yet -- between adding scoring, more kinds of trench at higher levels, and the major expansion we have planned, what is there is but a hint of what's to come...


Suggestions:
(for this section dragon snot = "juice". It just reads better)

In the code it's "flow" -- I couldn't stand typing it all the time either!


* You should be able to override any of your own trenches, regardless of how the juice is flowing, so long as they do not currently have juice in them. My game ended prematurely on a number of times because I or someone else had blocked my trench entirely. That's no fun. This was my only real problem with the game playability.

* Related: you probably shouldn't be able to place a piece directly connected to someone else's trench (or at least not when the juice is flowing toward it). It's just too open to malicicious attack. Or maybe if the above rule is introduced this won't be an issue.


Let me make sure of a couple of things....were you aware that you could replace a trench that blocked yours? The only things you can't replace are trenches that are part of a contiguous path back to a dragon. So unless someone runs their main path across yours, they can't completely block you. They can, as you mention, ADD to your path in an attempt to take you in a direction you don't want to go, and that does lead to an exploit where they can run you into a wall.

For the moment I want to stick with this approach and see how it works out. It will probably help when instructions are added to the game. A FTL BYOND feature that could assist here: the ability to have a selection rectangle that could follow the cursor. In this case, the rectangle would change color depending on whether you could place a trench at that location. To make a feature like this fast enough, it might have to be optimized/limited in some ways... Another possible approach would be control over the cursor image or color; in fact that might be a higher performance solution.

Oh, and last night I added a check for trenches placed next to the exit. Now it is not possible to block the exit -- any trench placed there must actually lead to the exit.


* The selection-highlight box should be more noticeable. And perhaps you could add a little "click" or "clunk" when you select a piece (I think Z does this in Sheep, and it works nicely). Occassionally I would think I had selected a piece and realized too late that I hadn't.

I'm not happy with the current selection rectangle anyway -- it was just thrown up for the GoB -- I'm hoping Guy T will have a better idea! I will add a click (I didn't yet because I have to think of a third click for this to record...) One challenge for BYOND on this point and elsewhere in the game: it takes a long time for things to display to users. The blinking dragons, the selection rectangle, the flow -- in all these cases I optimized as much as I could by trying to create the objects before I needed to display them, but often there seems to be a several tick delay between making an object or image visible and having it show the first time. Once it starts displaying, further icon state changes seem to be timed reasonably.


* There's some sort of bug in the restarting-game code, but I think you already know about that.

Yes and I left this un-fun bug-fixing trip for today.


* I take back the notion that the exits should be evenly matched up. After playing for a while, it didn't seem like this was even much of a factor.

Interesting -- well, I do think the proposal for everyone having an exit is interesting, so I'm hoping to get more comments on which way to go.


* This isn't so much an improvement, but a query (or perhaps a mode of play). What if you made it so that the juice flowed everywhere you had a trench? So if you had one of those four-way deals, it would go out the other three ways.

It would remove one of the cooler things, which is that you can use a cross trench twice -- one for each direction. (And I misspoke when asked if two flows could cross -- they can if they are using different directions of a cross pipe).

Once people start getting good at the game, they'll find this very useful. In Pipe Dream, in fact, you got a huge bonus if you managed to use both sections of five crosses, and that was quite a challenge. I should mention that about halfway through development of this game I checked out Pipe Dream again -- and was pleasantly surprised to find that I had misremembered enough features to have made a completely different game. Yes they are both about liquid flowing through shaped pipes, but the goal and feel are very different.

Maybe I should start the flow even slower though? It speeds up as you win, and the current starting seems pretty slow to me, but I have all those built up Pipe Dream reflexes.


* Here's a long babble on something that might be out of your control. We experienced occassional client-side "freezes" (especially right when the game started) They wouldn't have been a big deal, except in a game of this sort a one second delay can kill you. After some diagnosis, we concluded the obvious: when Spuzzum played, we froze, and he won; when he didn't it ran as smooth as silk. Thinking that this might be scientific (and a bit curmudgeony), we decided that the problem actually only occurred when there were larger numbers of people playing. With two or three people, I never had a problem, but with four or more, I was getting the freezes. I am convinced that the problem is that the client is getting too much data that it knows how to handle in the split second required...You could try experimenting with the tick_lag (making it a little bigger, perhaps based on the world.cpu?) An easier idea would be to go with a design solution, perhaps not moving the snot until the player had laid down a single tile (or some noticeable time had passed). Or you could just put this one to the wayside, since this only factored in a few games.

To be honest I mostly want to leave it this way as a good test case for BYOND! I think that all the simultaneous animation and the quick use of images in the game stress some nice areas of the system and I'm hoping that it will help drive improvements in those areas. However, before doing the major public release (which will have publicity and such to hopefully bring in a few dozen or more players) this stuff will obviously have to be fixed, whether in the system or in the game itself. The one change I think I'll play with now is offsetting the flows by a tick from each other. I don't know if this will make the game less visually appealing or even be noticable.


Out of curiosity, how is the trench placement working? Are you literally placing objects on the map? That would be the most efficient way of doing things, I believe.

They are objects which are created ahead of time and moved to that spot. And actually they are from 2 to 4 objects -- one is the trench, and the others are flow objects. I usually need multiple flow objects to handle all the possible flow directions, and I have to create all possible flow objects ahead of time to reduce the time it takes to start displaying a flow. This is pretty effective, since there is usually no noticable delay when the flow enters a new pipe. There is a delay for the final pipe, which didn't used to exist, and I don't know what's causing it.


Yikes. I guess this turned out to be unabridged after all. Well, I only babble about stuff I enjoy, so congrats to DDT for a job well done.

The DDT is excited about the game -- Gazoot has been doing about two songs a night, Guy is madly drawing up some new dragons (the existing dragons are pretty much perfect, but I stole them from a website and prefer to avoid possible permission hassles), and we're about to go into major planning mode for the remainder of the "Snot Simulator" level and then the expansion. (There will be cows -- yes, cows!)

By the way, this is now planned to be a revenue generating game. We have to work out the exact plan, but the basic idea is that the "Snot Simulator" level will be freely playable, and the expansion will either be donation-based or require a very small one-time payment to play. Obviously some of that planning will have to wait until we see how the BYONDimes system works -- one requirement it immediately brings up is that the game needs a way to know that a person paid, and how much they paid.

Well, off to the DDT labs!
In response to Deadron
On 10/20/00 8:05 am Deadron wrote:
On 10/20/00 1:43 am Tom H. wrote:

Let me make sure of a couple of things....were you aware that you could replace a trench that blocked yours? The only things you can't replace are trenches that are part of a contiguous path back to a dragon. So unless someone runs their main path across yours, they can't completely block you. They can, as you mention, ADD to your path in an attempt to take you in a direction you don't want to go, and that does lead to an exploit where they can run you into a wall.

I believe I understand how it works, and I understand the intention (allowing other people to affect your game), but in my opinion the game is difficult enough (especially in multiplayer) without having this restriction. It's just too easy to end your game on a depressing note because you accidentally placed one bad combination. Worse is when someone else does it for you. I don't have a problem with them being able to affect your game, but when they can screw it up completely with just a few motions it's a bit too much. And even the worst player can eliminate the best one just by discarding his trash into the opponent's pipeline, since it takes so much work to get a good flow in the right direction, but only a little work to mess it up entirely.

So I think that the rule should be that you be able to replace any of your own trenches as long as they don't have flow in them. That's also probably the expected behavior. But perhaps I'm the minority here. I was the most vocal about this "feature" yesterday. It may also just be my inexperience talking. You certainly have thought this through more than I, and I wouldn't want to induce labor (that doesn't sound right!) over something that may be a lousy idea.

[edited-- another thought]
Another idea would be to augment trenches when you place more than one. So if you placed a horizontal trench on top of a curvy one you would get a three way trench (this also fits in nicely with the idea that these are just digs in the ground). So if someone tries to redirect your trench you might be able to fix it by augmenting it with another in the current direction of flow.

Another possible approach would be control over the cursor image or color; in fact that might be a higher performance solution.

That's been suggested in the past, and I think it's a great idea. Custom cursors would be handy in many situations. It's re-Listed.

Maybe I should start the flow even slower though? It speeds up as you win, and the current starting seems pretty slow to me, but I have all those built up Pipe Dream reflexes.

I think the starting speed is pretty good, but perhaps the acceleration between levels is too extreme. After about five levels it became near impossible, I recall. We had to restart. Maybe you could keep the same speed for three levels at a time or something.

To be honest I mostly want to leave it this way as a good test case for BYOND! I think that all the simultaneous animation and the quick use of images in the game stress some nice areas of the system and I'm hoping that it will help drive improvements in those areas.

Fair enough!

The DDT is excited about the game

I am too! I'm looking forward to seeing what kinds of quirks you add in next. I hope this will spur on a contest of one-upmanship for the other members in the community (Sheep III, Hunter 3D? Etc). Of course, it will be hard to compete with such a fearsome threesome. Cliques will form, rivalries will be created, egos will be shattered. Good stuff!

By the way, this is now planned to be a revenue generating game. We have to work out the exact plan, but the basic idea is that the "Snot Simulator" level will be freely playable, and the expansion will either be donation-based or require a very small one-time payment to play. Obviously some of that planning will have to wait until we see how the BYONDimes system works -- one requirement it immediately brings up is that the game needs a way to know that a person paid, and how much they paid.

We'll have to get it in place, then. I believe that your questions will be answered with the pay() command.

Good luck!
In response to Tom H.
On 10/20/00 10:09 am Tom H. wrote:
I believe I understand how it works, and I understand the intention (allowing other people to affect your game), but in my opinion the game is difficult enough (especially in multiplayer) without having this restriction. It's just too easy to end your game on a depressing note because you accidentally placed one bad combination. Worse is when someone else does it for you. I don't have a problem with them being able to affect your game, but when they can screw it up completely with just a few motions it's a bit too much.

What the multiplayer game is exactly is definitely an evolving thing (the trench replacement rules changed twice just yesterday!). My only concern is not completely precluding players from messing with each other. From your comments, it sounds like maybe the combination should be:

- Other players can't change trenches that connect back to your dragon.

- Other players can add to your trenches, in hopes that you won't notice or that they can cause a last second change of direction.

- You can replace any trench in your line that is not already filled. When scoring is in place, you would probably take a score hit for doing this, perhaps a point for each trench orphaned by the change.

Does this sound reasonable? I will put it on the DDT list for consideration!


I think the starting speed is pretty good, but perhaps the acceleration between levels is too extreme. After about five levels it became near impossible, I recall. We had to restart. Maybe you could keep the same speed for three levels at a time or something.

As it happens, that's exactly how single-player works! I just figured that it might be fun to ramp up multiplayer faster. (You know, just how many rounds in a row do you want Spuzzum to win?)

Anyone else have comments on this?


Cliques will form, rivalries will be created, egos will be shattered. Good stuff!

I'm actually a bit concerned that no one be put out by the fact that, in putting together a small group, I limited it to the three of us for now. My projects with Guy kept growing, and Gazoot's music just blew me away, and I want to keep it comfortably small to start with. If the DDT takes off, it's quite possible we might work with others over time (and of course each member is a free agent also!)

By the way, this is now planned to be a revenue generating game.
Good luck!

Well, good luck to you guys too! A major reason to try and generate revenue here is to help keep BYOND healthy and growing.
In response to Deadron
On 10/20/00 10:47 am Deadron wrote:

What the multiplayer game is exactly is definitely an evolving thing (the trench replacement rules changed twice just yesterday!). My only concern is not completely precluding players from messing with each other.

Agreed! In fact, right after I posted I began to have second thoughts. Maybe the rules I've suggested would completely eliminate the screwage factor that makes multiplayer so appealing. I'm so wishy-washy.

- You can replace any trench in your line that is not already filled. When scoring is in place, you would probably take a score hit for doing this, perhaps a point for each trench orphaned by the change.

Does this sound reasonable? I will put it on the DDT list for consideration!

Oooh. This suggestion is a appealing, specifically the idea that replacement should not be without restriction or penalty. It does require a bit of finnesse so that your nice simple rules don't get too complicated.

I guess I would suggest sitting on the current behavior for a little longer so you can gather some other opinions. Oops. I guess that's what you suggested at first!
In response to Tom H.
* This isn't so much an improvement, but a query (or perhaps a mode of play). What if you made it so that the juice flowed everywhere you had a trench? So if you had one of those four-way deals, it would go out the other three ways. Any juice hitting the ground would be "out of play" (so you couldn't stall it), but you would only lose when all the juice was out. Would this make it too easy? (it's never too easy for me .. I suck). The four-way trenches would be very powerful. You could also add in three-way trenches. Perhaps this is too much to ask for something that might be hard to implement. I think Spuzz had some thoughts on this too.

There you go, putting words in my mouth! No, I was just complaining that because I put an angle piece against a 4-way piece, and I couldn't change that angle piece, though it wasn't even in the direction of flow.
In response to Spuzzum
On 10/20/00 11:19 am Spuzzum wrote:
No, I was just complaining that because I put an angle piece against a 4-way piece, and I couldn't change that angle piece, though it wasn't even in the direction of flow.


Hmm not sure there is anything to do about that one -- the game has no way to know what the direction of flow will be. In this particular case, maybe you were planning to loop around and run the flow through a second time in the other direction, for example.

However, this could lead to the new science of Snot Fluid Dynamics!
In response to Deadron
On 10/20/00 11:26 am Deadron wrote:
On 10/20/00 11:19 am Spuzzum wrote:
No, I was just complaining that because I put an angle piece against a 4-way piece, and I couldn't change that angle piece, though it wasn't even in the direction of flow.


Hmm not sure there is anything to do about that one -- the game has no way to know what the direction of flow will be. In this particular case, maybe you were planning to loop around and run the flow through a second time in the other direction, for example.

However, this could lead to the new science of Snot Fluid Dynamics!

If you allowed any changes to the snot trail that didn't have, um, fluid in them, then this bug would vanish. But, for sake of example, here's what happened:

Direction of Snot:

..V..
X . X | X X X
. . . | . . X
X . X | X . X
- - - | - - -
X . X |
X . . |
X X X |


The angle piece is the one on the right. The flow is continuing southward, at which point I'll get a horizontal bar...

X O X | X X X
. O . | . . X
X O X | X . X
- - - | - - -
X . X | X X X
X . . | . . .
X X X | X X X


Now, I have all of the pieces I need... a horizontal bar, a south-to-west angle, and a east-to-north angle.

I go to put down my horizontal bar over top of the angle brick...

X O X | X X X
. O . | . . X
X O X | X . X
- - - | - - -
X O X | X X X
X O O | O O O
X X X | X X X


...but can't because it assumes it is in the direction of flow, when there is no way in heck that it could go that way. I lost. =P