Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
But it's just completely unnecessary, and adds complications. It also means duplicating certain code (General GUI widgets for menus and buttons etc.)You can share source files between programs.
As for the "openxcom" vs "OpenXcom" thing, the executables on other platforms are called "OpenXcom" so I figured I'd keep it consistent, but I guess it doesn't really matter.
That is a very bad idea:Engines are separated not for saving memory. Look at Worms, for example. They have separate GUI for options and "battlescape". It just simplifies program.
- Having a program split into pieces like that is just asking for trouble. Sure back in the day you needed to save extra byte of memory you could, but you have to manage information between programs yourself which is bothersome and error-prone, there's no proper way to handle one of the parts failing (when the X-Com Battlescape died, the Geoscape wouldn't notice and just use the last available mission results), and it just restricts the parts needlessly (you couldn't quit or load saves from the Battlescape because the Geoscape had to do that). Who knows if I won't later extend the game to a point that the Geoscape and Battlescape should be tied together.
- The community still hasn't fully reverse-engineered the game's file formats, so a lot of them still remain a mystery and it'd force me to have to wait around until I could use them. Plus the old file formats also bring a lot of old bugs and limitations with them like the "proximity mine bug", the various engine limits, and in the end it'd just restrict me from extending them and taking full advantage of a new engine.
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.Ruleset is probably a bit of a misnomer. In fact I still haven't set in stone what it really does, but there probably won't be many actual "rules" in there since an X-Com engine is an X-Com engine and there probably isn't a whole lot you wanna change without becoming a different game entirely. It probably won't contain gameplay features like whether
For now it's just a nice place to keep all the typically hardcoded numbers like craft stats, facility stats, item stats, weapon stats, research tree, etc. For example, as far as the engine is concerned, a craft is a craft and it has various properties and can contain weapons and soldiers and it can fly around intercepting stuff and going on missions. It's the ruleset that tells it there's a craft type X with acceleration Y and crew capacity Z and so on. Whether you call it a Skyranger or a Triton the engine will treat it just the same.
In any case, the reason there's support for "multiple rulesets" is people will probably wanna play around with these stats a lot, so I need to keep them fairly separate from the engine. The XcomRuleset has all the original game stats, but some people would probably prefer improved tanks and weapons like in XcomUtil. You might only have one ruleset in use by one game at a time, but the player might have a wide selection to choose from when they start a new game (kinda like mods). Hell, maybe they're a picky bunch and decide they want the "improved tanks" but not the "improved weapons", so you need to split the rulesets into bits so the player can pick multiple ones that get combined for them. That is the reason there's an abstract Ruleset, planning for the future.
How about just a "Undo/Rewind" move button?
Whilst on occasion I'll do this, it is looked upon as bad practice; it also means that should you want to enter any validation or cascading updates based upon the field, you'll have to reimplment the methods anyway. Example of the latter is if you want to set Arm Damage, you might want to cascade an update to Accuracy to decrease it, then you don't need to be constantly recalculating the value.You should not recalculate accuracy. Instead, when soldier shoot, you should calculate some kind of "effective accuracy" based on damage, state of soldier (sitting, standing, flying) etc. Maybe some fields should be private, but don't just do everything private.
Then just store these options inside "Ruleset". Currently it looks like we are going to have two or more rulesets at a time.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.I think it was in a news post, SupSuper was referring to a screen to toggle fixes/options on or off (before the game starts). I'm assuming that they will be implemented as rulesets. Could be wrong on this point though.
If code is small, it is not hard to rewrite part of it the way you want. It is easy to use abstractions as long as they are suitable for your ideas. But when they don't, you will need to rewrite a lot of code. Abstractions are ok, just don't use them everywhere. Game is going to be X-COM remake, not some abstract turn-based strategy.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.Have you ever worked with Unreal Tournament (the original, I don't know a lot about the others)? Abstractions are good, because you don't need to understand the code behind them. You just inherit the original (with code), and add/replace the bits with your new version.
As for scripting engines, well, if you break open the Unreal Tournament code, you'll find that almost every aspect of the game is scripting. Okay, so the script gets compiled before running, but it's still scripted.
In all, designing it in the way it's being done should actually make your life easier should you want to start hacking away at parts.
Sorry if this seemed a little negative. I think the structure of the code looks good, and will be more beneficial to hackers and modders with this approach.
As for not implementing new features until the original stuff is complete, I can see where you're coming from, but if you don't plan for some features, you may have to rewrite segments of code to add it in later. I think features do need to be thought about, even if they are not implemented at the time.
It would be great to have an option which, when enables, forces you to confirm any movement command.
Or if you could at least interrupt one of your soldiers while moving by pressing the right mouse button.
Might lessen the frequency of "wanted-to-select-soldier-but-made-other-move-instead" mistakes.
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