Well today made for a rather eventful day. You might be wondering about the title, as it was, I had just finished a few commits worth of changes to my shell ruleset, when I accidentally “git push’ed” instead of “cg-push’ing” my changes up to the TP server. Biggest and most embarrassing mistake…ever. My small mistake pushed all my commits (I don’t mean just today, I mean like every one I have ever done) from my risk branch onto the main branch. Needless to say after a few minutes of crapping my pants I started working with my mentor xdotx to get things worked out.
While we had some ideas on how to get things fixed, from git-reverting to git-removing all my commited files from main, then commited the deletes, we ultimately decided to leave the beast lay as it was. I did, however, make on additional commit to the main branch that allowed it to compile properly.
Aside from my godzilla size mistake I did actually make progress today. I went over almost all of minisec’s “minisec” class and its “minisecturn” class, transcribing pseudocode of it to my existing ruleset as comments. It really helped to get a grasp of what was being used to make the ruleset work, and how my ruleset will work (as it is very different.) It also left me with a lot of questions (as can be expected.) I want to transpose more or less my scratch notes I kept while reading to be posed as questions for myself in the future, as well as my mentors:
- I noticed minisec goes pretty in depth for its naming system. If my map is static do I need to worry as much about that? Will I just be creating my map in a big set of statements, and not dynamically?
- On extending star system/planets: How to add a “connects to…” linked list for connectivity?
- Will every system be a star with one planet?
- Going over “minisecturn”: Do I need setFleetType and setPlanetType? Do I need containerids?
- Going over Ruleset-Docs: Does every ruleset need to have persistence out of the box?
In addition to thinking up more questions I also partially implemented my own Risk::onAddPlayers function. It was more or less practice for me in playing with some “game” and “settings” references/pointers. It is/should be functional however, restricting more than “risk_max_players” from joining a game, as well as disallowing players to join a game with all the territories claimed. At the moment I don’t see why any one would even want to join a Risk game mid-session, and that opportunity may be removed from the final product.
All in all I think it was a great day, besides the obvious screw up. Getting more “into” the code is letting me start to see how my final product will ultimately be implemented. I hope tomorrow is just as productive. I have to say though the prospect of “starting to code” on Monday is a little anti-climatic having started doing things early. That isn’t to say I wish I hadn’t done anything yet :P. Working from home is definitely a unique experience; all the motivations of working in an office are gone. You have to build your own positive reinforcements and motivation, heck you don’t even get the satisfaction of being anywhere special. Its been a challenge the last few weeks building a mental “office” in addition to a physical one.
xdotx | 25-May-08 at 12:45 am | Permalink
# I noticed minisec goes pretty in depth for its naming system. If my map is static do I need to worry as much about that? Will I just be creating my map in a big set of statements, and not dynamically?
## RFTS has a statically-named system. Just use a few helper functions for creating a system and make each one manually by name.
# On extending star system/planets: How to add a “connects to…” linked list for connectivity?
## internally in your planet/system class? Or do you want that information client-side visible?
# Will every system be a star with one planet?
## Iif you want it to be. Contained objects are completely optional for all things afaik.
I’m fuzzy on the other two. I believe you do need containerids though, and supporting persistence would be a good idea, though it shouldn’t be too important.