New phone OS and group help Post #6

As I stated in the main thread, the Parts & Portals group and myself will be joining forces to help each other get over our creative blocks this next week.  Jaron has quite a lot of HTML/CSS experience and all of my research into cross-platform game engines has actually made me fairly proficient at parsing engine code.  There is also the added bonus that their group is using Java and I love coding in Java.  It felt great to work with Daniel and just dive into trouble shooting on a new (to me) project.  I actually didn't realize how much I missed coding in Java until we started working on their game engine yesterday.  It really is a fun language to work in.

So back to my phone and feasibility of playing our RTS on it.  It doesn't look good.

I got everything working just fine after upgrading my OS to Jellybean 4.3.  This enabled WebGL and a few other cool developer features on my phone.  While the GPU isn't quite buff enough to handle even simple WebGL it was still really cool to play with the models from this site:

http://www.ibiblio.org/e-notes/webgl/webgl.htm

That being said.  I'm not entirely sure it's my GPU that can't handle it and not my internet connection, so more testing is needed to be sure.  That testing will just have to wait though.  For now, it's enough to know that it will take optimization of some sort to get 3D graphics to work on a phone so we will put that off to the side.  We didn't have phone design in mind when we started the project but I do think it's academically important to understand what it would take to have a WebGL based in-browser smart phone game.

I wish I could talk more articulately about the CSS/mouse event errors I'm getting in my HUD but I really don't know why the functionality is spastic.  There are a few factors that are involved;  the z-index and the functions controlling them, deprecated "prevent default action" code in the tutorial and the 2D canvas element "in front" of the HUD.

It's one of those problems where everything looks just like the examples in the book so I think the book must have a tiny typo.  I have run across several syntax errors in this book when the code spans pages so I at least know where to start hunting.  Overall the book is quite good for programmers familiar with HTML and CSS already.  It has been a good read so far and the first game example "Angry Fruit" was easy to follow.

Pro HTML5 Games: By Aditya Ravi Shankar
http://www.apress.com/9781430247104

Oh, and my terrain map isn't displaying either -even though the web console is showing that the asset was loaded correctly.  This is regular asset loader troubles though and shouldn't be a problem once I track down the missing/broken loader code.

So with the roadblocks over the past couple weeks and losing our 3rd and 4th team members part-way through last quarter it will be necessary for me to update our timeline to fit our reduced crew size.  I definitely planned this project out for a 4 person team and have had to spend far too much of my development time scaling back our model to fit our dwindling manpower.

I'm off to update our timeline now.

Thanks for reading,
-Clay

Recap for Spring: Elm, two clients, and my damn phone

As I mentioned in the main thread, we have realized the end of the school year is closing in faster than anticipated and we need to get this project in a playable format.

What that means.  It means Zach is going to spend the weekend whipping out a crude, top-down, touch reactive client in Elm (a new functional reactive programming language,  http://elm-lang.org/).  It also means we spent the better part of last night on Skype trying to get my phone to run his Elm code from our ftp server.  No luck.

After a few sessions of trial and error we figured out that I could download an ftp client (I used AndFTP by Lysesoft), download his source as a ZIP and unpack it (I used AndroZip by AVG Labs) then run it with my phone's native HTML viewer. BTW my phone is a Galaxy S2.

Everything seemed to work great until the HTML viewer kept only displaying a blank screen.  It did give me the ability to scroll the blank nothingness though so that gave us hope we could debug it and move forward.  So I plugged my phone into my computer and tried to use Chrome's remote debugging features but my computer won't recognize my phone (even for downloading photos) so we were once again stopped by web tech.  ugh...

SIDE NOTE:  a few days ago I even had to turn my WebGL capability ON for Chrome on Ubuntu.  That took me a minute to figure out.

So, the next step is to download the Android SDK  (done) and try and use ADB, the official Android debugger to get this working.  My hope is that we will be able to use the SDKs legacy drivers to get my computer to recognize my phone.  If that doesn't work, we'll have to ditch phone compatibility entirely for now.

If all of this comes together we will be able to have players download a couple simple apps (FTP client and Unzip), download our game, and play it.  All without going through the normal distribution channels.  We think it would be really fun to get a game out there under the radar just to see what kind of community would get involved.

Once we get the debugger working through my phone we can start troubleshooting why the "map" didn't display when we viewed the html page.  Until then we are at a standstill for the phone and will just continue with the regular desktop browser version as scheduled.


But on the progress side, Zach should have an Elm client up and running by mid-week-ish and so we'll be able to start prototyping game mechanics pretty soon.  This will pull my time away from the JS client a bit but we'd still really like to not think of the JS side as scrapped, I just need to build the next version from the ground up.  Really not a big deal, it's just my first implementation was very much a "get it done version" and is consequently gruesome to debug.  It doesn't follow proper best practice encapsulation guidelines, even for JS.  Pretty bad I know.  Things are being initialized all over the damn place.  I gotta wrangle all that in and  classify everything so you can chase down the JS console errors better.

So, that's where our spring quarter is starting.

Wish luck and thanks for reading,
Clay Francisco

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).

Model Loader Success

This past week (on thurs?) I finally got the ThreeJS Collada model loader to work.  Not that Mr Doob's model loader is hard to use, I'm just a newbie who had a hard time with a couple things.

First; deciding whether to use the JSON or Collada formats.  JSON is the preferred format of ThreeJS programmers importing Blender models, however, Collada is the default (nicely supported) Blender exporter so... I decided to with Collada because I'm an artist at heart.

Second; learning how to "bake/pack" my textures properly in Blender BEFORE exporting to ThreeJS.

Part two had been giving me no small amount of difficulty getting the texture maps to export to ThreeJS with the models.  The model part of the loader worked from the word "go" but the textures had eluded me for several weeks.

Sidenote:  the cool thing about the JSON format is that it turns your model into a .js file that you can open and manipulate vertices, animations, etc...   which has it's obvious advantages.

So with the models now in the game and dressed for success I am putting animation on the back burner.

I have a new set of issues to work through around the fact that the Collada loader seems to have difficulty loading several files.  The ColladaLoader object itself apparently only wants to load 1 super model (pun intended) that is then parsed into a "model array" (or insert your favorite data structure here).  Stack overflow has several great parser snippets with interesting work arounds for partitioning this super model DAE object.

Once I get a handle on parsing the super model it's a fairly simple matter to manipulate the individual models in 3D space with ThreeJS.

Oh, I also got the screen-panning working (standard to every RTS) with only a few kinks that are Javascript specific.  For instance, the keyboard input won't work until you "mouse click" in the canvas/browser window.  This confused me for about 10 solid minutes until trial and error eventually prevailed.

Aside from minor issues like that panning and such this week has been very successful.

Finally I also got some REALLY basic picking working which should help pave the way for getting the marquee selection working (standard group/area select for RTS).

To wrap up;  this past week I created the foundations for the screen movement, mouse picking/selecting, and asset loading.

With Zach's success in getting rudimentary message passing working we are now one step closer to piping our model and view/controller together.

Thanks for reading,
Clay Francisco

Starting out with Javascript - "It's single threaded?"

This post is about the Javascript "game-loop" and passive event handling for game-state updates v.s. the traditional game-loop.

Ok, so lets get the things we know out of the way.

1) Games depend on hundreds/thousands of logical computations per second.
    Because we want games that are more and more realistic.  Or at the very least,
    feature rich.

2) Multiple threads help the CPU process information in parallel; faster.
    For instance; game logic that isn't UI dependent (like flying birds and grass
    animations) can be farmed out to separate threads.  These UI independent
    threads can update game-state whenever we want them to.

    It is kind of confusing to refer to these kind of updates as game-state though.
    If it doesn't affect player experience AT ALL (if it is purely visual), is it really game-state?
    I say "No" it is not.  It is "environment" state.  This kind of state should be kept separate
    from game logic for many reasons.  My favorite is it allows us to replace the entire environment
    outright.  Go modularity!  

    We must now remember that Javascript is NOT multi-threaded so we are cut off from this
    optimization.

3) Games need a Game-loop:
    ( Take Input -> Update Game-state -> Draw New Game-state)

     
        a) Take Input:

                   We have event handlers that listen for user input.  

                   These event handlers place update requests in an event queue.
                   Normally the updateGameState() loop "pops" this event queue
                   every time it fires off.  In javascript however, this is where we have a
                   second tier of listeners that make calls to requestAnimationFrame().

     
        b) Update Game-state:

                 Update functions validate user requests and execute appropriate state changes.

             **Hopefully I can explain this right...
               
                 In a traditional game loop you have a draw method that is called around, lets
                 say, 60fps and a logic update method that is called around 30x per sec.
                 The draw method will have some kind of smoothing effect like LERPing or
                 tweening to keep the animation from looking like a clock tick.

                 In our Scrounge World Model the logic engine's update is only called 10x per sec.
                 Which means we do 6 frames of smoothing per logical update.
             
                 **Remember:
                 Javascript isn't multi-threaded so we can't have this kind of "forced" update
                 loop.  This is partly because HTML doesn't support state-fulness.

                 I have to make you look up HTMLs state-less nature on your own as I am no
                 protocol expert.  However I can explain how this affects us and how we create our
                 Javascript equivalent.

                 The big difference in a Javascript game-loop is our updateGameState() method is
                 no longer a naive loop.  Instead we have a super EventListener() method that
                 passively listens for changes to game-state.

                 What this looks like on the outside:
                         function gameLoop(){
                                 updateGameState();
                                 drawNewGameState();
                                 requestAnimationFrame(gameLoop);
                         }
                         //get things started by calling the function
                         requestAnimationFrame(gameLoop);

                Which frankly isn't that far off from the traditional structure.
                But with two main differences:
                    1- the updateGameState method is passive     ...and...                  
                    2- requestAnimationFrame is in control of the game loop

                What this looks like on the inside:
                        function updateGameState(){
                                //updateGameState() just wraps all of the eventListeners for UI.
                             
                                mouseEventListeners();  //onclick, mouse over, etc.. would be wrapped in here
                                keyboardEventListeners();  //keypressed, keyup, keydown, etc...
                       }
               
                **Note: There is some "preventDefault()" method that has to be called within the
                              individual event listeners in order to prevent the regular browser functionality
                              from firing off that I don't really understand how to use yet.
                              Mainly, I need to figure out how to use the right mouse button and suppress
                              it's default function.

                If you know how to use Javascript DOM event listeners then handling UI should be
                fairly straight forward.

          c) Draw New Game-state:
                    Render the updated game-state to the screen.

                    The draw method is a wrapper method that resides within the game-loop and 

                    calls every game entity's own draw method for the given update type.  

                 
                    i.e.  The event handler X() fires off logic method BadguyOnCollision() which
                           will queue two methods when triggered:
                           whoDidIHit() and damageWhoIHit()  (or perhaps just itself but whatever). 

                           We "pop" the event queue as discussed previously and perform update.
                         
                           whoDidIHit() searches the entity tree to find the entities involved in the
                           collision and damageWhoIHit() performs the entity damage logic (my AC v.s.
                           your THAC0 anybody?) and updates the appropriate entity's life totals (the game-
                           state).

                          damageWhoIHit() calls the appropriate damage animations for the entities and
                          then requestAnimationFrame() decides when to render them to the screen.
                         

Hopefully this all made sense as it is still fresh and squishy in my own mind.  As these ideas start to solidify I may come back to these posts and clean them up and expand them if time permits.

Thanks for reading,
-Clay Francisco
                       

Splitting up the blog

We decided it would be best if Zach and I each started reporting on our technical progression and not just outline the overall progress of the game.

I will still be keeping up on the overview updates in the Home thread but it has come to our attention people may be interested in the more nitty gritty details of the work we are doing.   This was of course the original intent of the blog but time and details slipped through my fingers and it became a snap shot of progress, not a catalog of experiences with implementations.

So the blog has been split into the three logical components.
    - Overview / Home (non-technical)
    - Model (Haskell language implementation details)
    - View and Controller (Javascript language implementation details)

That's pretty much it.  Hopefully you'll get the implementation details I know you're craving in the Javascript and Haskell threads and that we can keep you up to date with our overall progress in the Home thread.

Thanks for your continued reading.