Well I made good progress tonight on my Classic game, and possibly came up with some issues.
First, the animation works pretty well by manually changing the icon state. In fact, this gives me so much control over the timing that I'll probably keep it this way even with the upcoming icon object. Another nice thing is that thanks to icon tinting, when I have multiple players I'll be able to use the same icons everywhere by just tinting them.
The issues I came up with (which I'm still figuring out whether they are me or BYOND) are:
Adding an object as an overlay and changing the overlay object's icon_state did not do anything. I ended up creating a secondary object and placing it on top of the first for the effect to work.
I'm getting a graphic stutter when I start changing the icon state of an object. The first time seems to take a tick to kick in, after which things go fine. This is a problem for having a liquid flowing along pipes -- each new segment of pipe it gets to, it stutters for a tick. But this could still be me -- I'll play with it more and see what happens before sending any code or anything.
I have stationary objects for which I attempt to change the dir, but the icon......
OH WAIT, brainstorm:
I had the movement attribute set on the icon states, when I didn't really want them to be (I can still forget sometimes that movement state and direction are not related).
So both my icon stuttering and dir problems were related to that. Now, at least running locally, the liquid flows smooth as glass.
Yippee! A couple hours of work and about 60 lines of code and I already have a working version of the game.
ID:194583
 Oct 9 2000, 9:26 pm
|
|
Yippee! A couple hours of work and about 60 lines of code and I already have a working version of the game. That's great news. I only have two things done on Cribbage so far: jack and squat... | |
On 10/10/00 3:51 am Tom H. wrote:
I'm actually quite impressed that the icon tinting works as well as it does. Currently it is really quite inefficient, transmitting the entire icon (rather than just the color change). Of course, once you have generated the tint-combinations and transmitted them once, subsequent re-tints are pretty fast. I was very satisfied with the tinting speed in L&D, which seems to do quite a bit of it. I have never even noticed lag in L&D when tinting was occurring -- and you're right, almost everytime a hit occurs, something gets tinted. By the way, my partner, who isn't too impressed yet with my game work (neither am I, so I can't blame him) actually was impressed when he saw the icon tinting. "Why is that one pink?" he asked. And when I explained, he said, "That works really well." Adding an object as an overlay and changing the overlay object's icon_state did not do anything. Ah then we had some mutual mis-understanding in a conversation a while back. I had suggested something like that if an object is added as the overlay, then the icon would reflect the object's state, and you said that's how it worked. Probably I wasn't being clear because I really meant: the overlay icon should reflect any changes in the object's state. The example I used is armor. You have armor that becomes pockmarked when damaged, and the armor has an icon that you use as an overlay for the mob. When the armor object changes its icon state to reflect damage, the overlay should update too. In my case, the overlay is the flow of liquid through a pipe. Every tick I am changing the amount of flow, so I need to update the overlay. In this game, it is no problem at all to use the workaround I'm using now: put the object physically on top of the thing it would otherwise be overlaying. But in the armor example above, this would be impractical and defeat the purpose. What am I doing -- this is Babble and I'm not Babbling! | |
Well, there's two Classics I'm making. Take 15 (also called Matches) and Othello. Both are hideously easy, and Take 15 is almost done. It's two player only, though; you can only have two people log in. I might have to find a workaround; either that, or host it on the tourney hub.
As for Othello, I have an ingenious idea... =) | |
My Classic game is coming along very nicely. Main game logic is in place and animations/graphics are almost completely done.
Now I'm dealing with the grungy details of: - Making a friendly intro to the game. I'm trying to get certain elements to flash for a few seconds before the game starts, but running into bizarro image timing problems. Since the last time I had bizarro image timing problems it was my fault, I'm continuing to investigate (I suspect though that I'm running into timing problems related to creating an object and trying to do flick() on it right away before it has had time to physically display to players). - Finishing one last UI/game logic item. - Multi-player support. I'm really happy with how it looks. | |
Almost...to...first...release...
I support single player and two players (remaining players are just a matter of choosing some colors). Here are my code comments on what needs finishing: // NOW: handle players 3 and 4 // NOW: add start game functionality // NOW: add explanatory text // NOW: save player state // NOW: handle high scores This is about one more evening's work, so I should be right on schedule for Thursday's GoB... [edit] Wow looking at this message thread it's only been about 6 days of serious work on this project (one day went to friends). I feel like I've been living with it for longer. 6 days to create the game logic, icons and animation, and multi-player support. Boy are my arms tired. BYOND rocks! | |
On 10/17/00 1:54 am Deadron wrote:
Almost...to...first...release... 6 days to create the game logic, icons and animation, and multi-player support. Impressive! Make sure you do as Zilal did and add in some ability to queue up players, since the it is becoming more common for these GoBs to get more than just a few people. Plus, I suck so much at these games (Re: my hapless attacking strategy in L&D) that I think I'll need to watch some rounds to figure it out! What is the game called? | |
On 10/17/00 3:05 am Tom H. wrote:
Impressive! Make sure you do as Zilal did and add in some ability to queue up players, since the it is becoming more common for these GoBs to get more than just a few people. There's no game yet and the players are already insisting on features! Why, in MY day we WAITED for the game to come out before we bitched and we LIKED it that way... But, as it happens, I was indeed planning to steal Z's approach. What is the game called? DragonSnot. There. I said it. | |
Why, in MY day we WAITED for the game to come out before we bitched and we LIKED it that way... What is the game called? DragonSnot. There. I said it. A comedic curmudgeon! He's a jack of all trades! =) | |
On 10/17/00 12:34 pm Spuzzum wrote:
DragonSnot. There. I said it. It amuses me to no end that someone somewhere probably thinks I'm kidding about this title. | |
On 10/18/00 12:36 am Deadron wrote:
On 10/17/00 12:34 pm Spuzzum wrote: Heh. Nope, I took it as an honest answer... anyone still thinking of making that Nocturnal Mission game? =) | |
Good to hear. There are a couple of efficiency issues here that we may have to deal with if they turn out to be significant. When you manually change an icon-state, the server has to tell the client(s), which may be an issue when large screens are updating simultaneously. The advantage of using the internal animation-speed is that all of the work is done on the client, which is just ticking away and updating the icons accordingly. Still, I doubt that this will ever be a significant effect, considering that a worst-case scenario (when the entire view may be updating) is only transmitting on the order of 100-200 bytes per icon-update.
I'm actually quite impressed that the icon tinting works as well as it does. Currently it is really quite inefficient, transmitting the entire icon (rather than just the color change). Of course, once you have generated the tint-combinations and transmitted them once, subsequent re-tints are pretty fast. I was very satisfied with the tinting speed in L&D, which seems to do quite a bit of it.
I think it should work if you change the state before you add the object overlay. You can't do it afterwards because the overlay is merely a copy of the assigned object's icon data, so changing the object won't change the overlay. I could be wrong though. Anyway, here's a proc I posted a while back that at least used to work:
/proc/overlay_state(targ,icon,icon_state)
var/obj/O = new
O.icon = icon
O.icon_state = icon_state
targ:overlays += O
del O
That's excellent! I'm looking forward to seeing what you've done (and aching to write a game of my own too).