Changing the Blog Structure Post #9

So you may have noticed that this Blog has grown a few new threads.  This is because this main game thread didn't have the technical info that I originally wanted to be here.

This thread will remain the overview thread it has become and we have shipped the more technical stuff the the model and view/controller threads.

So back to the good stuff.  With the model loader now working correctly I can move on to the more critical "slave" logic for unit movement/animation control.  We are starting with just basic ID, (x,y,z), and facing direction info to show input handling from the model (via the server).

Zach has a little more "glue code" to write for the binary format parser (on the client side) before we can actually hook up our server and client but we are only one layer away from connection so we are both pretty excited to get some models moving with server commands.

Here is a screenshot of my models loaded up with their textures.

Thanks for reading,
Clay Francisco.

Progress Recap Post #8

This post will be a progress reports of sorts.  Really it will just be a signpost for us to catalog where we are at this point in time but even more so, an overview of how we got here.

Initial Concept: Summer 2013
  - Insane brainstorming about the coolest cross-genre experience ever.

Solid Concept:  Fall 2013
  - An RTS style combat sim in an RPG setting.
  - Main cross-genre components ->
            - Players recruit a "party" (a la RPGs) instead of
              building an army (par usual RTSs).
            - Units are initially NPCs; distinct characters that can
              be equipped, have unique "level" or XP,
              and are found in towns and villages.
            - In game items will be like RPG items
              (they can be scrapped for coin, traded, etc...)
            - A sim environment:  flora and fauna with
              aggressive and passive behaviors.

            - All other game aspects will be taken from the RTS genre.

Leads to:
  - Research on cross-platform gaming options.

 - Side problem *
             - Figure out a UI that makes it so RTSs on a tablet aren't so simplistic.
                i.e.  make the tablet RTS experience closer to the desktop experience.

             - Goal -  achieve 80-90% of the desktop functionality (hotkeys, control groups, etc...)

               (may have a good handle on this problem...  need time to experiment)

Cross-platform Options:     
Browser or Java (or port it to all the platforms!!!   yea right)

  - Java:  A great option.  The main reason we didn't go with this option was
              because of the nature of the 3D engine we wanted to use for it.
              There were several other options for lower-level frameworks that
              we decided to pass on for various reasons that are preferential
              not technical.

              In the end we decided we didn't want users to have to download
              our game.  Browser it is.

  - Javascript:  The option we went with.  Because; WebGL.
                       It just looks so cool. Additionally there is a lot of great
                       documentation out there for Javascript frameworks (I think it's)
                       because it has such a quick iteration time.

Implementation:  CURRENT
                              February 2014 
  Toolset:
  - 3D framework: Three JS
  - (Possible) workflow tools: Yoman, Node.js, Require.js, Backbone.js
  - IDE: Sublime Text 2
  - Development Browser:  Chrome

  - Books:  WebGL Up and Running; Tony Parisi,
                 Pro HTML5 Games; Aditva Ravi Shankar,
                 Learning HTML Game Programming; James L. Williams

  Game Framework:
  - Client-Server model with MVC components

  - Server: Haskell, because it has great concurrency control.  This should
    allow us to farm out the game logic to the host, which will free up the
    client to only work on the graphics.  This is a concern because of Javascript's
    single threaded nature.

 - Client:  Javascript, it's a great way to get our game out to as many people
    as possible AND it gives us a game with which we can test our ideas
    about a better RTS interface for tablets.  Javascript has great touch/swipe
    libraries.

  Tasks at Hand:
  - Finish UI mockup
  - Get textures packed into models for importing
  - Finish custom binary communication protocol (this should save us
    TONS of bandwidth allowing us to really push the amount of data we
     send about gamestate)
  - Complete the initial scene (models loaded and responding to picking events)

  Tasks Completed:
  - Basic models: male, female, weapons, armor, a few buildings and 3 vehicles
  - Worked through Three JS tutorials up through model loading.
     Networking portion will be next
  - Empty logic framework for server


PS:  Here's just another screen shot to show how the models are coming along

Timeline Post #7

In the interest of greater academic rigor; here is our rough timeline for the game.

Scrounge World time line:

as of 02-11-14:

week 1.6

-start the binary parser for the clientside (data unpacking).

-getting models loaded with their associated textures.

week 1.7

-finish GameObject class and first level of subclasses (NPCs, Units, Buildings, etc...).

week 1.8

-finish UI “mockup” that will have basic mouseclick event handling.

week 1.9

-have basic scene set up with dynamic entity spawning.

week 1.10

-have basic functionality for server/client message passing.

-experiment with rigging over the break to see how hard getting animations to

work will be

week 2.1

-demonstrate Unit behaviours and “ownership”.

week 2.2

-more unit behaviour (sim-animals / bandits)

week 2.3

-more unit behaviour

week 2.4

-Units need to have basic behaviours by now (i.e. auto attacking, healing, etc...).

week 2.5

-vehicles as ITEMS not as units.

week 2.6

week 2.7

-be done with our SAP so we can implement some of our stretch goals

week 2.8

-tech-tree,

week 2.9

-procedural terrain generation

week 2.10

-Play it!

Vehicles and Mounts!!! Post #6.2

With the idea of modular units I'm trying to create some models that will reflect the blending of the Mutant and Human tech paths.  These are my first attempts.

WEAPONS!!! Post #6.1

Weapons!!!!  Yay!!!

Low poly assets are coming along.

Armor!!!!

Back to the 3D. "Who you callin' chicken?" Post #6

Zach spent this last week creating an alliance system for the game.  All RTSs need a way to deal with multi-person teams; how resources and units are shared among teammates.  We've been leaning towards less control of your team's resources and equipment for a more "free trade" kind of mechanic.  As in you can "pass" units and resources to people on your team but couldn't use their stuff unless/until they GAVE you control.  No take backs though, that's just too hard.

I have been working on getting some 3D models sketched out because my teammates like to watch me suffer (not that 3D isn't the best)... Hao ;P

So we are plowing ahead with 3D even if it kills us.
Below is a preview of the low-poly male and female we will be using for our default NPCs.

The male was the character I started with because I wanted him to be the "base" size.  I then "shaved down" the model to get the female to match the basic shape.
 

I also had to give the female some kind of distinguishing marker because there body types were so similar from far away.  Of course they need to be if we are going to use the same models for weapons and armor.  

I had some difficulty trying to model a female that was the same height and width as the male while still looking feminine.  I also didn't want the female to be super thin and weak looking on the other hand because the NPCs will be a 50-50 mix with NO difference in their "stats" (they have identical data members and functions).  I guess the clearest way to say this is the server logic doesn't know about gender.  It's just something we do on the client because I think it's cool to have randomly gendered units. 

   

Hopefully I'll be able to pull it off.  The proof will be in the pudding I guess.  

Anyway, I hope the ponytail isn't too silly but I couldn't think of anything else. 

Right now they aren't rigged and don't have any textures but I'm going to build some weapons, armor and a couple other assets before I get to that stage.  I think we will be able to use the "naked" models as place holders and ramp up the detail (animations and textures) as the game starts coming together.

This would be do to the "emptiness" of our framework.  Since we have to code all the functionality we want to have as a "mod" anyway, we can create a minimal movement/behavior model for our game and then add animation functionality etc... as needed.  The reason we designed it this way was to give us the ability to abandon graphics after the SAP stage in order to focus on NPC AI behavior.  Which is what we all think will be the fun part.

Thanks far reading,  more pics to come soon.

-Clay Francisco