191 karma · joined May 31, 2009
That said, early in product development in-person feedback is invaluable and you can get so much more out of it than of a simple video of a person using your product.
It's hard to tell whether the guys shooting at me were really trying to heal me though.
Some suggestions:
* At the beginning of the screen show a message that tells the player 'You are on team RED'
* Add a message for players who are team-killing - like a huge 'TEAMKILL' popping up on their screen.
* Also add a penalty to prevent people from team-killing (like a 10 sec respawn delay)
edit: friendly_id does not use the dynamic find_by_x methods. I guess it should be safe.
A game like this was feasible 20 years ago in a native environment or 10 years ago in Flash. I can only see disadvantages in developing games in JavaScript + HTML.
Take an iPhone app for example: The simple, elegant way to implement a page change in the Mail app would be a to just switch the page like this:
currentPage = pages[nextIndex];
The resulting code is probably far from what you would call simple and elegant.
1. What's the advantage of doing this in HTML5 vs Flash? This is not a game I can play on a touch screen device.
2. Why should customers get excited about a game that would have looked pretty average even in the 1990s? Nobody cares that it's HTML5.
edit: I use git for game development, and we check in some big asset files (uncompressed .wav music tracks etc.). As long as these don't change too often, the repo stays manageable. Up to 10gigs is still a reasonable repository size IMO.
Suggestions:
- Add a tweening for picking up and dropping letters
- centering of the board should happen automatically
- put the restart button somewhere else. It looks weird when you drop a letter on top of it and it appears behind it (e.g. the 'm' in 'seem')
- can't really tell from the video whether you already did this, but implement iPhone-like scrolling w/ momentum and bouncy behavior
The GC's marking phase is very slow because it has to traverse the whole object graph each time, meaning you want to make the object graph as simple as possible. Arrays of structs are very efficient for the GC to scan (it can either collect the whole array or not), but working with structs is a nightmare because there's no polymorphism.
For Fluffy[1] we just used classes and tried to optimize the hotspots as an afterthought. I'm not quite satisfied with how it turned out, there's still a periodical 20-40ms lag in the game.
There is a great article about keeping heap complexity low: http://blogs.msdn.com/b/shawnhar/archive/2007/07/02/twin-pat...
[1] http://marketplace.xbox.com/en-US/Product/Fluffy-Operation-O...