I am not quite sure I understand the plots, or more specifically, the arrows,
but I think I get the gist of what you are saying which is that we will
actually have a single play_controller class from which all others would
directly or indirectly be inheriteded from. I like the idea of the single
player controller being a special instance of a multiplayer controller, however
wouldn't that imply that playsingle controller should inherit from playmp
controller? Anyways, I think that this is a good idea and will try to keep my
stinking paws off of playturn.cpp and playlevel.cpp
Oh, and MP campaigns would be cool!
On Mon, 6 Mar 2006, Jörg Hinrichs wrote:
> Hello,
>
> when i did the new replay functionality, i had to duplicate quite a bit of
> code into the class replay_controller. I pushed this away a lot of times but
> i feel that it is about time to get rid of that and hopefully i will have
> some time to do it next weekend.
>
> I attached two uml diagrams to give you an imagination what i am after.
> Those of you who are familiar with uml may forgive me because these diagrams
> are a little bit "unusual" as they combine static and dynamic information. I
> hope this is the best way to carry the information, though. The new
> architecture has playmp_controller inherit from playsingle_controller. I
> might start differently and have it inherit from play_controller first,
> because there might be too many differences at the moment to already relate
> them like shown in the diagram. But in the end, like we discussed a couple
> of times, imo it would be best to have "single player" be a special case of
> "multiplayer".
>
> However, this means refactoring the architecture of gameplay completely and
> it will not be a minor change. To be honest there is some chances to break
> things and if i won't be careful there is a possibility that i lose track
> completely and will either have to start from scratch again or give up. I
> have done such large refactorings before, so i know how to deal with this
> best. But i am not perfect: It is likely but there is no guarantee to
> succeed with this at the first try.
> Therefore i suggest this: I will create the new classes and move the
> functionality into them step by step. I will not touch existing code in
> playlevel.cpp and playturn.cpp. The only thing in the "old" code that
> changes is 2 or 3 function calls within playcampaign.cpp, that can be easily
> redirected to the original destinations. So if i fail on this it will only
> take a lot of my time but not really screw up everything.
> If i go for it, i would like you not to make any changes in playlevel.cpp
> and playturn.cpp. For if you do, it has the potential to completely screw up
> what i am trying to do. I hope i can tackle this within a few days, from
> 10.03.2006 (3/10/2006) to 14.03.2006 (3/14/2006). If changes are badly
> needed within that time it would be best to contact me first and discuss it.
> Minor changes should not be too big a problem.
>
> There is one more nice thing besides getting rid of duplicated code and this
> motivates me even more: If i am not completely mistaken this architecture is
> a good first step towards mp campaigns. And guess what is one of the next
> things on my todo list... :-)
>
> Criticism or positive comments are welcome. If you see any reason not to go
> for this, please let me know.
>
> Greetings
>
> Yogi
>
--
-------------------------------------------------------------------
"In theory, theory and practice are the same,
but in practice they're different."
-------------------------------------------------------------------
John W. C. McNabb
-------------------------------------------------------------------
_______________________________________________
Wesnoth-dev mailing list
[email protected]
https://mail.gna.org/listinfo/wesnoth-dev
