-
Notifications
You must be signed in to change notification settings - Fork 7
development discussion
First off let’s impose a little order here. All new updates should appear on the top immediately following this block of text. Please try to keep things in list form with explanations given as needed. Also include a date next to your update so that we can get a sense of whether things are still be relevant. Finally, leaving your name somehow (for instance the traditional — name format at the end) would be a great!
— aschearer
I’m going to propose some big changes to the design, as the addition of the light rendering system creates a strong reason to remove the collision detection system from the light rendering process.
I suggest a new interface (model view control, whaddya know):
CollidingEntity – these entities must all implement repel, move, and onCollision.
CollisionLevel – this should be where the collision handling actually occurs. As it stands the shadowlevel is now taking up too much responsibility and the code becomes difficult.
The original ShadowCaster, ShadowEntity, and LightSource interfaces can stay put, as they describe the relationship of how things are lit in the game. The two interfaces I’m suggesting will make it so that the LightRenderer will not be the one handling the grid, etc.
Alex, Gornova, let me know what you think, and if you can get these changes made. I’ll probably get to them once I’m done refactoring the light system.
JJ
Hi Alex! I’m waiting your input: where can i help coding something?
— Gornova
- The mushroom following algorithm needs to be updated to accommodate wrapping.
Took a stab at this. Mushrooms now wrap at least passably well. There’s still room for improvement.
— aschearer
- Need to implement meter system for measuring time-in-the-sun, player loses when meter runs out.
Added a simple meter which is updated whenever the player collects mushrooms. This actually makes the game a lot more fun by injecting some tension. Still plenty of balancing issues left.
- Created new build file to automate all sorts of common things
- Implemented “absolute” control scheme over “relative” control scheme, thanks JJ for the idea!
- Added “wrapping” for player, you can now move off stage (and appear on the other side)
- Updated level design to optimize for wrapping. Again, thanks JJ for the discussion on wrapping.
- Updated wiki to streamline layout. Hopefully it’s easier to find what you want now, I’ve tried to remove the junk.
- Updated work items to reflect latest changes
— aschearer
I’ve just checked in another huge set of changes. Let’s look at the previous set of work items:
- Dome.java is a mess and totally out of date. It should be easy to have it correctly implement the ShadowCaster interface but it is erroring currently. Fix it.
- There are performance problems with the domes’ shadows
Done. Dome now works just like you’d expect. I discovered that Slick has a RoundRect shape which solved all our problems.
- There’s a bug with picking up mushrooms, it’s a Slick bug and I reported it, but if it doesn’t get fixed soon we should work around it
There is a workaround for the bug which we are employing throughout the code. If the bug gets fixed we can switch back which might keep things conceptually simpler but otherwise we’re good.
- Mushrooms aren’t shrinking and dying (because they are always in the shade)
Mushrooms no longer cast a shadow. In fact I’ve made it possible to opt out of that altogether by simply returning null for your shadow. I don’t see this as a big loss unless we really wanted mushrooms to grow in other mushrooms shadows… Feel free to rework things to enable that scenario if you like.
And here are the old ones which aren’t fixed yet (ordered by significance).
- Collision response isn’t right yet. It should be possible to “slide” along an obstacle.
- Monsters! We need monsters!
- The mushroom placing algorithm is not correct. It sometimes places mushrooms too close to or even inside an obstacle.
- It shouldn’t be possible to walk off the level. In fact the player should collide with the green trim.
- Need a lot more feedback for events such as picking a mushroom, collecting, losing, etc etc
- Need to figure out how to really cast the shadows correctly. Right now they overlap eachother which isn’t right. (To see this change the shadow’s alpha to something less than 1)
- Need to make more complex shapes as per the mock up.
So we really have all sorts of things to work on even for the early mock up phase. The collision response is probably the easiest. You just need to update the player.onCollide method. I even have some code to start to work things out checked in. The monsters problem is most likely the most fun task on the list. It involves writing AI for the monster and making big decisions such as how the monster behaves. Personally, I think the monster should look for and eat other mushrooms, but at the cost of potentially evaporating under the sun.
— aschearer
Instead of quickly copying over all the junk I’ve written so far I’m taking this move to git as an opportunity to start over. Let’s figure out what exactly we want to do with the code base.
Some big questions,
- Do we want to use Phys2d, how about JBox2d, or should we just roll our own? (Check, rolling our own for the time being)
- How about a basic game framework, have you got any lying around? (Check, I just used what I had from Forte)
- Tile based game or not? I’m thinking not… (Check, it’s not)
- Whoa, real time lighting?! How the hell does that work? (Check, it works by cheating as much as possible)
For the first question, I want to do whatever will accelerate development. I started to explore JBox2d but I found it totally confusing. There’s no documentation… the example is next to useless… I am not even sure how to draw their entities to the screen. Phys2d is at least easier to use. However I still find it a pain to have to battle the physics engine to get entities to move as you want. That said, I am not up to the task of implementing a comparable collision detection library, so I’m willing to put up with some of the unpleasantness of Phys2d in exchange for its superior quality. What are your thoughts?
Ideally, one or both of us has some basic game engine code we can start fastening into place so that the gears can start turning… I’ve got some stuff which you’ve seen in the old repo. However, most of my old code doesn’t use Phys2d or doesn’t use it in a manner which will translate to this game, so if you’ve got some experience there please step forward!
I don’t think we can make this a tile based game and still have the right sorts of objects casting shadows. Most likely the obstacles in the stage need to be larger than a tile ought to be. They will probably vary in size a great deal too. Let me know if you think we should still go with tiles.
Finally, this is the most important part of the game but also the biggest gray area. I know on some level that we just need to specify a light source and then do some trigonometry, but I think it will be difficult going from that level of abstraction to the real thing. Any thoughts? Let’s get some code running without real time lighting and then start prototyping solutions for the problem.
— aschearer
h3.gornova:
- i don’t have any experience with phy-engine. But the question is: we need it ? Really ? To do what? We can move actors (player, monster) into screen.. and stop i think. So please explain me why we can use it!
- your old repo-code is a perfect start: it’s clear and simple!
- good question. My first idea was to use some editor (like tiled) to build test map, and then moving into random-generate maps. I think that we can use tiled map to set initial position of player, mushrooms, blocks, and draw terrain, so we don’t bother to do it with java. But into real game we need to draw shadows, so it’s a good question. For now no, i think.
- some link when we can start:
Those are some great links. Hopefully we can use that second one to implement everything! We need a physics engine to handle collision detection. That’s the only reason we need it. I’m happy to try our own collision detection (in fact that’s what’s in the old repo) but it won’t be as good as theirs. It will also require a lot of time and energy to write our own system for this game, my old code isn’t really appropriate.
If you look at the prototype screenshots linked in the shade gameplay page you’ll see what Shade should look like when it’s done. The end product doesn’t really look like a tile based game. The blocks and such are all very large, too large to be a single tile. This can still be accomplished with a tilemap but it’s messy. I don’t think we’d gain much by going with tiles, either. There is only one stage and its going to be pretty simple so there’s no reason we can’t just write it in a script or something.
—aschearer
Understood why use physics engine: i think that our better choice is Slick’s phy-engine, so we have a minimum of tutorial and help from kevin (slick creator and mantainer), what do you think?
Ok, no tiles! :D
I’m sure you really wanted to know, so here’s what we still have left to figure out.
- How do we add mushrooms to the world correctly, meaning…
- They are in the shade
- They don’t intersect with another mushroom or obstacle
- How do mushrooms know when they’re in the shade or sun? We need some sort of database for this… this is probably the hardest
- Collision response isn’t right yet, hopefully a bug in Slick will be fixed which will make it possible (I filed the bug)
- Need to figure out how to really cast the shadows correctly. Right now they overlap other objects which isn’t right.
- I’m thinking we should implement a Z-buffer and just sort things by some z-index assigned to the objects.
- Also need to find a way to have the shadows move over time in a smooth manner. Definitely are biggest technical problem. There are performance problems with the domes.
- Need to make more complex shapes as per the mock up.
- Monsters! We need monsters!
- Still some bugs in my shadow implementation.
- adding mushrooms in world: good point. I think that we need a sort of map (or matrix, as you wish to call it), to understand where are objects/mushrooms and so on, so we can avoid interstecting. We need a shadow matrix, or a method to understand if, given x,y, there is a shadow or not. To do this, we need to undestand that shadow is not only a graphical effects, but a gameplay element.
So my idea is:
- create a matrix (x,y) to map position of actors (player, mushrooms, objects, and so on) in the game
- create a matrix (x,y) to map position of shadow in the game
The problem is that, doing in this way, we are using a tile-map approach, in sense that we need a discrete number of cells that represents map status :-/
- z-index for shadows can be really usueful, but think about that: player and monsters, and mushrooms too, have shadows? Yes! So we need to add a “height” properties to everthing in the game.. so everything can have a shadow!
- How do we add mushrooms to the world correctly, meaning…
- They are in the shade
- They don’t intersect with another mushroom or obstacle
OK, I’ve taken a stab at this. I basically try to pick a random shadow then pick a random point then check that things are OK. Sounds easy but it’s not working well (it’s buggy) but it’s close enough to give you an impression of how it would work if it didn’t bug out.
- How do mushrooms know when they’re in the shade or sun? We need some sort of database for this… this is probably the hardest
It is hard. It would be easy if mushrooms didn’t cast a shadow. In fact, the implementation on the code right now assumes they don’t (but they do so it doesn’t work) and all it does is iterate over each shadow and check whether the mushroom’s center is in the shadow or not. Simple right? Not when mushrooms have shadows as that totally invalidates the loop. We’ll see what a good solution is to this. One possible solution is to pull the mushrooms shadows out of the shadowscape altogether, but if we do that why not just forget about giving them shadows completely (which is an option).
- I’m thinking we should implement a Z-buffer and just sort things by some z-index assigned to the objects.
I implemented this. It does it’s job simply enough. It doesn’t totally solve our shadows problem however because shadows are still intersecting with other shadows causing that area to be too dark. Ideally the entire shadowscape would be uniform. So I’m going to leave the shadows issue as a work item.
- Also need to find a way to have the shadows move over time in a smooth manner. Definitely are biggest technical problem.
I am actually updating about 18 rectangles on each frame and its still running at 60 fps and things are totally responsive for the player. This includes mushrooms popping into the game. So I’m optimistic about this. Domes are still a work item.
- Still some bugs in my shadow implementation.
I have actually managed to really fine tune the shadow algorithm for rectangles. That’s not to say you can’t improve it but I think it’s bug free and efficient at least judging from running the game. It may be possible to improve speed somehow, but I don’t think it’s a top priority; I’d rather see one of the other work items completed.
Here are the rest of the work items left from before plus some new ones.
- Collision response isn’t right yet, hopefully a bug in Slick will be fixed which will make it possible (I filed the bug)
- Need to figure out how to really cast the shadows correctly. Right now they overlap eachother which isn’t right.
- There are performance problems with the domes’ shadows
- Need to make more complex shapes as per the mock up.
- Monsters! We need monsters!
- Mushrooms aren’t shrinking and dying (because they are always in the shade, see above)
- There’s a bug with picking up mushrooms, it’s a Slick bug and I reported it, but if it doesn’t get fixed soon we should work around it
- Dome.java is a mess and totally out of date. It should be easy to have it correctly implement the ShadowCaster interface but it is erroring currently. Fix it.
Also, Gornova, it’s fine to have things be partitioned spatially (as in with cells, read tiles) in fact that’s how the collision detection system works. The only thing we won’t be doing is actually making a tile map, using Tiled, etc. I think it’s a very good idea to approach some of these problems by trying to divide up the physical space into a matrix and then performing the heavy work on a subset of the entire matrix. (Again this is exactly what the collision detection system I wrote is doing)