It appears you have not yet registered with our community. To register please click here.

Origin XT RPG Network Home

Our First Task


Jul 16 2009, 06:01 AM (Post #1)
Not Odd anymore
* * * * * * * * * *
Posts: 45,875
Cash: 1,915,578 / 1,817,041,051
Group: Administrator
Joined: 7/10/02 09:48 PM
In line with our project development philosophy, we will write a roadmap of what we want to achieve initially. We want something with clear visibility and something that's achievable.

Here's what I think: We can create a simple regional battle system that can read map inputs and allow multiple players to make moves, one after another. This will force us to decide the details of 1. what moves people can make, 2. how to read/interpret map files, and even 3. what a map can have.

Who'd like to talk about 1, 2, or 3, or suggest a 4?
Post Options

 
Jul 16 2009, 12:48 PM (Post #2)
Colonel
* * * * * *
Posts: 2,579
Cash: 46,264 / 266,023
Group: Nobility
Joined: 12/14/05 03:32 PM
Here's my opinion, as a guy who makes games for fun. Don't do any programming until you know exactly where you are going with it. As tempting as it is to just figure it out as you go along, the game will represent your programming skills alone, not what the original idea was about.


I would start with exactly the stat system, and that alone, until it's finished, but that's just me.
Post Options

Jul 18 2009, 04:18 AM (Post #3)
General
* * * * * * *
Posts: 4,936
Cash: 29,817,299 / 68,857,771
Group: Representative
Joined: 11/26/02 02:31 AM
1:

Movement can go one of two ways, we can either have horizontal/vertical, or we can add in diagonal movement added in as well. Units should have individual movement ranges (presumably a whole number indicating the number of tiles that a given unit can move in one turn).

If we go with diagonal movement, we could have a penalty of 3 movement points per 2 diagonal spaces per turn.

Going with the fashion of various TBS games, different types of terrain can have various costs associated with them, ie: hills have a movement cost of 2, and unit A has a current move range of 1. Therefore, he cannot move onto the hills, as he would wind up with -1 move.

I think we should veer away from the advance wars concept of movement costs varying based on what unit you have. It is a great system, but for the sake of simplicity and outward originality, it would be best to stick with what works. Though some units should be at the very least restricted, ie: tanks can't go in water.

I am not opposed to the idea of teleporters, either; something that could be built to hasten mobilization into the front lines.


On that idea, i can segue into a #4: types of units, though I think it can be saved til later. Maybe a second task?
Post Options

Jul 18 2009, 09:09 PM (Post #4)
Not Odd anymore
* * * * * * * * * *
Posts: 45,875
Cash: 1,915,578 / 1,817,041,051
Group: Administrator
Joined: 7/10/02 09:48 PM
QUOTE (Key's Rat @ Jul 16 2009, 04:48 AM)
Here's my opinion, as a guy who makes games for fun.  Don't do any programming until you know exactly where you are going with it.  As tempting as it is to just figure it out as you go along, the game will represent your programming skills alone, not what the original idea was about.
I would start with exactly the stat system, and that alone, until it's finished, but that's just me.
*


Well, we'll definitely do planning along the way, but as I've said, in incremental/iterative steps. We're thinking of our work as discrete segments that are at most 2 weeks long (so not very big segments). For each iteration, we plan quickly, do work, combine work, and re-evaluate. Traditionally we've done a lot of planning for projects we've wanted to do, but much less of the execution. I want that to change with this project. First and foremost is to get things done. Planning is just so we are all on the same page.
Post Options

Jul 18 2009, 09:19 PM (Post #5)
Not Odd anymore
* * * * * * * * * *
Posts: 45,875
Cash: 1,915,578 / 1,817,041,051
Group: Administrator
Joined: 7/10/02 09:48 PM
QUOTE (Billy Mays @ Jul 17 2009, 08:18 PM)
1:

Movement can go one of two ways, we can either have horizontal/vertical, or we can add in diagonal movement added in as well. Units should have individual movement ranges (presumably a whole number indicating the number of tiles that a given unit can move in one turn).

If we go with diagonal movement, we could have a penalty of 3 movement points per 2 diagonal spaces per turn.

Going with the fashion of various TBS games, different types of terrain can have various costs associated with them, ie: hills have a movement cost of 2, and unit A has a current move range of 1. Therefore, he cannot move onto the hills, as he would wind up with -1 move.

I think we should veer away from the advance wars concept of movement costs varying based on what unit you have. It is a great system, but for the sake of simplicity and outward originality, it would be best to stick with what works. Though some units should be at the very least restricted, ie: tanks can't go in water.

I am not opposed to the idea of teleporters, either; something that could be built to hasten mobilization into the front lines.
On that idea, i can segue into a #4: types of units, though I think it can be saved til later. Maybe a second task?
*


We could simply things very much if we stick to only vertical and horizontal movements, with diagonal ones being some combination of the two, exactly like in advance wars. So that reduces complication from the programming point of view.

As for terrain-based movements, it's not too hard to make movement cost be a function of unit type, terrain type, and weather. So we can just compute movement cost by calling a function we can write:
CODE
int movementCost(int unitType, int terrainType, int weather);

Of course, if we use PHP, we can omit data types, but you get the idea. Making movementCost() read from a text file input is incredibly easy, so it'll be okay.

Teleporters would definitely be something that we do after making a basic design. I agree that the idea is cool, but the first task is to have a basic regional map ready.
Post Options

Jul 23 2009, 08:35 PM (Post #6)
Foot Soldier
* * * * * * *
Posts: 4,710
Cash: 88,623 / 0
Group: Nobility
Joined: 5/04/04 11:36 PM
Haven't you already sort of decided this on your own Jinghao, with what you've coded (aside from movement), or is that all just preliminary?

When you talk about "moves," do you mean simply physical moving from place to place, or a move as in a turn or attack? Is this even going to be turn-based? That discussion's not for here.. about structure of battle..

But maybe it is for here, since you say you want a "regional battle system," so are these moves then offensive as well? And you say one after another, which leads to believe it's turn-based... this would be so much easier if we were in person, god.
Post Options

Jul 24 2009, 07:04 AM (Post #7)
Not Odd anymore
* * * * * * * * * *
Posts: 45,875
Cash: 1,915,578 / 1,817,041,051
Group: Administrator
Joined: 7/10/02 09:48 PM
QUOTE (Angel @ Jul 23 2009, 12:35 PM)
Haven't you already sort of decided this on your own Jinghao, with what you've coded (aside from movement), or is that all just preliminary?

When you talk about "moves," do you mean simply physical moving from place to place, or a move as in a turn or attack? Is this even going to be turn-based? That discussion's not for here.. about structure of battle..

But maybe it is for here, since you say you want a "regional battle system," so are these moves then offensive as well? And you say one after another, which leads to believe it's turn-based... this would be so much easier if we were in person, god.
*


First off: It is turn based.

Second off: I mean physical changes in position = moves. If I meant attacks, I'd say attacks.
Post Options

Jul 25 2009, 05:04 AM (Post #8)
Foot Soldier
* * * * * * *
Posts: 4,710
Cash: 88,623 / 0
Group: Nobility
Joined: 5/04/04 11:36 PM
Okay. I was thrown off by your use of the world "battle" in your description of what you're going to create. This is much more manageable.
Post Options