search

abraker95 / tanks

2D arcade top-view shooting game
1 stars 0 forks source link

Main Discussion #14

Open ghost opened 10 years ago

ghost commented 10 years ago

We will use this "issue" for the main discussion.

ghost commented 10 years ago

I'm trying to get 1 line of code working for 4 hours. And it has to do with the include loop interdependency. I decided not to push the broken code until I got your thoughts on the problem.

env->addObject(this); // this thing is in object.h, and I can't include environment.h because environment.h already includes object.h

ghost commented 10 years ago

Ok I found a solution, but you may criticize it for its design. I hate it too, but at least the object management is more automatic. The environment provides the object the object pool to add itself upon creation, and the Environment deletes the object if it sees the object set itself to be destroyed. I am pushing the new code since it runs.

ghost commented 10 years ago

ok, im going to take a look.

ghost commented 10 years ago

I made the environment a singleton, now the object class doesn't depend on environment. We should be able to go pretty far with this design

ghost commented 10 years ago

I think it is a good idea if you enable all compiler's warnings. For example the "extern friend class" was just an error for me because of that. Warnings are always good.

ghost commented 10 years ago

Good idea.

Also I was thinking of making the visual style of the game unique. Can we use layers to give a some what depth effect? Almost like paper mario. The tank will be made of many smaller objects like wheels, body and cannon. Imagine those pieces flying apart if the tank is hit by a rocket. It's just a rough idea, and maybe we can improve on that.

On Thu, Nov 13, 2014 at 4:47 PM, Sherushe notifications@github.com wrote:

I think it is a good idea if you enable all compiler's warnings. For example the "extern friend class" was just an error for me because of that. Warnings are always good.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-62972247.

ghost commented 10 years ago

I like it. I will create the tilemap class with that in mind.

ghost commented 10 years ago

Whoever gets the assignment for an issue about implementing the rectangular collision first gets to work on it. I don't think the vector based collision is of high priority right now. I will probably get back to it when we will be doing fancy effects like highlighting a projectile's path. So, If I don't get the assignment for collision first, I will work on either:

1) Scene code 2) Object Layering 3) GUI objects class

Which one of there is more important?

ghost commented 10 years ago

I already assigned myself for the rect vs circle collision, but you can do it if you want. I just thought maybe you had enough of vector calculations. Do you want to work on that?

Restructuring the environment class is the highest priority.The 1). We can't do any GUI stuff without it and object loading is also dependant of the implementation we make.

ghost commented 10 years ago

I cleared the assignement so go ahread if you want to do it.

ghost commented 10 years ago

You can do it if you want, I'm going to be rather busy today and and tomorrow. So if you need the collision to to further the development, I suggest you do it because otherwise I will be slowing down progress. I would rather work on other features at my own pace in that case. If it won't slow down the development then I can take on the assignment.

On Mon, Nov 17, 2014 at 10:53 AM, Sherushe notifications@github.com wrote:

I cleared the assignement so go ahread if you want to do it.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-63325114.

ghost commented 10 years ago

ok I do it. It isn't the most interesting thing anyway and we can finally add walls.

ghost commented 10 years ago

I added a new programming guideline: If a new file has been added to the project relating to an issue, add a "new file(s)" label to the issue and state the name of the files added. If the issue pertaining to the added files doesn't exist, then create it.

This is due to visual studio not seeing new files that are pushed into the repo that don't exist locally.

ghost commented 10 years ago

I have the same problem here. I have to tell cmake so its a good idea.

ghost commented 10 years ago

Hey Sherushe! One more day left until I can put college work aside for a bit. So what's the status of the component system? Also, be sure to follow at least some guidelines. You added a bunch of files and renamed some others, so it would take me extra work, following through the commits, to see what to import.

Since you are far into the component based design, I'd rather not repeat the same incident as what happened with the camera. I will instead proceed to work on the GUI and HUD.

ghost commented 10 years ago

Hi, Alright, it's a good thing that you work on the GUI. But what do you mean by same incident? We are working on different things. If you fix the Dev branch and optimize the architecture, we could do a better comparaison between both.

For the component system, sorry the repositry is still in an "in-between" state. Once i get the system to work I will properly name the files and tell you how it works. For the status, i'm struggling a bit with the design, because i wanted to have a strongly typed system but the consequence of it is that everything needs to be in the headers ( because of templates ). I hope I can find a solution soon.

ghost commented 10 years ago

For the status, i'm struggling a bit with the design

Take your time. Just keep me posted, so I'm not in the dark.These last couple days were very busy such that I didn't go over to github to check the status until yesturday, and github never sent me updates about the new commits. So try writing something in the issues so I know the project is not on hiatus.

On Tue, Nov 25, 2014 at 4:51 AM, Sherushe notifications@github.com wrote:

Hi, Alright, it's a good thing that you work on the GUI. But what do you mean by same incident? We are working on different things. If you fix the Dev branch and optimize the architecture, we could do a better comparaison between both.

For the component system, sorry the repositry is still in an "in-between" state. Once i get the system to work I will properly name the files and tell you how it works. For the status, i'm struggling a bit with the design, because i wanted to have a strongly typed system but the consequence of it is that everything needs to be in the headers ( because of templates ). I hope I can find a solution soon.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-64337747.

ghost commented 10 years ago

I can write things in the issues, but the design is constantly changing so if I say something it will probably be wrong the next day. Don't worry if you don't see updates, I'm working on it whenever I can. I pushed the last updates so you can see the current state.

Everything is in include/core/memory.h, but it's still evolving.

ghost commented 10 years ago

I will tell you when it's ready so no messages means I still have problems.

ghost commented 10 years ago

the design is constantly changing so if I say something it will probably be wrong the next day.

Nothing like documenting the history of the project. This is also know as a changelog

On Tue, Nov 25, 2014 at 6:44 PM, Sherushe notifications@github.com wrote:

I will tell you when it's ready so no messages means I still have problems.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-64492143.

ghost commented 10 years ago

Good idea. I will make one once I get the base system running which sould be pretty soon ( probably tonight ).

ghost commented 10 years ago

Are you planning to merge the experimental branch with the dev branch?

ghost commented 10 years ago

Well, I think we can keep the oop architecture for a souvenir. I think the best would be to directly merge with master once we reach a millestone or something.

ghost commented 10 years ago

We will merge with master after the scoring system is implemented at least. A game is no game without game mechanics; it's a demo otherwise.

On Thu, Nov 27, 2014 at 5:00 AM, Sherushe notifications@github.com wrote:

Well, I think we can keep the oop architecture for a souvenir. I think the best would be to directly merge with master once we reach a millestone or something.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-64768883.

ghost commented 10 years ago

As soon as you are ready to merge with the dev branch I will begin implementing the GUI/HUD code. Visual Studio is giving me issues when switching to a different branch (as if it was another project). Meanwhile I will make sure I understand how to use the new code.

On Thu, Nov 27, 2014 at 5:05 AM, A Braker abraker95@gmail.com wrote:

We will merge with master after the scoring system is implemented at least. A game is no game without game mechanics; it's a demo otherwise.

On Thu, Nov 27, 2014 at 5:00 AM, Sherushe notifications@github.com wrote:

Well, I think we can keep the oop architecture for a souvenir. I think the best would be to directly merge with master once we reach a millestone or something.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-64768883.

ghost commented 10 years ago

Alright, I will merge with Dev. I will keep the oop code in the "old" folder.

ghost commented 10 years ago

I added a wiki page explaining how to work with the entity component system. Maybe look at some existing projects to give you an idea of how the components and the systems look like.

ghost commented 10 years ago

Ok sounds good On Nov 27, 2014 3:47 PM, "Sherushe" notifications@github.com wrote:

I added a wiki page explaining how to work with the entity component system. Maybe look at some existing projects to give you an idea of how the components and the systems look like.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-64829205.

ghost commented 10 years ago

One thing about the compilation: You will probably have to add the "include" folder in the include directories in vc++. Every include is relative to that folder.

ghost commented 10 years ago

I have successfully pulled, built, and ran the project.

ghost commented 10 years ago

I'm done for today. Changelog:

ghost commented 10 years ago

okay. good job.

I will try to fix the bugs.

ghost commented 10 years ago

I cant push. Git is giving me this errors which I have been trying to solve for hours:

current branch does not have an upstream branch configured

You cannot publish local branch Dev to the remote repository origin because a branch with the same name already exists there. You might want to rename your local branch and try again.

ghost commented 10 years ago

My Changelog for today:

ghost commented 10 years ago

So I looked through the SFML docs, and found a function in the RenderWindow class that is going to resolve the coordinates not matching up if the view is altered:

I won't be able to work on the game tomorrow, but I am planning to get at least the buttons done this week. One thing I wonder: Using the ECS system, how would you go about having relative values. For example: A button has text and an icon relative to the button's location, and a scrollbar causes it to move up and down. I am thinking a reference component might do it, but I don't know how it will work for multiple values. The reference component would be updated by the system, where the system gets the referenced value, creates a copy, operates on it and returns the relative value. What do you think?

ghost commented 10 years ago

That function should work. Also when the view will be correctly set, the conversion won't be necessary anymore, I think.

For the relative position, I'm not sure how you want it to work. I guess like it's a parent-child system. Because we won't have a complex GUI, the easiest would to just keep the id of the parent entity and when an object gets rendered, go up the parent chain and compute the absolute position. But do it how you like.

For the project, you don't have to work everyday on it. Do it when you're motivated. In other words, you don't have to tell me when you're busy I will understand.

ghost commented 10 years ago

For the project, you don't have to work everyday on it. Do it when you're motivated. In other words, you don't have to tell me when you're busy I will understand.

I just feel that me working on it once every 2 to 3 days is a bit to little for me. I used to put in hours a day programming back in highschool, so seeing how college takes away that time is a bit sad.

On Sun, Nov 30, 2014 at 4:13 AM, Sherushe notifications@github.com wrote:

That function should work. Also when the view will be correctly set, the conversion won't be necessary anymore, I think.

For the relative position, I'm not sure how you want it to work. I guess like it's a parent-child system. Because we won't have a complex GUI, the easiest would to just keep the id of the parent entity and when an object gets rendered, go up the parent chain and compute the absolute position. But do it how you like.

For the project, you don't have to work everyday on it. Do it when you're motivated. In other words, you don't have to tell me when you're busy I will understand.

— Reply to this email directly or view it on GitHub https://github.com/Sherushe/tanks/issues/14#issuecomment-64979820.

ghost commented 10 years ago

Yea, I agree. Well, if you just have little time to spare, use it wisely!

ghost commented 10 years ago

For some reason the function I mentioned from the renderWindow class is not working. I tried setting the view to screen size and that didn't work either. I am running out of ideas on why the mouse coordinates do not match the view coordinates.

ghost commented 10 years ago

How are you getting the mouse coordinates? Did you get the coordinates relative to the window like this?

ghost commented 10 years ago

oh. I was using sf::Mouse::getPosition().x, but the one with the relative to window parameter could simplify my code a bit, but still not solve the problem. Look closely at how sprites are rendered in the view. The pixels look zoomed in; they have this blinear zoom effect to them, and setting the view to (0,0), (window width, window height) doesn't resolve it even though it should put the view in a 1:1 ration with the window, per-pixel.

ghost commented 10 years ago

Changelog for today:

ghost commented 10 years ago

I see you're progressing with the UI. Nice.

Sorry if I'm inactive, my mind is elsewhere. I will push some code once I'm restored.

ghost commented 10 years ago

ok, and I want to figure out how to resolve the mouse-view coordinate problem

ghost commented 10 years ago

Changelog for today:

ghost commented 10 years ago

I red the code. Looks like you understood what an ECS is. Good work.

ghost commented 10 years ago

I'm getting used to it. It has its limitations that OOP doesn't have that I need to work around, such as getting a certain entity from the list.

ghost commented 10 years ago

What do you mean? An entity is an ID. You can get all its components based on the id.

ghost commented 10 years ago

ok, i am back. Here is the changelog for this commit ( I will probably make one more today ):

New files
Changes

I made two separate components for the sprite and the texture. Reason, obviously flexibility but the most important one is that the tilemap is a vertex array. So now tanks = sprite + texture, tilemap = vertexarray + texture.

Also now every sprite entity must have a Sprite component attached to it. It includes UI elements ( I made the changes ).

ghost commented 10 years ago

I copied the code of the camera into this version:

New files

sorry for the messed up namings. I will correct everything soon.