Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Nov 2009
Offline Last Active May 17 2012 08:21 AM

Posts I've Made

In Topic: Wanted: feedback on multiplayer ideas and target platform

27 March 2012 - 04:40 AM

Just a few, eh? ;D

You don't ask, you don't get :-)

Thanks for all your responses.

Casual gamers love puzzles, they don't like competitive gunfights. I'm confused over the balance you want between puzzles, and fighting.

I'm maybe confusing myself with the terminology. Basically, I'm looking at something that is simple and quick-fix enough for players to log into for half an hour for a quick few levels, but has enough of a 'hook' and enough variety to keep the more hardcore amused over a longer multiplayer campaign.

I love games like Enemy Territory for example, but to really get into I find I have to play a full campaign which can last hours.

I'm also trying to avoid a complicated class/weapon/stats system that takes hours of play to get into.

Sure, $5 seems fine to me. If we're saying, One class with 2 variable weapons for free, and 4 classes with up to 20 weapons paid. I like that model.
Hustlerinc's suggestion of micro-transactions is going to earn you more money though. A lot more. If each class costs 500 Out-Of-Game credits, and each weapon could be bought with 500 In-Game, or 100 Out-Of-Game, and 100 Out-Of-Game costs $1... build your own model, but it's making serious amounts of money for other games.
As a designer/player hybrid, I prefer the first option. Feels less of a rip-off / sell-out. But don't be fooled by people who share my opinion. We'd all stick micro-transactions in our own games in a flash.

Haha, I know what you mean about the sell out feeling. Personally it gets my back up a little when I sense an attempt to quitely and subtly part me with my money, especially when they've got you in a corner. But I do like the idea of 'let's try this class out and see how it changes the game, it doesn't cost much extra'.

Hope to have helped,

Thanks for the opinions, I have things to think about now.

In Topic: Wanted: feedback on multiplayer ideas and target platform

27 March 2012 - 04:17 AM

Have you considered HTML5? Since you want a webhosted game I definitely suggest looking into it. The tech is getting really advanced, really fast, and simple games are allready possible to make.

The thought never crossed my mind, but I am looking into it so thanks for the pointer.

The biggest advantage is that there is no download. On the other hand you will have to reconsider the payment method, but there are advantages with microtransactions too, instead of getting payed once for the game you charge for every new major weapon/armor/grenade you put into the game.

Another good point about microtransactions. My main fear about adding new weapons would be unbalancing the multiplayer side; those who'd paid full whack would have an advantage, putting off new players. I hoped to delicately balance the class system so that, even though one class may approach things in a different way (stealth or speed vs brute force) the two classes would be closely balanced in terms of pure capability. But then I could still have a microtransaction to add in each new balanced class. (Play as an "x class" for $y).


In Topic: Get a point along a bezier based on distance

26 March 2012 - 02:49 PM

I came across this problem once when designing a railway system. After all, often you want to be able to move something along a curve at a defined speed, right?

At first I was using Bezier curves, and the best solution I came up with personally was to pre-evaluate the curve at the point of creating it, stepping over the curve and building a lookup table as JTippets suggests. The only remaining issue is one of accuracy, as you will a finite number of entries in the lookup. If the point you want lies between two lookup entries, then you'll need to linearly interpolate between them. Not a big deal, but if your curve is very long and the number of lookup entries small, then the amount of deviation will be enough to notice stepping as something moves along it.

However, the very best solution I found was to scrap beziers entirely and move to catmull-rom splines, evaluating with the newton-raphson method. (Google catmull rom newton raphson and you'll no doubt find it). This gives a accurate and reliable method of evaulating the spline by arc-length without any lookups.

In Topic: Delta time & Collision Detection problems

13 May 2011 - 12:15 PM

What about setting a max limit on the deltaTime? If it goes over a certain amount (say 0.066 for 15fps) then you cap it at 0.066. So you might see a judder in the game when your pc lags but you shouldn't get jumps that are big enough for an entity to pass through another.


In Topic: composite design question

13 May 2011 - 03:53 AM

When it comes to collisions between entities, and how to deal with those in components, I found the best way personally was to keep the system as generic as possible.

If a projectile collides with an entity, then specifically calls that entity's takedamage method, then you're hardwiring the rule that a collision will always give damage. What if later you decide to add a shield to that entity, or want to make it invincible to certain projectiles? If the code is hardwired into the projectile then you don't have flexibility.

There's also the possibility that the entity which was hit by the projectile does not have health or a damagable component (an indestructable wall?) , therefore it wouldn't have a takedamage method.

Here's the way I do it.

My Entity does very little, it simply holds an array of Components, either one or zero of each type being allowed. All components regardless of type have a standard init, deinit, move, update, render, and handleEvent. Each update, the entity simply loops through its components and passes through the init, move, update, render information for that frame, and on a message being sent, just passes it through to all components' handleEvent method.

I currently have about 7 component types, but the ones relevant here are CollisionComponent and LifeComponent. These are just abstract classes/interfaces, the ones which do the actual work will subclass these.

Bullets have a BulletCollisionComponent. On each update, it asks the world to give it a list of all colliding Entities. If any, it generates a takeDamage event containing the bullet id, the bullet type, the damage factor, and also the id of the entity which fired the bullet originally. It posts that event out to each Entity and then forgets about it.

The receiving Entity will pass this event through to all components which will eventually reach the LifeComponent. The LifeComponent, depending on its type, can hold information about the entity's strength, or shields, or how long it has left until self destruct (ie: bullets have a lifetime).

In this case, it's a ShipLifeComponent since I'm working with spaceships here. In it's handleEvent method, it'll respond to takeDamage events by working out if the bullet is a type which damages this ship, work out the damage after shields are taken into account, etc, then decrement the strength if necessary. When strength reaches zero it'll spawn a nice particle explosion and tell the parent entity that it's time to deinit.

If I have a PowerUpLifeComponent I'd simply ignore takedamage events, unless I want to be able to shoot them down.

As for your question about the barrel vs. enemy collision code being exactly the same.. in the above example the receiving entity's collision code is never called so it's not a problem.. only the entities which perform actions do any work in their collision code. The ones which respond to actions do the work in their lifecomponent. In this case, the enemy lifecomponent would simply decrement the life until it reaches zero. The barrel lifecomponent would do the same, but upon reaching zero would send out its own takedamage event to all entities in range. (I assume the explosive barrel is going to hurt things when it dies).