Forums Thread

Welcome, everyone, to another sprint. As we push forward in our project, the challenges we conquer as a team, absolutely amaze me.  With that being said, lets get started :).

Does anyone have any comments, questions, or concerns about the agenda they are assigned too?  If you need your agenda defined better or you're not sure where to start, please post on the kanban discussion any questions and we can start figuring it out as a team.

Hi James,

What do you mean by 'we will have continue the music per screen'?

The music that is being created we set a number one background music per each screen then we will have a play list per screen that cycle though each one as they navigate the GUI of the game.

Thanks,
James Fleming

Received From Pvt Alexandre Freitas Game Programmer


Or I can just simplify it and keep it a single model for real and modify its surfaces and so on, and simply use water planes. The game engine itself should be able to handle physics anyway and as for being under or out of water its all about when it crosses the plane. In theory all I have to do is modify the same model and later on split it. Pros: Can do anything and depending in the model complexity can be as efficient as a height map. Cons: Map might end up using a lot more triangles for complex structures and colision calcs are more complex since you're breaking away totally from tile. Still, blender can be used reduce vertex count. Editing maps this way seems simplier, only trouble would be spliting the model into multiple models cuz u dont wanna draw the whole map every time but.. all together still much simplier than my first theory.
Moderate
4.16 Pvt Alexandre Freitas Game Programmer
1/4/2016 19:12
Just confirming, as of now I'm supposed not to have acess to source right?

Next I'm actually wondering, as for my task. 100% autogenerated terrain or create a terrain?

Reason I'm wondering that is because, even if I were to autogenerate it i'd do it serversided and only then send map structure to client or otherwise in a multiplayer situation not everyone would see the same map. The bad side from this is, a lot of data between server and client.

Meanwhile a static terrain can be stored client sided and all server has to do is request it to be loaded.

And theres still a 3rd way which would be dividing existing terrains into chunks and having server assign which chunks are posed where in a new terrain and by so generating a new map which would end up being a fuse of multiple stored maps.

Next, theres many ways of generating terrains, that being said, we'd probably want full control, so obviously you wouldn't want to do it automatically based in heights and so on. That being said I'm wondering a lot of things about this game engine here. Does it support multiple materials per mesh, does it automatically divide meshes in order to be able to render meshes with more materials than the graphic card can bind to, or automatically fuse materials and fix new coords. Thats what I'm searching as of now. Anyway apart from that theres also the fact we wouldn't want to generate whole terrain in a single mesh since that would mean rendering not visible assets, unless the engine already automatically splits and culls. At same time we don't wanna draw tile by tile or too many draw calls which was why I had these questions above, since as such we'd split terrain by chunks, but every chunk would still have multiple materials.


Next I have another question. Just wondering if the engine supports blending textures(cuz of terrain borders between materials such as streets and so on). If so, saves time, if not, im wondering, generate once with cpu(not as efficient memory wise, nor loading wise(ofc that could be solved by generating with gpu but the time it takes to upload, generate and read result would probably be the same), but after generating once and uploading into gpu no need to generate again meaning more efficient), or upload all the diff materials and generate it every frame with the gpu(much more efficient memory wise as all you need are the original materials, but less efficient gpu wise).

Finnaly, the kind of map we'd want. As you know a heightmap is really limited seeing as all we can do with it is a single plane and even so no stuff such as tunnels. A voxel map would solve that but... thats wasted perfomance, especially for clipping. The terrain would end up being pretty much a whole 3d model. Theres another way, a mix of the first. Multiple planes. One for floor, one for water(which intersects the floor one at some point. as for regions which go bellow water level, the water plane doesnt need to be all visible, plus can also change altitude and materials depending in position for lakes and stuff), and from there on repeat: bottom underground x plane, top underground x plane (where as first is inner side of walls of tunnels and so on, and outer is outer side of wall such as montain in case u have tunels inside) and x is the amt of tunnels which pass by the same place. This last way allows anything a voxel map would and at same time be quite efficient, meaning we'd be able to do any kind of structures(as for clipping, same logic as a heightmap but interlace the planes(idk how to explain but its not really hard to visualize)). In the other hand the method I just thought of has a limitation.

Hard part would be creating the map generator I guess. Height maps don't support vertical planes. Nothing that can be solved. Ah creating a map generator for this gonna be a huge pain (you could say in theory its a voxel map but.. efficient). Oh well, could it be that's what you want me to do?

Anyway I'm still not sure of what exactly you want so for now I'm researching on the game engine api to answer my questions. And if anything I just said doesn't make sense, just ask. I kinda created the whole theory as I wrote now.

Thanks,
Alex

@Alexandre For now we want to keep it simple the game engine comes with a sample terrain please review it and let us know what it would take in your opinion to create auto generated terrain.

For now we want to keep it simple yes it will probably be placed on the server side however we need to start working on this now as the GUI should be done here pretty soon and we will need a sandbox area to start creating the game functionality.

Thanks,
James Fleming

James, I am ready to test the upload. -Thanks!

@Robert Do you have time tonight @6PM CST?

Thanks,
James Fleming

After 19:00 CST works for me. Or anytime on the weekend.

What's the upload being tested guys?

@Sean Robert was having trouble uploading last sprint so we are going to troubleshoot that today.

@Robert Ok 1900 CST is fine I will get a meeting going and send out the invite for Team Viewer.

Thanks,
James Fleming

@Robert Sorry I submitted that request without changing the date to today.  I have edited for today so ignore the email you got saying the 8th.

1/5/2015 1900 CST

Thanks,
James Fleming

@James, Sounds good.

In my opinion, there is no need to over complicate maps. You can easily generate a simple height map, hand texture, modify terrain levels, and lay assets down to form the level. Basic physics are handled by the engine, and other physics properties that don't work can be changed at a later time before launch. Also if you leave the maps solely up to the server users will have to download maps as they play otherwise streaming maps to each player is pretty inefficient. Having the server chose to load the map and updating player locations is much more efficient.

Never mind. I actually thought for awhile with random I was requested to think of a way to make realistic computer made maps in real time. Now that I understood what you really mean't, then yes we can keep it simple since its a shooter game. From what I've seen Xenko doesn't have an implemented terrain maker(as for map editing once we place the terrain as an asset that's simple as placing object assets above and animating them, and doing the environment, such as lights, skyboxes,fogs and so on). As such that leaves two options. Create our own terrain maker(which why I asked that earlier) or use an available one. Honestly I suggest the second one as that would save us a lot of time. Lastly, indeed it's simple to implement a loader to heightmaps but, we wouldn't be able to preview with the game engine as the engine doesn't support loading heightmap, but in the other hand they support extensions and you can write your own compiler so indeed it should be possible to support heightmaps. Offtopic: Originally the reason I didn't understand what I was assigned to do is because it is already done as a sample which was the first thing I checked, plus it was really relative as there's many ways of randomly generating terrains and depending in implemented algorithms the results will drastically change but that itself wouldn't help the project if not related. In the end you have to decide between a prebaked model or a custom map format. Pros from the first: easier to load, no need to write compiler extension. Pros from second: easier to work with serversided to prevent hacking and easier to split maps and fuse different maps into a new one as a feature of our game if we were to want. One game which uses the first example that I'm aware of is final fantasy 14. A game that uses the second example would be Wow.

There is enough free terrain makers I'm sure we can find one to integrate into Xenko easily. After it's imported and set up in the game engine it will all be recompiled into other package files so it won't be easily accessible and then as far as server-side goes it will be easy enough to call the maps to load from server commands that it shouldn't matter what way we go there.

@Programmers The GDD does provide some guidance for maps:

Yeah, making a map to randomly instantiate object is easy enough, but seems like randomly generating a new map every time is pretty inefficient. Unless we use a similar idea to mine craft maps where it randomly generates a map by a seed, then have the server generate a seed and all user's clients generate a map based on seed. That way players can be in the same map/match as each other

@Programmer My original thought for this was to do some sort of BMP auto generation thing to get the height map first using something like this.  However I am unsure if this will work or not for the Game Engine but I figure it would be worth mentioning as a possible option.

Thanks,
James Fleming

My apologies, I've been sick as of late, I'll get to work on my agenda as soon as this boils over,

-Thanks

Since I still have a pending joint assignment for source control branching, I cannot grab other work. I did however complete more of the GUI elements to speed things up.

Double posted, sorry

@Anthony I have submitted the source control as approved.  I will make a code adjustment later so we dont have worry about that.

Thanks,
James Fleming

@James. Thanks. I will grab the scenes I accomplished and submit them all

@Programers Do we know what's up with 1091 / The Queue Screen? It's noted as completed, but it doesn't look completed. I try to check the history on it, but a change on 1/6 does not show up. VS15 says I have the newest version.  

@Nick Agenda 1109 from James, suggested we use specific branches of the code for our edits and James would combine them when it was all done. Agenda 1091, and the others I completed, were checked in under the Xray branch.

@Antony Okie dokie 

@Antony I kicked back 1091. Could you add button to go to the waiting screen? Everything else was approved. 

Thanks,
Nick

@Nick I modified the Queue screen as you suggested, Also modified the Leaderboard screen to match coding templates. The error was quite annoying while testing. I grabbed and completed that task as well.

@James
 In the Xray branch, I combined the Xenko sample for terrain into a scene and uploaded it working with navigation GUI. I don't know if Alexandre had completed it or not, but it randomly generates a new small terrain each time.

@Anthony OK I will review it as soon as the sprint ends today.

Thanks,
James Fleming

Indeed I verified the code in that example and made an even simplier version just for the sake of testing shader effects. Still, I didnt go further than that since I don't really know the level of control we want when generating our maps(such as the way we're texturing our terrains but I've also thought of a few ways). I've also been thinking further and.. honestly generating a simple terrain isn't a big deal but a realistic map is a different story, due to objects placement and key elements of the game. That being said,most game engines come with level editors and paradox being a new game engine doesn't have any terrain api implemented yet. Personally I'd choose to work in the game mechanisms itself and focus on the randomness factor later on. Better than writing code that will almost surely be implemented in the game engine at a later date.
Apart from that I've also spent some time learning the game engine(having had some issues with documents at first due to some packages having had their names changed since then) but overall I've gotten a better understanding of how the game engine works.

I'm unsure If I should upload it or not and if count these hours or not seeing as personally I don't feel that they contributed to the spring itself.

Still honestly I think for starting we should implement a static map. Not only is it easier to preview but it could also be used as a sample as for what exactly we want.

@Alexandre I have re-open your agenda back up for you to place your notes in the "Time Logger" area please fill this in with the time you spent researching this to come to this conclusion.  Adding these notes and anything else you would like to tribute to how you came to this opinion so we can review it and figure it out.  This allows the lead and myself to see what is going on and we could of address these topic before the sprint ended.  We are a team and communication even when disagreements take place need to be worked out.

In order for us to know what we want we need to start somewhere.  Creating a dynamic map was for that reason.  Other agenda will follow and we will continue to work on it until it is the way the GDD describes and it is automated.  It is one of the feature set by the design team to set our game apart from others.

The game engine might in deed come out with a terrain editor some day but that does not solve our problem of dynamic level generation.

I do agree we will end up with a "Sandbox" predefined level but that with the sample the engine provided already exist for us to test with when we start using models.  Their will be agendas when the time comes to create that area in matter that is organized and available to all members including design team but until we research that point we are stretching to solve for x when x is not even a problem yet.

Thanks,
James Fleming