Jump to content

  • Log In with Google      Sign In   
  • Create Account


rakketh

Member Since 07 Nov 2007
Offline Last Active Sep 11 2013 09:59 AM

Posts I've Made

In Topic: Don't like ending games

19 April 2013 - 07:10 AM

I've had a similar idea for a (theoretical) MMORPG for a while now. When you reach "maximum level" you can breed and create a new offspring character to play. Doing this gives (at least) 2 advantages:

1) The old character can now level up further, but has perma-death:
This would allow for high-risk/high-reward play such as going after a legendary treasure that can be handed down in the family until it breaks. The dungeon holding the treasure would be far too difficult for normal characters to attempt.
There are other ideas such as having the older characters retire as trainers in your clan village, where the higher level they reach post breeding increases their teaching rate, so you would have to trade off training speed vs risk of dying and wasting that potential.

2) The child character can get new abilities unavailable to the parent:
My game idea is loosely based on the Naruto world, where characters can master individual elements that they have innate talent for. So if your old character could use water and you breed with someone who can use wind there is a small chance that the offspring can get a new talent to combine both water and wind to manipulate ice.

In Topic: MMORPG combo/keybind system

23 June 2009 - 12:05 AM

I really like this idea in terms of keyboard real-estate. I know when I used to play a rogue in WoW there were always some moves that I wanted to use occasionally, but since they weren't my main set of moves they were always out of the way and therefore difficult to hit when I needed to. The option of introducing more complicated combos appeals to me too, since it gets really dull performing the same attack over and over.

I'd like to know how these moves are set up - does each stance have it's own set of moves, or do you get a bunch of moves to choose from and you put them in the stance bar yourself to create your own combos? If that is the case, does a move have "stance 1, leads into stance 2" and you chose from a set for that particular slot (or maybe could lead into a choice of stances)?

Something that came to mind while I was reading is an enhancement (maybe) to the system, where the move sets represent combo steps rather/as well as stances. For example, move sets 1 and 2 could both be in the same stance or could be different stances. Characters who focus on 1 stance get more moves / more proficient at moves for that stance, while characters who flow between multiple stances have the benefit of confusing the defender, making it harder to block the attacks. Implementing this would depend on the skill system you are building into the game and also thinking up more benefits for each play style.

In Topic: Avoiding the MMO end-game with generational advancement

30 January 2009 - 10:31 AM

Thanks for the replies so far. I was trying to get a feel for whether constantly having to restart a char was a big problem. I don't think that the "ultimate top level boundary" poses too much of a problem: if you consider WoW, once you get to full tier 3 epic armour and such, there is still a drive to get just that little bit extra; in a game such as EVE, which has no skill caps, players are striving to achieve an ever-decreasing performance boost every year of play.

I suppose I am moving this boundary to a different position in character development. Instead of having 1 char constantly getting that little bit better, you spawn a new char with the extra potential to get better, or with a different build so your game can vary that way also. Doing it this way opens up a new part of the game, which is a large focus of my overall game plan: having elder characters.

Elder characters become controllable NPCs that are added to your clan village - this would be either as an alt or in a more generic goal kind of way (comments?). Rather than having a bunch of developer-created NPCs that you have no connection to, your village is actually full of characters that you (and your clan-mates) have developed.

For example if your elder char is a healer, they could open a hospital where players can respawn for a fee. The better the healer the less of a debuf the death leaves, giving an incentive for friendly players to use your healer, and therefore giving your village more capital.

The game introduces a strategy to either breed early to give your village more NPCs, or less frequently to give it more knowledgable ones. For example one player may want to train their first character to a high skill level, compared to another player who breeds 5 generations in that time. The second player would have contributed more NPCs to his village, which would provide a different advantage to a village compared to the advantage of having a single strong character.

There would need to be a mechanic for a population control for elder characters. This could be an aging mechanism, perma-death whilst making the NPCs still playable, a combination of the two, or some other mechanism (insert ideas here).

I envisage this game is largely PvP, so the challenge is not a particular "dungeon" which would be repeated through each generation; instead "quests" would be based around player interactions so repetitive PvE content would become less of an issue.

In Topic: const return problem

16 January 2009 - 02:33 AM

Quote:
Will someone make sure that his/her x's and y's are in the right order?

his :D Don't worry too much about x/y battling as that is something that will be worked out when I debug if it is wrong. I'm mainly after advice on good practices.

Quote:
squares = new GameSquare* [x];
squares[0] = new GameSquare[x * y];

I found this on a website when I was looking up dynamically allocated 2d arrays. The idea behind it is that you save overhead by only calling new and delete twice. I agree that it doesn't look right, but I went along with it. After another search I see that I've missed a vital point, the full example that I now find is:

template < typename T >
T **Allocate2DArray( int nRows, int nCols)
{
//(step 1) allocate memory for array of elements of column
T **ppi = new T*[nRows];

//(step 2) allocate memory for array of elements of each row
T *curPtr = new T [nRows * nCols];

// Now point the pointers in the right place
for( int i = 0; i < nRows; ++i)
{
*(ppi + i) = curPtr;
curPtr += nCols;
}
return ppi;
}

template < typename T >
void Free2DArray(T** Array)
{
delete [] *Array;
delete [] Array;
}


I agree, however, that this is unwieldy and will change the grid to a vector using the maths example provided by EasilyConfused. I have changed the bool into a GameSquare struct with a state member variable to make it easier to change its implementation in the future and to avoid the vector<bool> potential pitfalls.


Quote:
I think you want >= here not just >, unless the first element of each column and row is to be ignored.

Yes, this is wrong, should be >= 0, < size. I blame tiredness :) thanks for pointing it out.

In Topic: const return problem

15 January 2009 - 01:24 PM

Thanks for the replies and the links. That const 2-d array gets complicated fast! I'm quite new to cpp, being a Java developer by trade but wanting to learn cpp for games development as a hobby. I've read up on references now and see that they are a much better option than pointers in the way I am using them here.

I've refactored my code into a new class based on your advice:

GameGrid.h

#pragma once

struct GameSize {
GameSize(int x, int y) : x(x), y(y) {}
~GameSize() {}

int x, y;
};

struct GameSquare {
GameSquare() { state = false; }
bool state;
};

class GameGrid
{
public:
GameGrid(const GameGrid &source);
GameGrid(int x, int y);
~GameGrid(void);
GameGrid & operator = (const GameGrid & other);

const GameSize& getGameSize() { return size; }
const GameSquare& getGameSquare(int x, int y);
void changeGameSquare(int x, int y);

private:
GameSize size;
GameSquare **squares;
};



GameGrid.cpp

#include "StdAfx.h"
#include "GameGrid.h"

GameGrid::GameGrid(const GameGrid &source) : size(source.size) {
squares = new GameSquare* [size.x];
squares[0] = new GameSquare[size.x * size.y];

for(int ix = 0; ix < size.x; ix++)
{
for(int iy = 0; iy < size.y; iy++)
{
squares[ix][iy].state = source.squares[ix][iy].state;
}
}
}

GameGrid::GameGrid(int x, int y) : size(x, y)
{
squares = new GameSquare* [x];
squares[0] = new GameSquare[x * y];

for(int ix = 0; ix < x; ix++)
{
for(int iy = 0; iy < y; iy++)
{
squares[ix][iy].state = (rand() % 2 == 1);
}
}
}

GameGrid::~GameGrid(void)
{
if(squares != NULL)
{
delete[] squares[0];
delete[] squares;
}
}

GameGrid &GameGrid::operator =(const GameGrid & other)
{
if(this != &other) {
GameSquare **tempSquares;
tempSquares = new GameSquare* [size.x];
tempSquares[0] = new GameSquare[size.x * size.y];

for(int ix = 0; ix < size.x; ix++)
{
for(int iy = 0; iy < size.y; iy++)
{
tempSquares[ix][iy].state = other.squares[ix][iy].state;
}
}

if(squares != NULL)
{
delete[] squares[0];
delete[] squares;
}
squares = tempSquares;
size = other.size;
}
return *this;
}

const GameSquare& GameGrid::getGameSquare(int x, int y) {
// if(x < 0 || x > size.x - 1 || y < 0 || y > size.y - 1) return NULL;

return squares[x][y];
}

void GameGrid::changeGameSquare(int x, int y) {
if(x > 0 && x < size.x - 1 && y > 0 && y < size.y - 1)
{
squares[x][y].state = !squares[x][y].state;
}
}



Does this look like a correct implementation of the rule of 3?

There is a commented out line which I'm not sure how to handle. In Java, this works since everything is treated as a reference. In this instance should I be using a pointer instead of a reference, or is there a better method? (I am of the understanding that cpp exceptions are slow!)

PARTNERS