Tuesday, February 21, 2017

Sanjay Balaji PPJ 2/7 - 2/21

The main focus for me over the past few weeks has been documentation. After our meetings with Salvage, he suggested that we put more focus on this since we were a bit behind in terms of documentation.

While we had worked on a GDD before, Salvage stated that one of the requirements for the CCI side was that we have a SRS (Software Requirements Specification) that lists out specific requirements instead of descriptive paragraphs the way they were in the GDD. The main benefit of having a document in SRS format is that when it comes time to test, we will have specific requirements to test against.

So most of my time was put into converting our GDD into a SRS. We had some feedback from Salvage and some changes were made so that the SRS could be of top quality.

Team PPJ 2/14 - 2/21

This week, there was a good amount of progress made visual-wise, though not without the requisite batch of hiccups. One team member (hint: it was me) brought to light a possible issue with the repo, which has the potential to set us back a couple days in order to sync everything up.

We made progress on the arena shell, the outside environment, and on the tools, while coding-wise a lot of tweaks are being made to the AI and to the new offhand tool, the ionizer. On the web side, we have a shiny new domain name (wetware.games) and our website has received a face-lift, with a new animated logo and improved blog support.

New VFX

New ball model WIP

Arena outer 1

Arena outer 2

Arena lights

Ionizer, rigged

Cyberpunk buildings

Gravity whip, rigged

Jumbotron

Logo iterations


Going forward, we'll continue iterating on our assets and code, while paying particularly close attention to the new ionizer and how it works.

Pros:
  • Lots of asset progress
  • AI only gets better with time
  • Reaching a point where refinements are more important than adding new mechanics/assets

Cons:
  • Aforementioned git issues
  • More progress on some assets while others are falling behind

Daniel Ingman 2/14 - 2/21

This week I spent time finishing UVs and beginning to texture the player's tools. Since the UV maps are a royal mess, I spent a bit of time making reference textures so I can easily add details to each area with minimal fuss. Due to this lovely mess I've made, I was set back a few days on making the materials for each tool. The textures are not yet at a state where I think they're presentable, but I'll show the reference texture for the main tool in the meantime.



Oh goodness


Going forward I'll have both textures completed with normal, spec, and emissive maps, so look forward to that.

Pros:
  • UVs for tools done
Cons:
  • UVs make children around the world sad
  • Set back a few days on making materials because of my professionalism
Hours spent: 16 hours +  meetings
  • UVs: 4 hours
  • Reference textures: 4 hours
  • Beginning textures: 6 hours
  • Troubleshooting issues: 2 hours

Cory Zicolella 2/14 - 2/21

This week I tackled the UVs of all of the environment models that I did in the weeks prior.  This includes the seats, the stadium light, and the triangular stadiums themselves.  These guys took me way far longer than expected because their default layout was so convoluted.  In the end, I eventually got them all to a workable state, which is always nice.

I was told that the model of the stadium itself, specifically the seating, needs to be tweaked so that the seats are smaller, giving the illusion of more onlookers. Along with that, theater seating would be a great addition to multiply the amount of people watching exponentially.  I will get on doing that, but it may alsso break the current UVs, which poses yet another issue -- but there is usually a creative solution.

The WIP I made this week is still rendering at the time of this post.  It took only around an hour and fifteen minutes to edit it, but the files were very large and thusly resulted in rendering times that were far larger than they had any business being.  That, and also nobody had access at the time to the widescreen build of the game (because that runs on an entirely separate install of the engine), so the footage we do have is super cropped to the square of footage that we were able to capture.

I would post the WIP here but it is still rendering, and UVs are relatively boring to look at.  But that was my week.

Monday, February 20, 2017

Cancelosi 2/14-2/21


This week I did a lot of work for the DIGM side of our game. First, I made an animated texture for the arena glass. I had some difficulty syncing it up correctly but it is now working fine. Some tweaking is left to find the perfect balance between distracting and good background motion



I also made a texture that has a parameter passed in that changes the location of a red circle. This is going to be used for the programmers to feed a target point for the AI to aim at. This will make it so you dont need a vive to work on the AI.

In the process of making the glass texture, I stumbled upon a cool texture for the ball VFX that I integrated pretty quickly.



I'm currently working on a a remodel of the ball. Should be done soon and textured by the end of the week.



Time Spent : 20? hours
Pros: Got a lot of work done on the art side
Cons: No AI improvement


Andrew DiNunzio PPJ 2/14 - 2/20

This week I spent a lot of time trying to learn how we could get our AI to "learn" how to use the gravity whip to swing the ball. I sent a Udemy instructor who teaches machine classes an email describing our problem and asked for his thoughts. He said that it "definitely sounds like a Reinforcement Learning problem". So with this going from likely unfeasible to somewhat feasible, I decided to dive into it to try to make it happen.

-------------------------- Describing my RL studying below --------------------------

I enrolled in a class on Reinforcement Learning on Udemy, and I started working my way through that. So far, I've learned about the basics of RL and Markov Decision Processes. I started learning about the Bellman Equation, which describes how to find the value function.

I learned that there are a few ways to solve MDPs, and there are typically two steps to finding the optimal policy.
1) policy evaluation
2) policy improvement
The former being responsible for updating the value function given an updated policy, and the latter being responsible for updating the policy by choosing the action that results in the best (greedy) value of the next state. You can go back and forth between these two things until they converge, and you'll have an optimal policy with up to date value function. Actually, these steps can be combined in something called "value iteration"

I studied Dynamic Programming, which was interesting, but it requires having the full model including knowing p(a|s) and p(s',r | s,a) for all states. I learned that DP makes use of "bootstrapping", which allows you to use the previous value of the value function to update it, instead of having to wait for the end of an episode.

I then looked ahead a bit and considered Monte Carlo as a solution to the problem, which is better than DP because it doesn't require having a full model ahead of time (it actually learns from experience). This solution however is not fully online, since you have to wait until the end of an episode to make use of the average returns.

Then I looked into the idea of Temporal Difference (TD) Learning, which combines the good parts of DP and Monte Carlo, in that it is fully online, but still learns from experience.

All of these still require "storing" the value function somehow, which I've been using a dictionary for, mapping states to values (or states and actions to values if using the action-value function Q).

I learned about approximation methods to avoid having to maintain this massive dictionary (while at the same time avoiding having to collect data about every possible scenario) and how you can actually just use linear regression, neural nets, or deep neural nets to approximate the value function.

I learned that the two common value functions are V and Q. V maps state to value, and Q maps state-action pairs to values.

Q has an advantage in that you don't need to know how to "look ahead" (which isn't possible to do for our game), but it has the disadvantage in that it needs many samples in order to learn.

Lastly, I took a glimpse at Q Learning, which is an "off-policy" method of policy optimization. Apparently approximation methods are not very effective for things like this though, but later I'll see how Deep Q Learning can solve it.



This is all prerequisite stuff for the next Udemy course I'll be taking. Right now, I'm at the point where I assume I can hold info for the entire state space, which isn't really feasible. Also, I haven't done anything continuous yet (only discrete).

The next course I'll be taking will demonstrate how to solve the inverted pendulum problem with RL (I think it will make use of TensorFlow or Theano), which will be extremely helpful for our purposes, since that will cover things like continuous (infinite) action spaces among other things.

If it is possible to solve our problem this way, we'd probably need a way to get our program to interface with Python, which I think is doable. This could also have a really neat side effect of letting people code up their own AI if they want to.


I'm still not sure if things will work out, so I still plan on working on the AI as before.
------------------------------------------------------------------------------

I also worked on getting the AI to use two splines now instead of 1, depending on where the ball is coming from (left/right).

Finally, I spent time to get the gravity wells to be "ionizable", which would throw the ball towards the enemy's goal when ionized. These forces would be stronger the more "charge" they have.



Time spent: Total: ~30 hours

  • 20 hours - RL studies
  • 5 hours - Allowing gravity wells to be ionized
  • 5 hours - Get AI to swing both ways horizontally


Pros:
  • I'm learning about reinforcement learning, which is exciting. And this project would be a great application for it.
  • Gravity well ionization works decently well, with some minor future tweaks.
Cons:
  • Gravity wells need some tweaking, since it looks strange throwing the ball at the inside of the gravity well and having a "boucing off" effect towards the goal.
  • There isn't really enough time between studying RL and working on the project, so I feel like I have to commit to one of them and not both

Tyler Schacht PPJ 2/14 - 2/20

This week I spent my time working on the game logo and its different versions.  Mike Cancelosi originally started vectorizing the logo, and Dan created the original concept, but I picked up from them.  Most of my time that I spent on the logo was trying to get it animated on the website.  Unfortunately, Clipping Masks do not work the way I hoped they would.
I also added in a "better" blogger integration.. It is super poorly optimized, but the full blog is now on the same page as the website.
I also filled out some forms for a few different things.


Total Hours: 14 hours
- Logo:
+ Vectorizing Main: 4 hours
+ Animating Main: 5 hours
+ Designing Square form: 3 hours
- Forms: 2 hours

Positives: I think the logo looks really nice.  I tried to keep the logo readable at most sizes without losing the readability.  Also to save us a bit of effort, the logo was made to be strictly black and white to avoid color issues later down the line.

Negatives: I spent WAY too much time trying to get clipping masks to work the way I wanted them to.  I spent so much time trying to get the logo to not have a background and be able to be animated, but it didn't work out that way.

Ryan Badurina PPJ: 2/14 - 2/21

This week, after 2-3 weeks, I "finally" imported the various assets and tools into UE4.  The buildings you saw posted over the past 2 weeks finally have the modular texture I created.  This is what it looks like in-engine.


The texture was designed to so it wouldn't make the buildings prominent in the environment, as they are mostly set-pieces meant to help define the background of the arena.  The player is not meant to see them in detail, especially with the glass arena.

I also finally started work on rigging and animating the Whip Tool.  This took around the same amount of time to rig and animate as the Ionizer, if longer, due to the way the prongs work.

The divided pieces of the mesh that I would focus on animating.


The skeleton of the whip tool.  Paint weighting this took a bit longer because of the way the prongs move alongside the wires connected alongside it.


While I am not able to show animations currently on my PPJs, I can show you clips of the animations to show how we are envisioning the look and feel of the tool.


Outside of one animation for the whip tool that still needs some work, the rest of the clips are, for the most part, done.  I want to finish the animations before I properly put them into the engine.

Now, importing the building models was easy, as well as applying the material to them.  It was importing the animations that led to some problems that I needed to look at.  UE4 doesn't have a build in Animation Clip Editor, so I had to divide the animation clips separately within Maya and then import them all with the same skeleton as the Skeletal Mesh (Tool Mesh and Tool Skeleton).  Good news is, Maya has a build-in game-exporter for Animation Clips, so I divided the animations into separate FBX files, imported them, and made sure they worked.  Good results.


The red lines on the middle and bottom timelines is the frame tick that the animation is on.  While I am unable to show actual GIF animations, I can show you the progress and that everything is working.  With this knowledge, I hope to import the Whip Tool and Animations much more easily in the future.


Time:
  -Weekday Meeting(s): 1 Hour
  -Weekend Development Session: 6 Hours
  -Building Material:  1 Hours
  -Whip / Main Tool Rig:  2 Hour
  -Whip / Main Tool Animations:  6 Hours
  -Asset Importing to Unreal: 3 Hours
Total Time: 19 Hours

Pros:
  -Finally imported most of the assets from previous weeks into UE4.
  -Animations for the Whip Tool are, for the most part outside of some refinement for the ChargeHold animation sequence, are complete.

Cons:
  -Importing animations into Unreal is a little finnicky.  Unlike Unity which allows the user to divide a whole file into separate animation clips, UE4 doesn't have that ability, so I need to divide the clips separately in Maya.  That kind of set me back a little as I tried to work around it and prepare for creating the animation states inside UE4.