First time posting, try not to say anything stupid...
My name is Tyler Camp (aka GZ), and I'm the guy who developed the demo that was just recently released. Of course, it wasn't all my work, Allen, Mike (K), and I all contributed to the engine that is currently being used. But the important piece is the time frame in which the demo was developed:
Connor came to me about 3 days before his presentation stating that he was rushing to get his final pieces put together. I didn't know that the show was that Friday, but I offered to get a basic demo out for him.
Making the player class: 1 hour
Making the box class: 2 hours (with fiddling, I had to mess around with the physics mask to make it fit all of the sprites that were different sizes [Thanks Cameron])
Making the buttons: 1 hour
Adding strict line-drawing: 1 hour
Adding free-form line drawing: 1 hour
Adding views (and applying): 20 minutes
Swapping out player physics: 2 hours
Adding shadows: 30 minutes
Adding line/box clearing: 1 minute
If I went right through and made all of the underlying changes that I had ended up with, it would've taken me a total of about 5 hours of coding to make that demo. But, like with all games, I took my time adjusting the rotation and scaling rate of the buttons, the distance between line separations when in free-form, how much the shadows scaled based on the object's height, etc. Fortunately, even without a GUI to assist in creating the demo (we don't have a game editor, just a coding library), it took about as long as it probably would have if I was using Game Maker.
So, on to the actual point of this topic: What we're going to be doing now that this demo has been out.
Now that we have the physics and basic game project management mechanics completed, we have to focus on continuing with our GUI engine and creating a networking test bed for our online libraries. The GUI engine currently only has tabs, buttons, and text boxes, but it provides the basis of what we need to develop more components for an interface without too much of a hassle (and it also got me a 100 in my programming class, but who cares about that).
As for the networking testbed, we're developing it so that we can assure that any problems that arise will be a result of poor programming on the game development side, and not deriving from an inefficiency from the networking manager. Allen was put in charge of the networking piece of the engine when we had gotten to it, and unfortunately we all rushed to get a game out to test how well it did. We knew it worked, but we didn't know if it did what we wanted it to. Unfortunately, there was an IMMENSE amount of lag in that demo, and many of the game mechanics didn't work anyways. With the networking testbed we'll be able to focus on just the online piece of our engine and track the speed of each stage within our TCP message handling.
Fortunately, we'll be putting our GUI engine to work in that test bed since we've been getting tired of CLIs, so this should help us know whether or not my work will end up being usable.
So to sum it up, we'll be working on the GUI engine so that we can build a place to test how well we handle networking. One step at a time.