Re: csisland improvement
"Christian Van Brussel" <[email protected]> Tue, 23 Apr 2013 19:52:51 +0200
| Newsgroups | gmane.comp.graphics.crystalspace.devel |
|---|---|
| Message-ID | <[email protected]> |
> Apparently the same problem occurs with csbias too. I experience sudden > drop in frame rates at times. And I guess activating the shaders and > compiling them at launch time would fix this issue with csbias as well. This happens with all applications that are using shaders, that is almost all CS applications. > I have come up with a few improvements that might make csbias more > interesting : Did you have a look at the Wiki page on that? There are a bunch of ideas listed there for csbias. It's at http://www.crystalspace3d.org/trac/CS/wiki/Demo%20and%20Test%20apps > 1.I'd like to start by making a crosshair. Although a crosshair is > something strictly artistic, I don't think making a small cross or a > circle would be too out of the way. An idea is to make it a bit more complex than just displaying an image ontop of the 3D view, eg by animating it when the crossbow is reloading. > 2. The arrows go in a straight path.But since its a crossbow it is > expected > that the arrows are shot with considerable velocity and thus follows a > linear path within a certain range. I believe it'd be more realistic if > they follow a slightly more parabolic trajectory thus making it harder to > hit the target at a longer range. The current shooting behavior is very basic: a ray test is made when the player shoots, therefore the damages are computed as if the arrow trajectory was made instantaneously. Improving this behavior is clearly interesting, there are a lot of other ideas towards that in the Wiki page. About the trajectory: I don't think that the trajectory of the arrow can be computed through physical simulation because it is a fast moving object and real-time simulation doesn't like that. This can be tested though, but if it doesn't work then the code that is being used for the trajectory of the physical particles can be used instead. > 4. Snappier bows. I think the bow string moves all too slowly. And the > arrow gives me the illusion that the arrow 'takes off' rather than 'shoots > off'. If the bow string could move a little bit faster and if the arrows > go > off faster I think it would make shooting more 'snappy'. Also, I think the > bow string is sort of too thick. But again, that's the artist's job. This can be changed easily by code by setting a different value for the speed of the animation. > 5. Patrolling monsters. The monsters are looking at my way but they > respond > only when i move within a certain range. I think it'd be better if the > monsters start patrolling with their back towards the hero and attacks him > if the hero is in their field of view. When an arrow falls within a > certain > radius of the monster, the monster goes into 'alert mode' and moves around > to find the hero. But I guess this would mean implementing paths for > monsters and would be complicated enough to be considered as a project by > itself. A better monster behavior would be great but I wouldn't go that far in that direction since a real AI might become a GSOC project in itself. > 6.Monster flashes red when its hit. Alternatively, a monster can have a > health bar. Either way, the user will know when an arrow hits its mark. There are also other ideas about that on the Wiki, eg planting the arrow in the model of the monster, adding blood particles or decals (animated mesh do actually support decals). > 7. Health bar for player - the player can die. The screen edges flash red > when the monster attacks the hero. The hero takes damage when the monster > is facing the hero and is within a certain radius AND moves its hands. This can be made by a combination of HUD elements and post effects. > 8. Pick up-able arrows. The arrows do not mysteriously dissappear once > shot. They lie around. The user is supplied with a limited number of > arrows > and can pick up arrows he has already shot from the ground. Also, arrows > striking the wall can stick to the wall. When the user moves his crosshair > towards the arrow, the arrow highlights indicating that it is an item that > can be picked up. Good idea. Since the walls are in stone, it may be better to not stick the arrow to them, but instead the arrow can become animated by physical simulation. You can also add decals and/or debris on the wall impact. > I would like to concentrate on points 2,3 and 4. I'd like to improve the > shooting mechanism.And the crosshair shouldn't be too difficult to > implement. And I'd like to know what's your take on point 8. Also, this > would mean there should be a minimal HUD as well. Yes, 2 and 3 are great and there are several things that can be made around that. But there are already quite a lot of tools for that that are already in CS so that shouldn't need that much time to be made. I think you can go on and add some other ideas such as 8, ragdolls and some HUD, just list them with some priority regading your timeline. ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr