Jump to content

  • Log In with Google      Sign In   
  • Create Account


Zed2100

Member Since 10 Mar 2012
Offline Last Active Apr 15 2014 07:38 AM

Posts I've Made

In Topic: Thoughts on Splitting Up the RTS...

04 January 2013 - 04:55 AM

This sounds kind of similar to a browser based MMORTS like travian and the million others that are out there but maybe in a real time/non browser based form?

 

Being browser-based doesn't necessarily mean that the game is turn-based, it can also be played real-time using websockets (example : Browser Quest by mozilla). 

 

I agree with Shake92 about answering the question of victory/defeat conditions. I think something like the concept of the world map in Total War series could do the trick : you have cities (or one city in our case) that is safe from harm and where you can build and train troops, but there is a battlefield where troops can fight. When one army defeats the other on the battlefield, it can move to the city and siege it.

 

A victory on the battlefield doesn't necessarily mean winning the game. One player must successfully siege the other player's city in order to win. So instead of 2 modes of play, I suggest having 3 : 

  • City Building
  • Battle Front
  • City Siege : this mode will eventually lead to winning/losing the game.

I think one of the biggest pleasures in RTS games is protecting your weakest points (city, supply convoys like DtCarrot suggested, ... etc) and trying to hit your opponent's. If cities are completely isolated from battle, players' weakest points will not be exposed (at least not completely). But that's just me, I like combat more than management in RTS games, so for me this point is very important.


In Topic: Advice regarding language choice - 2D Top Down Strategy

03 January 2013 - 02:00 PM

I agree with the guys above on learning C++ and making your game with it. C++ has evolved a lot these last years and there has been some nice updates to the language.

 

C++ is the language most pros are using, but these are very skilled people, so it would be a better idea if you took some time to master it first before thinking of making a game with it.

 

Personally, I learned C++ and made some simple games with it, then I switched to Java, then finally to javascript because it were easier for me and I wanted to make games that are directly playable in the browser without requiring a plugin. Now with the advances of HTML5, you can do a lot of cool stuff like drawing 2D shapes or sprites in canvas, saving data locally (in case you wish to save player progress, score, ...), playing sounds, ... etc and you can also do 3D if you wish.

 

I appreciate working with javascript because all it takes to see the changes you made to your code is hitting F5 to refresh the web page. I like to focus more on game design so working with a scripted language saves me a lot of precious time.

 

I think the most important thing for a beginner is to go through a basic, but complete, development cycle, one that includes a basic initial idea of a game, a simple game design, modeling the features of the game (here your job is to "translate" the game design to technical details, algorithms, UML diagrams, software architecture, ...etc), programming and testing. So I agree with bassy that the language in itself is not very important.


In Topic: The Weapons of a Game Designer

15 November 2012 - 03:07 AM

1. GDDs are really overrated ! They are a good way for unexperienced designers to get their mind right, or to write down the basic game play for larger productions, but most of the final game will be developed during ..well.. development time.


I think any team needs some sort of "document" to keep track of their game design. The document will be enriched during the iterative process of making the game. By "document" I don't mean a big fat word document made prior to developing the game. The document can be empty in the beginning and filled along the way.

Then again, I'm a beginner in game design so I learn a lot by writing down stuff.

4. Cheats: they are necessary, but they are really dangereous. Using cheats is a way to avoid certain game play, the danger is, that you start testing the end-game only and negclet the start of a game. But the start of the game is the most critical part for new players.


I agree with you on this one, there could be a bug in the beginning of the game that you'll never see during your tests. And new players are very important because they judge a game by the first minutes of play. So testing the final product as-is is also a good idea.

In Topic: Guide to bad game design

15 November 2012 - 02:38 AM

I think bad game design has a lot to do with lack of fun :
  • Make the game as repetitive as possible, variety is bad ! Avoid it at all costs
  • Make it as difficult as possible so that only an elite of players can beat it, noobs don't deserve to win
  • Give as much achievements as possible, give an achievement for opening the options menu !
  • Let players guess how to play, it's much more fun that way !
  • As an alternative for 2), strip the game from any challenge so everyone could win, targeting a very large audience (including new-borns) will sure make you filthy rich !
This is an exerpt of my blog post Do these 5 Mistakes at the Risk of Boring Your Audience

In Topic: Punishment and reward

10 March 2012 - 01:10 PM

I think the reward/punishment system must be balanced so that there's no clear winner or loser until the end of the game.

A reward must always have a little punishment in it, for example : in a multiplayer FPS, when you reward a player with a big gun, the gun will make him move slower, making him an easier target for other players.

PARTNERS