Showing posts with label C#. Show all posts
Showing posts with label C#. Show all posts

Monday, December 31, 2012

Notoriously Databased v0.41

After a couple more play sessions there have been some more bugs to squish, some wierd strategies to rebalance and some UI recommendations to help smooth out the game's flow.

First off the list was to fix an abuse of the win condition by popping yourself over the notoriety limit for 2 turns in succession. I was sure i'd covered this by checking for a wipe on the winning turn, but it needed a check for wipes on the turn before as well to catch this devious little strat.

The turn submission screen also now has a notoriety list to help gauge where you are in relation to the notoriety limit and others. this has added a bit more informaiton at your fingertips to make your choice for next turn, but has also turned the submission screen into somewhat of a knowledge store for the game too. The recommendation to place the story on there is most likely as a response from relying more and more on the informaiton at hand rather than really reading and digesting exactly what's going on in the region.

To add the story to the submission screen I wanted to try a partial view so that the same information could be displayed there as well as in its current location. Because the view has already been set up I didn't think it would be too hard to turn it into a partial view.

It turns out that there are a number of different ways of making a partial view. What i really wanted was to call the same action that currently exists as it has a ViewModel and custom data gathering script already in place and a major part of what I didn't want to replicate, so calling the partial view using @Html.Action was the way to go.

After a couple of tests it turned out to be a fairly simple change:
 - Replicate CharacterCurrentStory into PartialCharacterCurrentStory in both the controller and view
 - Set PartialCharacterCurrentStory controller to return a PartialViewResult
 - Strip down PartialCharacterCurrentStory view to only show the table of messages fit for both views.
 - Strip down the old CharacterCurrentStory view to only show the headings and page setup
 - Call the PartialCharacterCurrentStory using @Html.Action()
 - Add the same call to the character submission
 - Strip down the old CharacterCurrentStory controller to only pass in the current character rather than the stories. 
 - Lock down PartialCharacterCurrentStory to only be called as a child action (probably not required, but handy to know)

Here's the end result for the controller:
        public ViewResult CharacterCurrentStory(int charID)
        {
            Character currentChar = db.Characters.Where(i => i.CharacterID == charID).SingleOrDefault();
            return View(currentChar);
        }


        [ChildActionOnly]
        public PartialViewResult PartialCharacterCurrentStory(int charID)
        {
            Character currentChar = db.Characters.Where(i => i.CharacterID == charID).SingleOrDefault();
            int currentStoryTurn = (int)db.Storys.Where(i => i.CharacterID == charID && (i.Turn.GameID == currentChar.GameID)).OrderByDescending(u => u.TurnID).FirstOrDefault().TurnID;
            var storys = db.Storys.Include("Character").Include("Turn").Where(i => i.TurnID == currentStoryTurn && (i.CharacterID == charID || i.isPublic == 1));
            return PartialView(storys.ToList());
        }

Sunday, November 04, 2012

Notoriously Databased v0.32

Another playthrough of NotoriouslyDB with Grieg and Sandy revealed yet another handful of bugs, but all were relegated to the bin by the time the night was out. I've even come up with an endgame of sorts that should fit in well with the style of game that it is.

End Game

I've tried to come up with a couple of viable endgame scenarios, but most either bred a deflated finish when one person pulled ahead in the power curve, or could be colluded a little too easily for my liking. The current endgame looks at sustained notoriety.

Each game will have a notoriety limit placed on it. Once somone passes this limit, they are eligible to win the next turn if they are not wiped and remain above the limit. Hopefully this should give people time to react against the current leader when they first break the win limit, but will become harder and harder to keep them (and eventually others) from winning.

From the playthrough tonight I'd expect a limit of 30-50 to be adequate as by then it feels like you have mastery over the village and can ramp up in power fairly easily. Lower limits will be more for advanced players as it will require more management to cram both the middle -> late phase transition and maneuvering for the end game into the same timeframe.

If it survives a couple more thought experiments, it should be relatively easy to implement and even automate.

Bounties

Another feature that made it into this revision was bounties. After a discussion with Andrew regarding the relative merits of the current system ("So, is it fun?"), it seemed that the game has become more than the testbed for high level play that I thought it would be. If the game were to be played in its own right, there needed to be another avenue to use treasure, especially when you know you are about to be wiped. I enjoyed having wipes "educate" people regarding the fleeting value of money compared to the real currency of space, but with bounties in place it feels like there is more of a multiplayer component, even if it's a "Hey! what was that for!" yelled out from the other side of the room.

Bounties are quite simple. Place a treasure amount against another player and that increases their notoriety by that amount next turn. The bounty is public, so that other can see not only who has the bounty, but who placed it too. I've been contemplating having a way to hide who placed it, but that will most likely be rolled into the Raid disguise update in the future. At least the variables are in place on the batabase to support it when the time comes.

 

Changelog

 - Added bounties.
 - Fixed attacks on other players
 - Fixed defense with both elites and minions
 - Fixed multiple player attacks on other players
 - Added notoriety list to CharacterSubmission to see other player's notoriety. (This will be to make the game more, well, gamey, and give better feedback for the endgame)


There is still an issue with fortifications. I'm leaning toward an increasing scale of costs as 5 treasure seems fine at the start, but too little at the end.


Thursday, August 23, 2012

Notoriously Databased v0.31

User Interface

After a couple of multiplayer experiments, the main feedback was that there isn't enough information to show you what's going on in the dungeon. Some of that was intentional, but some was just poor placement (or no placement) due to the lightweight nature I thought this game would have. Now that it's being tested, it's kind of cool on its own to see a dungeon developing. With that, I put a bit more effort into presenting the data.
  - Reading the character's story defaults to only the story rom the last turn so you don't have to keep scrolling down to the end of the story.
  - Redid the Character Submission to more clearly show dungeon state, and how space is allocated. Also added the village state and current defense ratio.
  - Removed a couple of Edit / Delete hyperlinks to turn it into a more consumer experience instead of a database.
  - Highlight public stories
  - More stories about how many minions / elites are surviving
  - Indicator of who is the most notorious and that they are the focus of heroes. 

Bug List

 - Elites not defending properly
 - spelling errors
 - Villages now appearing back in the village when ransomed / released
 - Hero focus on proper highest notoriety character


Sunday, August 05, 2012

Notoriously Databased v0.26

With the turn processing finished, Notoriously Databased was ready for limited testing. Unfortunately some conflicts with the online database made the LAN tests a bit of a flop, even though I'd been able to test a couple of turns myself locally. Debug phase ...

The first issue was that the cascade on delete that I'd set up locally hadn't been merged over very well. I tried fixing it with a diagram system, but it kept complaining about multiple cascade loops when it was only cascading downward from multiple parents. Wierd. It allowed it on manual update of the foreign key though.

Next issue was that partially filled submissions were causing null errors, so I zero'd out all the null fields at the start of processing. Later on I found out that Characters not submitting a turn was throwing errors too, so created a default blank submission for those. Some other small errors were isolated & fixed in a couple of hours.

Testing the turn processing was getting a little tedious when triggering the proces from the admin panel, so I moved it to the player's screen to keep it all together for now. It raised another problem I've been having with MVC and the modelessness of web design: there doesn't seem to be a built in way of returning back to the previous caller, rather it lets the currently active action determine where to go next. I can see why this might be the case, but it's such a radical shift from traditional functional design, I'm surprised that they haven't tackled it in some way. There are far more complex issues (like entity framework) that have been solved. Hopefully I'm just missing something simple, which is quite likely.

Another thing I wanted was a quick way to see the character's story.  Earlier changes to the controller and views made it quite simple to make a method receiveing the character's ID and only outputting those stories. Since it was only called from the player's screen, at least I didn't have to worry about the redirection on completion. Limiting the stories to those involving the character was one step, but I also needed to include all public stories as well. In SQL this would be a simple ID=x OR isPublic=1, but it took a while to figure out how an OR could be imoplemented. Many methods to do an AND, but only one looked like it could also be manipulated into being useful for an OR by simply using C# binary logic in the where() clause. It looks like Entity Framework does a nice job of processing the logic and converting it into an SQL statement. I haven't had to reduce entity framework to SQL queries just yet, although there have been a couple of wierd interfaces to do more or less the same job.

After the turn processing I thought it would be a good time so show the whole story of the turn to whoever processed it (as another debugging tool). Setting up another list was pretty easy, but unfortunately I couldn't trigger it easily with a RedirectToAction() passing a parameter to another controller, but it feels like returning to the Player's screen was a more concise alternative anyway, leaving individual turn debugging relegated to the admin panel.

It's feeling nice and solid. Now for some serious strategy testing ... 

With turn processing triggered of fthe admin panel, and