Closed GoogleCodeExporter closed 9 years ago
Original comment by Kai.Saerthen.Darker
on 16 May 2010 at 9:25
Original comment by Kai.Saerthen.Darker
on 16 May 2010 at 11:36
Original comment by Kai.Saerthen.Darker
on 16 May 2010 at 11:37
Original comment by Kai.Saerthen.Darker
on 14 Jun 2010 at 8:44
Original comment by Kai.Saerthen.Darker
on 4 Aug 2010 at 7:55
Хотелось бы знать сколько времени займет
эта фича. Если больше пары недель, то может
быть стоит передвинуть ее на майлстоун 0.8.
Original comment by Kai.Saerthen.Darker
on 11 Jan 2011 at 9:10
думается, что не сложно. пары недель должно
хватить.
Original comment by korn...@gmail.com
on 13 Jan 2011 at 9:47
Original comment by korn...@gmail.com
on 13 Jan 2011 at 9:48
Several save files are allowed. 6th item is no longer needed.
Original comment by korn...@gmail.com
on 13 Jan 2011 at 11:00
Shuffle command should keep seed too and be able to accept a seed.
Original comment by korn...@gmail.com
on 13 Jan 2011 at 11:46
done.
Original comment by korn...@gmail.com
on 14 Jan 2011 at 4:20
Save (GameState) consists of:
- REMOVE(id1, id2) cmd(s),
- SHUFFLE(seed) cmd(s),
- Chronometer timing,
- game type,
- layout name,
- hints' number,
- undos' number,
- difficulty.
Original comment by korn...@gmail.com
on 14 Jan 2011 at 5:15
and party seed, of course.
Original comment by korn...@gmail.com
on 14 Jan 2011 at 5:16
continue with State::gameInterface logic.
Original comment by korn...@gmail.com
on 16 Jan 2011 at 6:36
continue with special Game::start(seed, etc) function implementation.
Original comment by korn...@gmail.com
on 18 Jan 2011 at 6:16
don't forget to keep Layout in the state.
Original comment by korn...@gmail.com
on 18 Jan 2011 at 7:11
implement Game::setLayout(layout, dim x, y, z)
Original comment by korn...@gmail.com
on 18 Jan 2011 at 7:22
Game should report some GameState struct that will be keeping everything.
game::State will then be manipulating it to get/set values.
May be GameState should just be filled in by Game, not by game::State.
Original comment by korn...@gmail.com
on 18 Jan 2011 at 9:42
game::State should not be manipulating Game, instead, Game should be
manipulating game::State. game::State is only a container. Game has load/save
itself.
Original comment by korn...@gmail.com
on 18 Jan 2011 at 10:40
State commands should only be descriptions without execute field. so it seems.
Original comment by korn...@gmail.com
on 18 Jan 2011 at 11:46
May be game::Command's can actually store such commands too. I just need to
pass ID's to RemoveCommand instead of TileDesc's.
Original comment by korn...@gmail.com
on 19 Jan 2011 at 4:10
game::Command's now can write(std::ofstream&). proceed with Game::load/save
impl.
Original comment by korn...@gmail.com
on 19 Jan 2011 at 5:20
still, may be Game should not save *all* data like seconds nb it doesn't use.
may be it should not deal with it at all. may be Application should have
save/load.
Original comment by korn...@gmail.com
on 19 Jan 2011 at 10:17
keep in Game only related data.
Original comment by korn...@gmail.com
on 20 Jan 2011 at 4:30
the problem is in commands again. i need to find a way to describe commands in
Game::Desc. game::Command's won't work. mere descriptions are necessary.
Original comment by korn...@gmail.com
on 20 Jan 2011 at 4:39
decided to have Game::CmdDesc {type, id1, id2, seed}. the necessary field will
be taken depending on the type.
Original comment by korn...@gmail.com
on 21 Jan 2011 at 4:18
Game::getDesc returns Game class state.
Original comment by korn...@gmail.com
on 21 Jan 2011 at 6:23
i need to get layout name and chronometer timing, that's all the info for a
save.
Original comment by korn...@gmail.com
on 21 Jan 2011 at 9:32
continue Application::load.
Original comment by korn...@gmail.com
on 21 Jan 2011 at 2:41
loads fine what has been saved.
now implement save/load dialog.
Original comment by korn...@gmail.com
on 21 Jan 2011 at 5:40
also, update chronometer timing label right during load, not on next timer tick.
Original comment by korn...@gmail.com
on 21 Jan 2011 at 5:44
keep saves under saves/ directory where game.cfg is located.
Original comment by korn...@gmail.com
on 22 Jan 2011 at 6:21
think of save, load dialogs' structures.
Original comment by korn...@gmail.com
on 22 Jan 2011 at 6:50
there should be a single save/load dialog.
in there, we should have a list of already saved files.
saved file name is in format:
YYYYMMDD--HHMMSS--GameType--Layout--GameDifficulty.
one button automatically saves current game state.
the other button loads selected file from the list.
the third button removes selected file from the list (popping the "Are you
sure?" dialog).
Original comment by korn...@gmail.com
on 22 Jan 2011 at 10:06
created SaveLoad dialog. Save button looks related to the list of saves. this
is incorrect. i think we should keep Save button in Game only.
Original comment by korn...@gmail.com
on 22 Jan 2011 at 2:43
continue with Load dialog.
Original comment by korn...@gmail.com
on 23 Jan 2011 at 5:08
Load is somehow visible and does not respond to ESC.
Original comment by korn...@gmail.com
on 24 Jan 2011 at 5:16
use Load2 within GameTypeLayout to see if it's layout that's fucked up.
Original comment by korn...@gmail.com
on 24 Jan 2011 at 12:11
Load.layout used in GameTypeLayout isn't visible. mystery.
Original comment by korn...@gmail.com
on 25 Jan 2011 at 4:21
done. the mistake was because i added window, not layout, to the root sheet.
now add back btn.
Original comment by korn...@gmail.com
on 27 Jan 2011 at 5:20
fix btn size, hide bg & stop the game.
Original comment by korn...@gmail.com
on 27 Jan 2011 at 6:15
hiding bg and stopping the game requires rewrite of GUI architecture with new
one in mind (outside GUI class). this looks unnecessary. just fix the back btn
size.
Original comment by korn...@gmail.com
on 27 Jan 2011 at 7:07
GUI needs to references gui/Load (through gui/Sound), and gui/Load references
GUI. cyclic dependency.
The Listener interface should be redesigned and placed in separate files. May
be in Common.
Original comment by korn...@gmail.com
on 27 Jan 2011 at 9:40
create Listener interface with some convenient macro if possible.
Original comment by korn...@gmail.com
on 27 Jan 2011 at 9:41
ok. i remembered the problem. current macro MJIN_LISTENER not only allows to
define interface, but also add/remove/Listener functions. how to be without it?
Original comment by korn...@gmail.com
on 27 Jan 2011 at 9:42
2 macros are necessary.+
Original comment by korn...@gmail.com
on 27 Jan 2011 at 10:40
i want macro invocation like this:
MJIN_LISTENER(GUI,
virtual void guiButtonPressed(const Ogre::String &name,
const Ogre::String &text) { };
)
generate this:
class ListenerGUI {
public:
virtual ~ListenerGUI() { }
virtual void guiButtonPressed(const Ogre::String &name,
const Ogre::String &text) { };
};
Original comment by korn...@gmail.com
on 28 Jan 2011 at 7:35
done. fix all listeners now.
Original comment by korn...@gmail.com
on 28 Jan 2011 at 8:14
done. continue with Load dialog impl.
Original comment by korn...@gmail.com
on 28 Jan 2011 at 12:47
Save btn works. Now display the list of saves in the dialog.
Original comment by korn...@gmail.com
on 28 Jan 2011 at 2:47
Original issue reported on code.google.com by
Kai.Saerthen.Darker
on 16 May 2010 at 9:25