Jump to content

  • Log In with Google      Sign In   
  • Create Account

My Pokemon Clone - Design Questions & Answers


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 Weajiin   Members   -  Reputation: 101

Like
0Likes
Like

Posted 24 November 2012 - 06:39 PM

Welcome to my Pokemon Clone design thread. I need help fleshing out the systems needed to make a flexible single player skeleton for the game. I plan to reuse sprites, audio clips, and data so I just need to create a scale-able system to display, manage, and update whatever I throw at it. This is not for commercial purposes, I have watched the serious spiral into chaos, I have a few features up my sleeve, and I want to see if I can bring life back to the dying series. I haven't gotten to far just yet, the reason being is, I don't know how to mesh everything together properly to begin with.

I need direction. The language and the libraries aren't set in stone, It is looking like SDL and C++. I'll try and explain what I've got so far.
  • A blueprint of factory class that contains all the information necessary for making instances of Pokemon, sprites, items, etc.
  • A memory class that keeps track of instances being used by the game.
  • A game class that will wrap SDL and provide an interface to the references and instances noted above.
  • In between the blueprints and instances there will have to be a function that creates the game world, polling blueprints and creating instances in all the necessary spots to (re)create the world in memory.
//#include <stdlib.h>
//#include <SDL.h>
class cGame
{
//audio
//video
//timing
//update
  //input 
  //map
  //sprites
  //scripts
  //states
  //numbers
//blueprints - use separate header files for all of the references?
  //player
  //pokemon
  //abilities
  //natures
  //moves
  //items
   //types
   //effects
   //names
   //descriptions
  //sprites
   //players
   //pokemon
   //efx
   //menu
   //statics
   //dynamics
  //audio
   //music
   //sfx
   //cry
//memory
  //map
   //boundaries
   //spritepositions
   //pokemon
   //player
   //npcs
  
public:
}
int main(int argc, char* argv[])
{
cGame GAME;
return 0;
}

This is what I have so far, it is sort of an outline.

Should I make separate classes for everything and allow the game class to access everything?
How should I go about creating instances and generating the world? Vectors for each entity that SDL will loop over?
I'm having a bit of a design crisis I suppose.

Sponsor:

#2 Radikalizm   Crossbones+   -  Reputation: 2984

Like
1Likes
Like

Posted 24 November 2012 - 07:54 PM

Maybe you should get familiar with object oriented design before you go any further, there are a lot of bad smells in that little bit of design you already have.
There are tons of good online references and tons of really good books on the matter, so I'd recommend you do some research on google and maybe on this forum as well.

Also remember that making a pokemon clone is not exactly legal, whether you're developing it for commercial purposes or not. I don't expect it to cause any trouble if you keep this project completely to yourself (I've done such a thing myself to be completely honest with you), but releasing it can potentially get you into trouble.

I gets all your texture budgets!


#3 Weajiin   Members   -  Reputation: 101

Like
0Likes
Like

Posted 24 November 2012 - 09:34 PM

Given your previous experience with OOP design, could you give me a very basic idea / outline of what it is that I should pay extra attention to when I do research it. Sometimes they have you on a wild goose chase when all you really need are a few core ideas.

#4 Radikalizm   Crossbones+   -  Reputation: 2984

Like
2Likes
Like

Posted 25 November 2012 - 08:33 AM

It seems you have a tendency to put too much responsibility in one class, creating so-called god classes.
There are two collections of principles you should get really familiar with if you want to write good object-oriented programs:

The first one is SOLID, which stands for:
  • Single Responsibility Principle
  • Open/Closed princple
  • Liskov Substitution Principle
  • Interface Segragation Principle
  • Dependency Inversion Principle (this one can be hard to grasp when you're just starting out though)

The second one is GRASP, which is an acronym for "General Responsibility Assignment Software Principles".

I'm not going to write up a full explanation of all the principles contained within GRASP and SOLID here as they are both really broad topics, but those links I provided should be enough get you started Posted Image

EDIT:

I want to add that these lists of principles are not a guarantee that you'll be writing the best and cleanest code, as they don't give you any definitive answers on what to do in every possible situation. Remember that these are guidelines, and they are meant to assist you in making decisions, but they won't always provide concrete answers.

Edited by Radikalizm, 25 November 2012 - 08:36 AM.

I gets all your texture budgets!





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS