Scrounge World Game Project
Clay Francisco & Zach Kamerling
Code Repository
https://github.com/RTS2013/RTS
PDF Version of this doc on Google drive
https://drive.google.com/file/d/0B1FaaEchU94YQ2NqS045dGZPUzQ/edit?usp=sharing
Scrounge World is a browser-based real-time strategy game coded in JavaScript and Haskell. Our main project goal was to design an RTS for mobile devices that plays like a full sized desktop application.
Our project examines the why and how of bringing the RTS genre to the mobile market.
Why we want to achieve this:
Mobile games are a huge part of today's gaming market and yet are still missing a catalog of strategically rich RTS games. I must note here that turn-based strategy games have been successful on mobile devices and the recent port of X-COMM to Android proves a market for turn-based strategy games does indeed exist in the mobile arena. This, combined with the obvious success of RTS games on desktop machines makes us certain that the need for this type of game exists.
We have set before ourselves the challenge of designing a game that distills the complexity of a full keyboard worth of hotkeys down to a 3-button, touch screen interface.
This project has several learning components, not the least of which is simply designing and testing the UI. Next, it will be necessary to construct a game that squeezes impressive battle scenes onto the reduced screen real estate.
How we plan to achieve this:
While simple to explain, implementation is proving to be quite the endeavor. The how of completing this kind of project is really a “cross that bridge when I get to it” sort of experience. When loading 3D assets for example; You can't simply use the JSON model loader provided with your given engine. You must consider the entire number of onscreen assets supported by your internet connection for each different format, JSON, Collada, OBJ, etc... and average the supported number of polygons by the number of individual units on the screen at any one time.
Without a wealth of industry experience to draw on, the new designer must trudge forward on his own discovering the boundaries of the current technology. Or we could have just done 2D from the start because the foundation of 2D programming hasn't changed in 20 years whereas the 3D browser environment is changing on a daily basis.
What the heck are we talking about anyway?
Real-Time Strategy (RTS) games are a genre of war game where players each control their own army. Game “pieces” are divided
<RTS run down>
Tower Defense (TD) games are a specialized version of the RTS core mechanics system.
The essential components of the TD are:
- Single Player: Games consist of waves of progressively stronger, faster and trickier units that
take predefined pathways towards your home base. Once your home base is drained of life,
you lose.
- Snap-to Grid. The map is always some expression of a standard grid separated by paths
leading to “the base”. The player may never place units in these pathways. They remain
clear for the enemy hordes to stream down. Your units are sized to be varying multiples of
this grid system. Placing units is the main strategy component of TDs.
- Immobile Units. Once placed, TD units are glued to their position and are only (and not
always) removable through recycling for scrap. Once recycled, a small “after-market” amount
is added to your resource pool and the square is now open for replacement.
- Economy: TDs don't have a classic harvesting based resource system. Instead, players earn
resources by killing enemy units. Resources are then spent on new weapons and upgrades.
- Strategy: The goal is always to protect your base by placing units who have the correct range
and rate of fire around the correct pathway or lane. This is a greatly simplified explanation
and games like Savage Moon for the PS3 prove that you can have engaging strategy with only a gamepads worth of buttons (and despite the horrible cursor control of the analog stick).
Too many Tower Defense games! But why?
We really aren't sure why game companies haven't tackled the problem of mobile RTS games but there are a few obstacles that become immediately apparent to any game designer.
1) limited AI capability for single player. 2) limited UI capabilities. The RTS genre relies heavily on complex hotkey setups. 3) limited/lo-fi assets do to decreased RAM size. This is another point RTS games tend to not to deviate from. Players have gotten used to to having dozens of available units with several available upgrades and customizations. Do to the visual scale of RTS games units require very distinct art assets to be distinguished from one another.
Obstacle 1: AI on a tablet.
People are spoiled. AIs nowadays are awesome. They often adhere strictly to the rules of the game and are truly an analog (if a poor one) for playing against a human opponent. It wasn't always like this.
In the early RTS days, most of your game AIs were pretty rudimentary. Many AIs were simply hard coded enemy factories that only spewed units at you. As you progressed through the levels the enemy factory would simply go into over-drive and the mayhem would ensue. Eventually people caught on and weren't very happy with the situation. Apparently they didn't like that their enemy could “cheat” –never mind the fact it can't think-- and the game companies obliged as technology allowed. Which brings to our current day audience who expect a more complex play experience than gamers of old.
It wouldn't be unreasonable to assume that one of the reasons game companies are hesitant to tackle the transition to mobile is because the AI constraints for single player mode might not be received well by the younger audience of gamers. We are pretty sure this is why game companies have stuck to the TD genre. It thematically allows the AI to no longer have to consider economy or terrain-based combat. Which is HUGE!
Obstacle 2: UI on a tablet.
This part just took sitting down and playing with an iPad to see what felt comfortable and what reasonably fit on the screen. Once that was accomplished (which was quite easy because much of this research was done for us) it was now a matter of sticking to the layout we had during game creation.
Which is actually an incredible difficult task but we did manage to design a fairly robust layout that should allow for 70-80% of the functionality provided by hotkeys.
<PIC>
Obstacle 3: Assets on a tablet (and cross-platform compatibility).
Frankly this part has been a huge struggle. Figuring out what kind of 3D assets you can cram into the RAM of a mobile device is a real pain. After literally months of struggling with trying to scale down 3D model implementations and loaders I came to the conclusion that the only real way to get 3D assets into a browser game is to write your own model parser so that you can trim it down to only the most critical model data for your implementation. I am not ready to write our own model parser just yet so 2D is really the only option left.
Although creating your own ultra-light model parser would be nothing for a AAA production company.
Where the project is now:
Client:
Really basic 2D UI has:
- limited button functionality (control groups and “action” buttons)
- broken map panning
- the start to marquee select
- the start to unit spawning
- binary message receiver 100%
- binary message sender 80%
Server:
How we will get to our goal:
Just keep coding! It may sound ridiculous but that's the plan. With the exponential reduction in work load created by moving to a 2D client I know has a very clear design path to follow. 2D RTS UIs have been around for over 20 years so there is a wealth of online experience for me to draw from.
Just to illustrate the kind of time and complexity reduction we are talking about here;
Time to create a 2D vector-art, scalable/rotatable, modular, overhead art asset: 3 hours
Time to create a 3D mesh with a baked-in texture map and rigging:
Model, 2-10 hours. Texture, 2-10 hours. Rigging, 2-10 hours.
So in the best case scenario it will take double the amount of time for asset creation. I think it is important to note that the test sprite I am using for units took me less than 10 minutes to draw.
Yes, we intend to market it:
Because I believe the mobile market is waiting for this kind of strategy game I will definitely be pursuing it's marketing. It is my intention to continue game design as a career path upon graduation, either independently or under a corporate umbrella. This project is a great learning tool for exploring mobile gaming technologies and I plan on continuing with it until it's completion after school.
BODY:
///////////////////////////////////////////////////
////////////////////////////////////////////////////
Specifications:
- Client/Server model.
- Cross-browser/platform compatibility.
- JavaScript 2D client.
- 3 (+ 10) button mobile UI layout.
Game Specs:
- Support 3-8 players simultaneously.
- Support 500-2000 individual units.
-
Use Cases:
We are hoping that we will bring RTS fans to the mobile gaming market and introduce the mobile gaming audience to a more hard-core style of gameplay. There is of course the theory that “hard-core” games don't belong in the mobile arena because the audience will only support a 10 minute attention span. We are hoping that this doesn't hold true and that people will spend 20-30 minutes completing a round of our game.
Implementation Choices:
Excluding the flip-flopping about 2D and 3D graphics most of the game has been fairly static from early on. Game-play and UI design components have been completely independent of dimensional representation
Game Structure on Client:
PhaserState -- Phaser uses “states” to control application flow. You can think of states as being screens; Main Menu, Game Login, Options Menu, etc... States are used to manage asset loading.
PhaserGame – the game object that contains all of the current level data. This object is a global variable that is re-used for every level. However, Phaser does allow for multiple games to be created which would support a mini-game sort of functionality. We only have one game object though.
PhaserObjects – I won't go deeper into explaining the structure of Phaser except to say that it has all of your standard 2D engine bells and whistles. Support for touch, keyboard and mouse input handlers, sprite sheets, tile maps, animations like tweening, limited WebGL shaders, etc...
Logic flow from server listener:
ChefClass: Receives binary data from the server and parses it into game-readable event code.
The ChefClass parses the data into messages called “cereal”.
In the PhaserGame update loop there is a cereal eater method that simply listens for changes to the cereal model and “eats” the changes as they come in. I think there is a way we can have the PhaserGame listen directly to the ChefClass but I'll figure that out later.
Almost all my subclasses inherit from the Phaser.Sprite or Phaser.Button classes because everything on the client is just UI.
Game Structure on Server:
GameObject:
- Map
- Team:
- Entity (Projectiles and Units are actually the same class for now)
- Chef (the binary message passer)
Status:
Not even close to finished. However, we do have everything in place for our Client/Server message passing and can observe unit behavior on the client through an Elm “portal”.
We have a less than complete product because we kept moving forward with a 3D client even after it became apparent that there was no way one person (me) could complete that kind of workload in the allotted time. This happened because we started our project with 4 team members and now only have 2. Both team members left (one dropped the class and one joined another group) during Winter quarter so much of the client work I had done already was in 3D which I was loathe to throw away. It was a lot of time and effort to scrap.
So much of my time has been spent scaling back implementation details to accommodate the lost members. Sadly taking even more time away from my direct project work.
CONCLUSION:
Not much to conclude other than we just need to keep plowing ahead. Successful game design is about sticking to the plan even when things get hard. Of course plans will change but changes must a conscious decision that reflects the predetermined goals of the design.
Design and Programming Issues:
//////////////////////////////////////////////////////////////
Lessons Learned:
Did I ever.
//////////////////////////////////////////////////////////////
No comments:
Post a Comment