First I thought about adding a special class for these types of plants called interactive objects but since they will differ so little from normal game objects I decided to keep them in the basic game object class for now, the biggest reason being lack of time.
I have already added earlier in code that game objects can hold a light so all I had to do was to enable this light and then use it. It was fairly easy to add and makes a huge different in the feeling of how the world looks. The plan is also to add AI to the other fish that make them attracted to these lights but I'm not sure we will have time to implement that.
So the circle for the plant light is cut out of the dark surroundings the same way as the player light circle mentioned in earlier posts but then I also added a sprite for the yellow light you see in the screenshot for both the player and the plants to make the illusion that the light bulbs actually emits light. It's hard coded?? (It's coded in a non-dynamic way) So the position for these sprites is fixed with numeric values, which is not that good but at this point it's all about getting our features into the game before time runs out.
Then I started adding collider boxes for the plant light bulbs so the program would know when to turn them on or off. For example when the player light bulb is close in range it would light up the plant.
It caused a few minor problems with the player vibrating when near the lights because our collision detection gives off an offset on both objects colliding and it caused the player to bump and move in an illogical way.
Instead of changing how our collision is handled. Changes that can cause our other objects to behave differently I decided to look for another solution. I found one in SFML. SFML have a built in function that checks if a sprite box intersects with another sprite box. It's called Intersects() and since I now use a sprite for the yellow light on both the player and the plants I could simply just check if these intersects and if they do light up the plants light bulb for a set amount of seconds. Here is some code of it:
First I check if the game object has a light. If it has I check the status of the players light bulb (on or off). I then check if the player light sprite intersects with the game object light sprite and if they do the game object light is toggled on.
Right now the timer is on 10 seconds. After 10 seconds the light on the game object goes out. This feature isn't a "game changer" but it adds a lot to the atmosphere and feeling of the game world making it feel more alive.
The feedback I got from testing this feature was really good by the people who tried it so I'm quite happy with it.
Cool! I had no idea SFML had a native Intersect function! Does it only use the sprite's bounds or is it based on transparancy also? OuO
ReplyDeleteGoing for final this Friday, everyone are trying to tie everything up nicely, and I have to say that this looks very promising! We've had to cut a LOT of features. Both extra-features but also vital ones that would've completed the feeling we wanted the player to feel. You however have come a very long way since the Alpha! ;) Although it doesn't really matter, I think it would've been cool had you added the "wavey" effect to the background! I understand if you did not have time to spend on such an "extra" feature, but just like the lights mentioned in this post it might have made the world a bit more alive.
The stuff about hard/dynamic coding that you mention is an interesting topic. I find that a lot of programmers here talk about how it's the most important thing in the world to make everything you code dynamic, and this I simply don't agree with. Just like art, the point of code is to get to the result. How you get there doesn't really matter. Dynamic programming is something to strive towards as much as possible, but you can't forget about the result. No matter how pretty you make the code, if there isn't a good result, all that effort you put into making the code pretty is completely in vain. This is especially true for the current projects. Since the scope of them is so small, the result is even MORE important and the structure of the code even less so!
Anyways, nice, structured post! Unlike some who post entire .h and .cpp files you chose to just add a short snippet of the most important code. The images/code should only support the text and not the other way around! So good work on that!
Keep up the good work! // Sky (Oscar Mohlin) OuO
Thanks for your comment,
ReplyDeleteIntersects work as far as I know only with sf::Rect and since a sprite have localbounds or globalbounds that returns a sf::Rect, that's what I used. And about transparency, my lights collide where the bounding box is so it's not optimal for our lights but it works okay. I don't think there is a way to catch the transparency with this technique though since it’s based on the rects.
For your info, there is also a contains() function with sf::Rects that check if a point is inside a rectangles area. Maybe that can be used in some way to catch the transparency. I haven't tested it though.
I agree with you on the wave shader. I more than anyone wanted to add shader effects like the wave effect, blur or a nice bloom effect and also particle effects like bubbles coming out from plants or waves created from player movement but my group saw them unnecessary and wanted us to focus on other stuff. Because I'm not in any lead role I sadly had to go with what the group said.
I understand your point about code structure and I agree on most. It all depends how things are coded. It’s fine to just put things inside to make a thing work especially when we are short on time and won't reuse the code. But if you are more than 1 or 2 programmers and you change what another group member have done, things might stop working elsewhere because he made a feature that only works in a special case and can't be reused. Then when you try to use it, not only does it not work but it can also mess up the original stuff the other person made because he might have added several numeric limits on different places in the code.
Then it gets troublesome and tedious to find all errors and stuff. So I guess it all depends. There need to be a certain balance. Sure we are short on time but you also need to code so others can understand it and re-use or change the code. Even if you are coding alone you might have forgotten what that piece of code did a few weeks later and then do changes in your code that make things behave strangely. So I believe it all depends on the scope of the project and the people you work with. Do you all think and code the same? In the beginning of this project I tried coding in a more dynamic way since I want to learn to code cleaner and better compared to the project in “spelprogrammering 1” and my group members did the opposite. It caused all kinds of clashes and I adapted more to their way of coding.