Jump to content

  • Log In with Google      Sign In   
  • Create Account

be-the-hero.net

Member Since 15 Sep 2012
Offline Last Active Oct 25 2012 02:29 PM

Posts I've Made

In Topic: Being an Investor - Paying Programmers/Artists

15 October 2012 - 01:46 PM

I think it is a dangerous path. Mainly for the "naive" reason: you have no idea what you are getting into and what budgets are required. So, in the best case, you'll end up working with a decent developer and artist, and sell a few copies of your app.
In the worst case, you'll delegate an over ambitious project to a cheap developer (in both senses) and burn through your bucks without completing it or end up with some crap.

Therefore, I basically have two advices:
- think small, try it first with a simple game (...and this would help you to check you found the right people!)
- ask the most ...knowledgeable... developer friend you know to interview developer candidates

Despite I would be reluctant, I think everything is possible ...provided some effort, luck and care.
It's a bit of gambling though, and I would say the odds are not on your side.

In Topic: New to this need some help

18 September 2012 - 11:25 AM

Tip 1: always prefer interfaces to inheritance
An interface defines what functionalities an object should provide
Inheritance is a "is a" relationship, and a way of reusing code among similar objects.

As for the rest, in what classes you should put what method, the best is to follow your intuition where it fits the best.
There is no golden rule for that, it is too case specific. In the process of doing it, you'll certainly acquire a better feeling of what to place where.
Tip 2: Refactoring and improving the code as you go is always a good idea. The time it costs now will be saved several times in the future.

In Topic: Turn Based Games - Initiative

18 September 2012 - 02:00 AM

I personnally prefer a "per-unit" initiative, it makes the game feel more interactive. My 2 cents.

In Topic: New to this need some help

17 September 2012 - 10:12 AM

1) Intuitively, I think I would divide it into following classes:

class Player
{
  Weapon weapon;
// ...
}
interface Weapon
{
  Bullet shoot(...);
  // ...
}

abstract class Bullet
{
  Vector2f position;
  int direction;
  // ...
}

class MachineGun implements Weapon { /*...*/ }
class MachineGunBullet extends Bullet { /*...*/ }

class RocketLauncher implements Weapon { /*...*/ }
class RocketLauncherBullet extends Bullet { /*...*/ }

2) Ideally, your:
setState(GameEntity.State.idle);
Should be triggered by a "mouse up" event to avoid any confusion / synchronisation problems.
The following seems also to make more sense to me:
if (input.isMouseButtonDown(Input.MOUSE_LEFT_BUTTON) && getState() != GameEntity.State.overheated){

		if(getFire() == 0){
		 System.out.println("Fire!");
		 setFire(getFireRate());
		 increaseHeat(getWeaponHeatRate());
		 setState(GameEntity.State.shooting);
		}
}else{
		 setState(GameEntity.State.idle);
		 System.out.println("no fire");
		 setFire(getFire() - 1);
}


In Topic: Text RPG - feedback wanted!

17 September 2012 - 02:32 AM

...perhaps visually showing all the nodes and the choices that connect them kind of like a road map...


Yeah, I thought about it, to have a graph of all pathes in the story generated automatically. However, I have no idea how I could do that. And making it "navigable/editable" is probably also a lot work.

Instead, to give a broad structure to the adventure, I though of splitting the "book" in chapters or in areas ...or both.
The chapters are like cutting the global storyline/plot in rough chunks. The other is more like a spatial division where a map could additionally be used.
By having an outline/synopsis/summary for the chapter and a single entry point, it would act as a check point to ensure all the pathes come back together at some point.

PARTNERS