Cross-Origin Resource Sharing (CORS)

The first step to getting the game hooked up was making sure that just the simple name/secret HTTP messages were being received and interpreted correctly.  We did this by creating a scene that loaded two models based on dummy unit data I created on the client.  After we had the super model parser working this part came together in just a few hours.

We pushed a few new versions up to Github and had our dummy scene up in no time.  The next step is where my end crapped out.  Zach's end works great though and he is currently de-optimizing the threading down to one thread for the all of the game logic.  Turns out when all you're doing is sending a few hundred coordinates you can run it all in the same place.  Hee hee.  We'll need them later though, we'll make sure of it.

Back to my end and the topic of this blog: Cross-Origin Resource Sharing  or CORS.

Official Mozilla documentation:
https://developer.mozilla.org/en-US/docs/HTTP/Access_control_CORS

Put simply, it's when the origin of the request is not the owner of the resource.  This happens whenever you have downloaded the content for a game and then log in to the server to have it feed the game logic.  You know, buy/download and install the game, play it online.  Tons of games do this; W.O.W., Neverwinter, The Sims, Planetary Annihilation, etc...

Our game will be browser based and will not require the client to contain any content.  Sites like Kongregate host these kinds of games but examples can be found all over the web.

I only bring up this point to illustrate the different functionality that web platforms require for development versus play.  While I may not need this exact functionality for this particular game.  It is a necessary tool in the web development kit of any good programmer so I'm going to add it properly instead of just hacking my browser permissions to allow cross-origin requests.   Which if you are a fellow designer reading this I would strongly suggest you do not do either!  You can look this up for yourself on stackoverflow.com if you don't believe me.  Yes, it's a little extra work, but you should know how to do this kind of stuff anyway so just learn it now and keep your computer safe during development.

I'm not 100% sure on the correctness of this information but from what I can gather from the above Mozilla link this seems to be exactly what I need to do.  I'll let you know if this works in the next few hours.
http://abdiassoftware.com/blog/2013/11/how-to-use-cross-origin-resource-sharing-cors-with-canvas/

Once I get this CORS issue worked out it's full steam ahead for iterative development.

Wish us luck. Thanks for reading,
-Clay

Connection Success & the Client!

So this is the companion post to the Connection Success post in the main thread.

To continue from the last post, I was trying to figure out how to parse my Collada super model.  This turned out to not be as big a pain as I had previously anticipated.  It did take both Zach and myself about 3 hours to figure out how to get everything working and rendering smoothly however.  I guess I'm finding that in the world of web dev that isn't such a bad turnaround time when you are stating from scratch.

The main issue was that I had exported the super model "wrong".  I had exported the lighting and camera, etc... a.k.a. the entire scene.  Which in turn, caused the lights and everything else to be stripped out of the sub models, making them render without their skins because there was no light in "their" scene, regardless of the world light I had in the Three JS game scene.   Another way to think about it is that there are two tiers of lighting;

Tier 1: the model lighting that needs to be baked into the model (and not accidentally imported WITH it)
Tier 2: the game scene lighting that lets the model show up in the game scene.

What this looks like;

No model light, No game scene light:    Pure blackness, your CSS will display but none of your WebGL will.
Yes model light, No game scene light:   Pure blackness, your CSS will display but none of your WebGL will.
No model light, Yes game scene light:   Models will display pitch black but will be visible in the game scene.
Yes model light, Yes game scene light:  This is what success looks like. Skinned models in the game scene.

Once we got all this sorted out and realized I had imported the lights, etc... as unit models, parsing the super model became much simpler and the kinks worked out nicely.  These problems all arise from the need to understand and be able to manipulate every aspect and parameter of the model meshes crashing with my learn-as-you-go style of game creation.  This style doesn't usually cause as much headache but the learning curve to understanding the entire 3D graphics pipeline is pretty steep and a pretty focal piece of the design process.

So, as my knowledge of the 3D rendering domain grows, our path towards a playable game becomes easier to traverse.  This knowledge will eventually even guarantee a better end product.  This is because I am researching and creating every step by hand (all two man game-dev is like this) instead of using off-the-shelf models from another artist.  Which is also the reason that rigging and animation is being pushed to the end.  If we wanted to use pre-animated models we could have a much prettier prototype but it's a skill I'm not willing to pass up on learning so it's taking us a bit longer.

I think that's enough for this post.  I'll cover CORS and cross-origin permissions in the next post.

Thanks for reading,
-Clay


Oh,  here are some INSPERATIONAL pics I downloaded from the web.

I DIDN'T MAKE ANY OF THESE.

They are just what I am basing my terrain designs on (To be shown and even finished...  later... just later).