Jump to content

  • Log In with Google      Sign In   
  • Create Account

Zed2100

Member Since 10 Mar 2012
Offline Last Active Nov 05 2014 06:52 AM

Posts I've Made

In Topic: Police spikes phyisics

08 October 2014 - 08:25 PM

In this context, what do you mean by "animated model"? What animations are in place that you're concerned about?

 

To attempt an answer, I imagine that the spike-strip would simply be a trigger object (and not a "solid" physics object) that would produce a temporary change in the velocity, handling characteristics and perhaps other properties of the car that hits it (perhaps via a state change, or perhaps an modifying class aggregated in the "car" object, or some other means); the specifics of this would likely depend on how you've modelled your driving physics, I imagine.

 

I agree with Thaumaturge, spikes implementation depends on how you model your car and physics. In order to help you, it would be nice to tell us exactly what language / engine you're using, is it 2D ? (Box2D, Farseer) 3D ? (Havok, Bullet Physics, Newton).

 

Spikes are better off without a physical presence, in the case of Box2D, they would be implemented as sensors. When colliding with the tires, you can make the car less responsive to input, you can modify the friction of the tires to make them stick more to the ground. I guess there's some tweaking to do here to get the right effect.

 

We're discussing gameplay mechanics but it seems to me that OP is more concerned by graphics and animation of the tires. We can go as far as implementing it using soft bodies but that would be overkill, I would say fake it : make 2 models or 2 textures for the tires, then change the model (or texture) once a tire hits the spike strip. You can also create a smoke particle system and maybe throw in some sound effects to make it more realistic.


In Topic: What is game maker?

08 October 2014 - 10:28 AM


whether it is better for production quality games or just prototypes, is debatable

 

Yes, that's exactly what I have been thinking about for the past 3 months while working with construct 2. It seems that these tools can help you progress really fast but not too far, so for small games they are good enough, but as your project gets larger these tools show some limitations.

 

I find it difficult to transition from programming to using these tools, there's always a voice inside your head that tells you you're not doing it right. However it seems that most of Game Maker like programs are made for non-programmers who still want to make games. I think it's not fair to not be able to make games if you lack programming skills, lots of great game designers don't know how to code to some extent. These tools provide an opportunity to test your ideas and play them in few minutes or hours of work, I think it's amazing.

 


One more signifant complaint is the pricing, for a 2D software.

 

Construct 2 and Stencyl are cheaper, and for my specific needs, they proved to be more useful than Game Maker.


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.

PARTNERS