Topics

1

Programming / small fix

« on: July 08, 2010, 04:02:18 pm »

Last update didn't compile without this. I think there should not be "Game::", gcc don't accept it.

Code: [Select]

Index: Game.h
===================================================================
--- Game.h (revision 95)
+++ Game.h (working copy)
@@ -63,7 +63,7 @@
  https:/// Gets the game's display screen.
  Screen *getScreen();
  https:/// Gets the game's states.
- list<State*> *Game::getStates();
+ list<State*> *getStates();
  https:/// Sets the game's 8bpp palette.
  void setPalette(SDL_Color *colors, int firstcolor = 0, int ncolors = 256);
  https:/// Resets the state stack to a new state.
@@ -86,4 +86,4 @@
  void setRuleset(Ruleset *rules);
 };
 
-#endif
\ No newline at end of file
+#endif


2

Suggestions / Anti-suggestions

« on: June 25, 2010, 12:29:25 pm »

Don't implement any new features until you fully reimplement original game or at least big part of it such as geoscape.

Create separate programs for geoscape and battlescape.  Use the same file format as original X-COM.  This will let you replace one of the programs with original program running inside DOSBox.  Share source files between these programs.  Don't create shared libraries, just compile them from overlapping sets of source files.

Use less abstractions.

For example, you have "Soldier" class.  Most of it's methods just get and set private fields.  There is only one place in code that modify soldier's names, it can handle everything that is related to renaming so you don't really need "setName" function.  And nothing is calculated when you get name so you don't need "getName" method.  Just make "name" field public.

Also you have XcomRuleset that is based on Ruleset.  You don't really need more than one ruleset in one game, just create one "Ruleset" class and everyone will be able to modify it if they want to change rules of the game.

If you want others to be able to modify game engine, don't try to create bulletproof abstractions and don't add scripting engines. Abstractions don't let you fully modify game until you understand code behind them.  Scripting engines are even more limited.

There is already nearly 8k lines of code (and 15k if you count blank lines and comments).  This number can be greatly reduced by removing most of such abstractions.

I am just afraid I would not be able to modify code when you finish implementing bigger part of it.

3

Programming / Cleaned up Makefile

« on: June 24, 2010, 02:58:04 pm »

I have cleaned up Makefile.

Code: [Select]

PROG = openxcom
SRCS = $(wildcard *.cpp)
OBJS = $(SRCS:.cpp=.o)

CXXFLAGS = -Wall -O2 `sdl-config --cflags`
LDFLAGS = `sdl-config --libs` -lSDL_gfx -lSDL_mixer

$(PROG): $(OBJS)
$(CXX) $(LDFLAGS) -o $(PROG) $(OBJS)

clean:
rm -f $(PROG) *.o

.PHONY: clean

Current Makefile uses $(CC) instead of $(CXX). CC is a *C* compiler, not C++. C++ compiler is CXX. You have rule for "openxcom" but instead you build "OpenXcom". Names are case-sensitive on Linux. You have also wrote your own implicit rule, don't know why. And `sdl-config --cflags`should not be in $(LIBS) BTW.