A few months back, there was a topic about making your games more "crunchy" and "juicy". and in it, this video was linked:
And I thought, "it'd be great if BYOND games could take it to that level".
And now they can!
Yep, Yut started that. I brought up "crunchy" mechanics.
http://www.byond.com/ forum/?post=1320998&hl=crunchy#comment5426479 I never clarified, but "Crunch" is the substance of your game. It refers to systems that are complicated, difficult, and/or progressively involve the player in more content. Basically, a game is said to be crunchy if there's not just a lot to do, but also a meaningful, and satisfying pace to all the things you do. | |
Juiciness looks like every major game in the Android/iPhone markets. Though it makes your game look slightly less rigid, it doesn't alter the gameplay whatsoever. So you probably earn maybe 5% more replay value because of aesthetics. I like Ter13's philosophy of "crunchy" mechanics better.
For me personally, what brings me back to a game is how much I get out of the play experience. The game can look like complete crap, but when a game hooks me in with its fluid mechanics (I guess not unlike "juicy mechanics," but I think this is a bit different) and design concepts that just fit together so well, it brings me back to want to play it again. I find a lot of arcade games fun in that sense. Like Joust or Galaga. Even Tetris. If by juicy mechanics you mean better aesthetics and animation, I guess it makes things a bit more interesting. I mean, I certainly would find it a bit boring if Tetris lines didn't do anything when they got filled in other than disappear. | |
SuperSaiyanGokuX wrote:
None of us now have to bother designing or writing our own icon animation functions (or even finding and implementing a library)For atom.transform and mouse position, no one had to before, either. You're ignoring the fact that it's been done, and it was as simple then as it is now. // then: The end-user doesn't care what is inside IconAngle(), and they especially don't care (most don't even know) what goes on with matrix transformations. You say "new stuff means no one has to write it" as if no one wrote it. That's what makes you sound like you're ignoring Lummox entirely. It doesn't matter to the end user who did the work, as long as it's not them.The end user didn't do the work, so where's the difficulty coming from? You wrote neither my library nor the native implementation. How are you then going to compare how you use them? This stuff is now much easier to add to a project.Because downloading a library and clicking a checkbox is so difficult compared to... updating BYOND? | |
Kaiochao wrote:
It's easier now because you no longer have to download a library and click a checkbox to include the functionality. I see what you mean. As for what the end-user actually writes, that doesn't change at all in terms of difficulty. But... Is there a library on this site that has equivalent functionality? (I genuinely don't know) So now, it becomes a matter of finding one, perhaps testing several to see which works best (or best for you), reading over the implementation notes a bit just to see which function is relevant to your needs, ticking that box, etc. In many cases, most developers around here would actually prefer to just reinvent the wheel than go through the hassle of adding a library (and many of them do; and many of them decide to release their own library for the same functionality that's already out there). But now they don't have to write anything, or find anything to add (at least in terms of graphical animations) I mean, a BYOND developer could re-write the entire movement system (with their own versions of Enter(), Entered(), etc.) or maybe even find a library that has already done so... but isn't it much easier that BYOND has this stuff built in? I understand your point that people around here need to utilize libraries more often if they want non-native functions and don't desire to write their own, but that's not really the topic that rises from Flick's original statement. | |
I think this entire discussion is missing a key point, though. I know you swept it aside deliberately, Kaio, but it was much more important a point than perhaps what you may think.
The client no longer has to generate appearances and cached data per-icon proc, and it is MUCH easier to interact with given the fact that every time you create a new icon transformation, you have to create a new icon handle. You can't do multiple edits to a single appearance. Each time you change it, you have to generate a brand new one, and increase your footprint. Not only that, Icon procs are not equivalent to the transform blitting. Theoretically, the transform matrixes should be applying a transform matrix to a quad as it is blitted, rather than generating and manipulating raster data, which is what the icon procs do. While it might be the same basic idea, they are very different implementations, and as such, the new features serve a much more modernized and streamlined purpose. I think it's hard to argue that X or Y was easier objectively, but I do know that I, as a developer, am much less concerned about implementing something like this. Look at everything that's been done in this thread thus far. It's all pretty nice work, but frankly, the fact that it's impressive is only a testament to the tools we have had available within the engine for so long. The new functions should allow us to consistently and much more easily bring our games some much needed graphical glitz. The point that's been swept aside is integral to each and every one of these things that have been shown off here. It's that it's being done in a sane, regular manner. The fact that we got used to pre-rendering animations frame by frame for dynamic behavior is a major problem that needs to be addressed. I agree with your semantic point, Kaio, but I disagree that the approach you hold up as comparable was ever the "correct" approach. It was just the only approach we had at the time. | |
Kaiochao wrote:
SuperSaiyanGokuX wrote: > // then: Are these native functions and variables? I've never seen them in the reference... The end-user doesn't care what is inside IconAngle(), and they especially don't care (most don't even know) what goes on with matrix transformations. What I'm saying is that the majority of BYOND developers will not use libraries to do this sort of stuff, they will feel a necessity to write these functions themselves. And now, none of them have to. The end user didn't do the work, so where's the difficulty coming from? You wrote neither my library nor the native implementation. How are you then going to compare how you use them? In most cases, the end user will have done the work. Custom icon animations prior to 500 would have been an almost entirely DIY thing for developers. Again, now they don't have to be. Yes, perhaps a library existed to do such things. But people were likely not using it. This stuff is now much easier to add to a project.Because downloading a library and clicking a checkbox is so difficult compared to... updating BYOND? No. Because writing "animate(blah, blah, blah)" is much easier than writing: var/icon/I=new(src.icon) I.Blend(rgb(200,100,0)) I.Scale(64X64) I.Turn(45) src.icon=I | |
You're speaking with the same bad attitude towards libraries that I'm actually referring to. What makes the functions I showed you any different from native functions and variables? If you treat them differently, you're using libraries completely counterintuitively.
The majority of BYOND users don't use libraries because they're absolutely terrible at everything. | |
Kaiochao wrote:
The majority of BYOND users don't use libraries because they're absolutely terrible at everything. Which? The libraries, or the BYOND users? :) But, getting to the issue at hand, we're just arguing because we're coming from two different angles on this subject (or, perhaps it could be said that, we're seeing two different problems). Your point is that if people would use libraries, then they'd have had all of this functionality long ago. My point (and, I believe, Flick's) is simply that (excluding library use), prior to 500, all of these effects had to be done with a lot of messy and potentially lengthy code (along with some algorithm design), whereas now, it's as simple and easy as sticking a function call or two in your code. Sure, it's equally simple and easy if you had been using a library all along. But that's a different topic of discussion to the comparison between writing an animation function prior to 500 vs. using the nice new one we've been handed. I actually agree that using a library or using a built-in procedure is equivalent (and I've even said so already), but again, that's not the point of the original statement (and my defense of it). | |
To continue the thread about doing things with animate...
This cute little guy is Tofu:  Tofu's walk cycle is animated with nothing but animate() and transform. Each limb and his body are all independent objects that move and animate with him. I was kind of inspired by Scribblenauts. Credits to Vrocaan for Tofu's sprite. We're thinking of taking this system to the max and utilizing it in the contest :) | |
Add a pink bow.
Super Tofu Girl. Get sued. | |
Fugsnarf wrote:
To continue the thread about doing things with animate... He makes a good point. I've knocked this thing too far off the rails...lol | |
Yep, I think everyone's coming at the library vs. native issue from different angles but is more or less on the same page. I'd love to see more library usage going on, especially libraries taking advantage of the new stuff.
A good lib certainly could have done most of what the new features do, though with a couple of difficulties. Server and network usage would be way up, and most animations on the client end would be stuttery or have timing problems. So there's that, anyway. The new native features give a lot of bang for the buck. Actually on the subject of libs, I'd really like to make some structural changes that would improve matters for lighting libs. Right now the fastest lighting libraries use areas because adding overlays to turfs is freakishly slow. The reason: Any turf appearance change resends the entire visible part of the map to the client. (This actually has implications for animate() when applied to turfs, but I think most people are using it for movables anyway.) I'm not sure if the same applies to images attached to turfs; images might actually be a better way to handle lighting, in that two players can see the lighting on the same wall differently. | |
Lummox, Would it be possible to chamge how the atom is rendered in terms of things like additive or subtractive rendering? An additive render with alpha would give a nice ghastly look.
Something like atom.render = ADDITIVE_RENDER | |
I think it's planned, Makeii.
| |
Additive, Subtractive, and Multiplicative rendering for atoms (in addition to the existing Overlay) would be absolutely boss.
| |
Topkasa wrote:
Additive, Subtractive, and Multiplicative rendering for atoms (in addition to the existing Overlay) would be absolutely boss. That it would. Mixing atom.color with multiplicative rendering, you could even multiply individual color channels, and that would be even more boss. | |
I didn't finalize any plans for blend_mode (I wanted to get 500 out), but I think additive, subtractive, and multiplicative are probably all good choices. Multiplicative has some iffiness with alpha since it first requires the icon to be rendered against white, but that's a pretty solvable problem.
Please do add some comments to the thread in Feature Requests. I'd like some input on how the var should be setup and what values it should take. I think this will be a 501 feature. [edit] Just to be clear, software rendering can only support normal blends and (surprisingly) additive. All others are off the table and will only work in hardware mode. | |
Ter13 wrote:
Yep, Yut started that. I brought up "crunchy" mechanics. u wot m8? | |
You might give that library a shot, and try a fracture effect. Break the block up into a series of pieces, then shoot the particles off in a random direction, with random rotation velocity and scale/fade at the same time. Extra points if you apply gravity to each of the particles. Would be a neat effect to try for a block-breaker kind of game.
I wonder if Flick used ObjectPools for his particles. He commented on it, so I'm guessing it's a maybe.