Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overhead map #85

Open
thegsm opened this issue Feb 21, 2014 · 25 comments
Open

Overhead map #85

thegsm opened this issue Feb 21, 2014 · 25 comments

Comments

@thegsm
Copy link
Contributor

thegsm commented Feb 21, 2014

In many cases it will be useful to have a second view and see the map and not just the current player perspective view.
For example, when driving the cart, the player should see where it's possible to go.

I'll start with something simple in the test area which we can improve upon later.

@bc5389
Copy link
Contributor

bc5389 commented Feb 21, 2014

I got a prototype mini map working

minimapprototype

Here is a link to a video of it(might not be fully processed yet): http://youtu.be/b3vSh-sb9i0

I made a duplicate of the terrain and set it's layer to UI_ONLY then created a child cylinder to the cart also marked UI_ONLY then added and orthographic and set that to only pick up the UI_ONLY layer and set the main camera to ignore UI_ONLY objects.

@thegsm
Copy link
Contributor Author

thegsm commented Feb 21, 2014

Oh, I just saw your post. You have gone ahead than me on this. I only did something very basic (as I wrote here).
Your repository has lots of other changes, so maybe it's a good idea to start merging them (it was difficult for me to find your exact change related to this item).

@bc5389
Copy link
Contributor

bc5389 commented Feb 21, 2014

I think I accidentally commited a bunch of files from a build I made of the game(whoops). I think it's only the bottom few that need to be merged.

@thegsm
Copy link
Contributor Author

thegsm commented Feb 21, 2014

We probably did something similar, only I didn't bother with the UI_ONLY part, so I still think my change can still be considered.

I also added a simple script to follow the cart. It's useful in case the map would be too large so the players sees the surroundings, but not forcing the player to see everything.

I think you'll need to clean up those commits for your change to be viable. So I would suggest this project would first take my initial changes (which can be done now with the current commit) and then you can apply the other changes (I believe it's rather easy to do if I understand your change, but I don't want to continue and widen the gap without us syncing).

@bc5389
Copy link
Contributor

bc5389 commented Feb 22, 2014

Think I fixed the commits but it is fairly simple only would take me a few minutes to redo. I'm still really new to github and git is there a simple way to start over with a clean fork? Just in case my repo got really messed up.

@ghost
Copy link

ghost commented Feb 22, 2014

@bc5389 To clean up any modified files, and untracked files. I usually do
git reset --hard
git clean -f
Be careful though.

@thegsm
Copy link
Contributor Author

thegsm commented Feb 22, 2014

@bc5389 what is MapIndicator.cs? I don't see that it does anything, why did you add it?

@bc5389
Copy link
Contributor

bc5389 commented Feb 22, 2014

Was using it to try and solve the rotation problem that you fixed, I thought I had it attached to the indicator with some code in there to set the transform rotation to Vector3.up

@Cheeseness
Copy link
Contributor

I actually thought it's better to have the tire tracks on the map, but I'm sure it's solvable without having to copy the entire map.

I'm sort of in favour of rendering this to a temporary texture and plotting cart positions on top of that rather than rendering the entire 3D scene again. This gets rid of cart tracks, etc. and should cut down resource usage a bit.

I'm happy for you to both pursue whatever you think is best for the project though :)

@thegsm
Copy link
Contributor Author

thegsm commented Feb 25, 2014

@bc5389 are you up to take some of the load here? We have been discussing some improvements, you may want review and perhaps there's some magic you can do here.

@bc5389
Copy link
Contributor

bc5389 commented Feb 25, 2014

Sorry I've been quiet for a few days I've been sick, when I get out of work I'll take a look at everything that's been added and was gonna take a stab at figuring out a reusable way to render the terrain to a Texture2D instead of the current 2 camera system

@Cheeseness
Copy link
Contributor

Oh, fantastic. Take a peek at #110, #111, and #119 as well.

If you're able to make progress, this will make #117 redundant (which will simplify level creation).

@bc5389
Copy link
Contributor

bc5389 commented Feb 26, 2014

I've been looking over the Unity documentation, unfortunately it seems like the easiest way to do this would have been with Render Textures but that is a Pro Only feature. There is a CaptureScreenshot function but it captures the whole screen so you have to disable the main camera, enable the map camera, take the screenshot, then disable and enable the proper cameras for the game to run. The screenshot function is kind of slow so you see the map view for a split second before the game starts. I changed the map rect settings so it was centered and a good size, after all that you end up with a texture like this:

test2

Which would obviously have to be edited further to be usable. Anybody have any ideas?

@thegsm
Copy link
Contributor Author

thegsm commented Feb 26, 2014

I think the main benefit was that we can play with the way the map looks like when generating the texture. Given the limitations above (either unity pro or relying on screen capture), I'm inclined to say we should leave it as-is for now. We can improve the other parts of the minimap and come back to that later. Does this make sense?

@Cheeseness
Copy link
Contributor

After @bc5389 posted this, we did take a brief look at this as a possible method for rendering to a texture, which looks like it might be manageable.

Definitely no urgency attached to that aspect, but if @bc5389 wants to continue with this, then it's all good, or there are plenty of other aspects to go on with mini-map wise if that's more exciting :)

@thegsm
Copy link
Contributor Author

thegsm commented Feb 26, 2014

I was wrong, it seems very good and easy. @bc5389 just update if you want to continue your work in that direction or take anything else so we'll all be in sync. Of course you may have other ideas.

@Lokno
Copy link
Contributor

Lokno commented Feb 28, 2014

I'm working on a script called MiniMap.cs that will handle drawing the icons (Issue #119 and Issue #110) to the GUI over the MiniMap Camera. I'm using the bounds of the level mesh to scale the player and ball position, and attempting to match that to the MiniMap Camera view. I still need to add some math to convert to camera space, so the scale is wrong, but I've got functioning player direction.

Edit: Updated GIF with corrected positions and flag position

@thegsm
Copy link
Contributor Author

thegsm commented Feb 28, 2014

The arrow does give a good sense of direction, seems to work well.
Hard to tell from just watching the video, so I'll ask, when you played it, did it feel that the it helps you know where you are? Also, did you have to look for the arrow due to the image/size or was it immediately clear where you are going just by a glance?

@Lokno
Copy link
Contributor

Lokno commented Feb 28, 2014

@thegsm I think it gives a good sense of where you are. Regardless, the way I'm writing the script, we can replace the head and arrow with any two layer icon, where one layer rotates around its center.

@thegsm
Copy link
Contributor Author

thegsm commented Feb 28, 2014

sweet! Once it's in we can get someone to close the visuals.
Note that @ErikBehar managed to add these icons as meshes so we would like to use those so we can scale them if needed.

@Lokno
Copy link
Contributor

Lokno commented Feb 28, 2014

Meshes would require a completely different script that what I've written currently, which uses GUI textures. I'm going to make pull request for it because its what I have. We can write something else that uses meshes later. Personally I don't think it would improve the look that much, because the textures are mipmapped and bilinearly filtered.

@thegsm
Copy link
Contributor Author

thegsm commented Feb 28, 2014

Okay, let's start by finding the look we want to achieve. If we'll want see meshes work better we can also consider creating textures from the meshes at runtime,

@Cheeseness
Copy link
Contributor

@Lokno meshes would probably help with those flashing ears a bit.

@Lokno
Copy link
Contributor

Lokno commented Feb 28, 2014

@Cheeseness That's a pretty grainy GIF, I didn't notice anything distracting in game. Textures will be easier to iterate on right now, as we're still deciding how the icons should look on the map. We can write something that handles meshes later.

@Cheeseness
Copy link
Contributor

Were you keen to pursue the method discussed previously, @bc5389?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants