Another mini review of Path of Exile with respect to Notorious.
Hardcore characters in Path of Exile have an interesting characteristic in that when you die you don't just vanish, your character then becomes a standard (multiple deaths allowed) character. This is also in use for the various competition levels available in that once the competition is over, the character then becomes hardcore (if it was a hardcore competition).
Specifically for hardcore, this still gives the sting of losing a character for those dedicated to hardcore, but also gives those who want to play on an avenue for doing so. With respect to the competitions, the narrowed time frame and scope brings added incentive to try out new characters or restart the game again. This gives much more longevity to the whole ramp up that is typical of a diablo clone.
I'd always considered having valleys surrounding a starting village be somewhat contained to allow people of similar starting times to compete together (or at least gauge yourself relative to others) in the same way that Grepolis gives an island somewhat of an independent feel until ships open the map up. Now I'm leaning more toward having the valleys open up as the main payment method. Each player would pay a nominal amount of the 2nd tier economy to enter a valley that has a specific achievement and entry conditions associated with it. Once the valley has enough entrants, it opens up that part of the map and players are shielded from other notorious activity until the achievement has been reached by one player. This then opens up the valley to be part of the main world.
Types of requirements would be:
- New players
- Power level (Eg min power level 200)
- Previous achievement holders
- Notoriety in region
Since the valleys are also based physically on the map, there would also be added incentive to compete in valleys close to your starting location so that you can build up region wide notoriety easier. There can also be tiered access so that lots of small starter villages need to be conquered before there are provincial cities or regional capitals that are exposed to the map.
This concept could also be applied to whole regions rather than just valleys, and allow different playstyles to be rewarded through the specific criteria and conditions placed on that enclosed region.
Showing posts with label Notorious. Show all posts
Showing posts with label Notorious. Show all posts
Friday, April 11, 2014
Monday, February 24, 2014
Craft the World review for Notorious
review will be more of a reflection on how CTW adapts DF to a tighter, more zoomed-in play experience.
For one thing the dwarves don’t seem to generate as much character and affinity from the player. The dwarves each have individual names, look slightly different and have skill sets to make them unique, but they all just seem to mill around like ants doing their own chores. Even when selecting a dwarf when taking control, it’s easiest to just grab the closest dwarf for the task you want to do rather than specifically looking for somebody. Even swapping through the dwarves, it’s hard to see where they are on the screen. I find myself looking at the stats at the bottom and the activity they are doing rather than their location.
TAKEAWAY: Position is important for building affinity with the individual dwarves. If a minion card is selected in notorious, highlight (and center?) the minion on the screen.
Although you can give dwarves specific equipment, it feels somehow divorced from the task that they are doing. If I set out 8 squares to be dug out, I can potentially have 5 of the 7 dwarves appear to complete the task. In DF you can specifically assign a role to each dwarf and, due to possibly long term play & familiarity with the game, those roles can be very tight indeed. 1 dwarf is the miner, 1 dwarf is the carpenter and possibly the lumberjack. These are chosen before you embark and plays a significant role in success of your fortress for the first season. This raises the barrier to entry significantly because you need to know how to play the game before you start, but it raises your affinity with individual dwarves as you have crafted them personally and know what they should be doing. Continuing on from this, narrowing down the roles for new dwarves during the rest of the game raises the barrier to entry, but also increases affinity.
TAKEAWAY: When the number of minions is limited, assigning them specific roles adds to affinity. When the minion count increases, this can lead to a bogging down into micromanagement. In Notorious, the player can change a minion’s desire to dig and then designate generic digging locations, or they can increase the desire to dig at a specific location. With defence, a general raising of desire for defence will make the minion defend their home territory, whereas a targeted defence will make them defend a specific point. Multiple targets will give a patrol.
There doesn't seem to be any discernible difference in skilled dwarves performing any better than unskilled. This leads to a feeling of nonchalance about who is performing what task. There needs to be feedback on why the skills are important to make the player care about who has what skill. In DF, legendary miners are possibly 4 times faster and produce more spoil. This adds to the desire for sending the right dwarf to the task and gives incentive to investigate and learn the traits of each dwarf. In DF the dwarves also level up by performing the skill rather than skills being assigned by the player. This also adds to the incentive to keep specific dwarves on task.
TAKEAWAY: There needs to be a discernible difference when elevating an action.
GIFTING ITEMS
Another way to increase the player’s affinity with minions is to gift them items from the treasure. This can be done in a number of ways:
Gift – have a way for a specific treasure to be selected then gifted to the minion. This gives a 1 time happiness bonus & increases minion’s knowledge & affection of the player’s name. Note this can have a negative effect as the minion’s memory now has an imprint of the player’s name that can be discovered by other players.
Desire for reward – have a way for the player to transfer ownership of a treasure item to the minion but also associate it with activities they have completed. It may or may not be associated with your name. This gives a bonus to the activity that is being rewarded.
Raise the desire to take an item – there is a natural tendency for minions to have selfish desire for items that they see. Raising one of these desires for the selected treasure has no association with the player’s name or with an action. Note that assignment of ownership is controlled by each minion so an item can have multiple owners (leading to potential fights).
Give item back – have a way to drop the desire for an item so that they abandon it or possibly gift it to another minion. Can also gift back to treasury by raising benevolence of the player’s name.
Gifting items with gems attached and then imprinting the minion again will be one of the main ways to permanently lock in items and improve the minion.
Sunday, February 23, 2014
First the Worst play mat
Woke up yesterday with an idea to make the play mat for First the Worst . Still needs a little work (like adjusting the print to proper card size) but should help in playtesting.
Saturday, March 02, 2013
Notoriously Tomed 0.0.2
After a long deliberation about where to go next with Notorious, a few Roguelike Radios have peaked my interest enough to return to ToME as a dev environment for at least building out a single player experience, possibly more with web server integration.
First off, review the old code and see if it works on the new ToME 1.0.0 engine. Moving the code over was easy enough, but it immediately fails with a lua file error. Looks like all new spells from the summoner code I pinched now have particly effect associated with them. Finding and copying the code is simple enough. Great! It works!
Next is reviewing the development path laid out from a year ago. Even though the design has changed a bit, the next couple of steps still seem to be the same as they were back then. I should Google doc it to make the tracking a little easier.
I'd left the code with lighting issues. What I'd like is that any arbitrary minion or hero can be linked to and highlight the map regardless of where they are. Turns out that it was only a case of changing game.level.map:applyExtraLite to game.level.map:applyLite. The first code looked only for entities within field of view, whereas the 2nd applies the light regardless. Nice & neat.
Next is to turn the heroes onto the other side. They still should be visible if they are carrying gems. Looks like the faction setting allows membership, so removing it from player affiliation makes it work.
Next is to place the heroes at a distance. The target code doesn't seem to work very well, and I'm thinking it's due to the realtime nature of the game not having the targeting in the same turn as the summon. Might be worth more investigation later as some talents might need a target. Arbitrarily placing the point 5 tiles below and to the left is pretty easy though. When approaching them the temporary war hounds go after them pretty well.
Rather than the warhounds chasing down heroes then returning to me, lets see if they can be anchored to the point where they spawned to give them a 'home base'. Hmm, seems easy, but having great difficulty locking down a suitable structure. It looks like there's late binding (or no binding?) on variables as well as the ability to pass completely different structures to the same variable. This is making for some imploding bugs later on, and isn't boding well for robust code down the track. Might need to see if there's a way to make Lua a little more tightly bound.
After a look into Lua's tables, the way they have been used in ToME started to make a little more sense. There is some scary bits:
What .. the .. ?
.. Actually reading it again it's not as bad as I thought. They are using a,b & c as the keys, whereas I thought it was saying that "apple" is defined both inside and outside of the array.
Back to coding with a little more enthusiasm and after about 1 & 1/2 hours of digging into and around the problem, the solution was identical to what I had originally intended, I'd just applied it to the wrong summoning code :/.
Oh well, it still feels like time well spent getting to know the system. 4 hours all up to move the goalposts a little closer and get it to a more comfortable release point:
Notorious 0.0.2
First off, review the old code and see if it works on the new ToME 1.0.0 engine. Moving the code over was easy enough, but it immediately fails with a lua file error. Looks like all new spells from the summoner code I pinched now have particly effect associated with them. Finding and copying the code is simple enough. Great! It works!
Next is reviewing the development path laid out from a year ago. Even though the design has changed a bit, the next couple of steps still seem to be the same as they were back then. I should Google doc it to make the tracking a little easier.
I'd left the code with lighting issues. What I'd like is that any arbitrary minion or hero can be linked to and highlight the map regardless of where they are. Turns out that it was only a case of changing game.level.map:applyExtraLite to game.level.map:applyLite. The first code looked only for entities within field of view, whereas the 2nd applies the light regardless. Nice & neat.
Next is to turn the heroes onto the other side. They still should be visible if they are carrying gems. Looks like the faction setting allows membership, so removing it from player affiliation makes it work.
Next is to place the heroes at a distance. The target code doesn't seem to work very well, and I'm thinking it's due to the realtime nature of the game not having the targeting in the same turn as the summon. Might be worth more investigation later as some talents might need a target. Arbitrarily placing the point 5 tiles below and to the left is pretty easy though. When approaching them the temporary war hounds go after them pretty well.
Rather than the warhounds chasing down heroes then returning to me, lets see if they can be anchored to the point where they spawned to give them a 'home base'. Hmm, seems easy, but having great difficulty locking down a suitable structure. It looks like there's late binding (or no binding?) on variables as well as the ability to pass completely different structures to the same variable. This is making for some imploding bugs later on, and isn't boding well for robust code down the track. Might need to see if there's a way to make Lua a little more tightly bound.
After a look into Lua's tables, the way they have been used in ToME started to make a little more sense. There is some scary bits:
> t = { apple=5 } > a = "apple" > b = "apple" > c = "app".."le" > print(t.apple, t[a], t[b], t[c]) -- all the same value because there is only one "apple"! 5 5 5 5
What .. the .. ?
.. Actually reading it again it's not as bad as I thought. They are using a,b & c as the keys, whereas I thought it was saying that "apple" is defined both inside and outside of the array.
Back to coding with a little more enthusiasm and after about 1 & 1/2 hours of digging into and around the problem, the solution was identical to what I had originally intended, I'd just applied it to the wrong summoning code :/.
Oh well, it still feels like time well spent getting to know the system. 4 hours all up to move the goalposts a little closer and get it to a more comfortable release point:
Notorious 0.0.2
Thursday, January 03, 2013
Notoriously Databased v0.42
Few more modifications & bugfixes before the LAN tonight.
Enhancements:
- Moved equipping minions up in the turn processing order so you can equip and use minions immediately to raid / attack. This is to help late game when you need to be able to attack others in the current turn to prevent a win, whereas bounties cope quite well for dealing with players in the next turn.
Bugfixes:
- Check enough space for fortifications
- Check enough space for elites
- Check enough space for slaves.
- Fix elite only raids returning with 1 elite.
Enhancements:
- Moved equipping minions up in the turn processing order so you can equip and use minions immediately to raid / attack. This is to help late game when you need to be able to attack others in the current turn to prevent a win, whereas bounties cope quite well for dealing with players in the next turn.
Bugfixes:
- Check enough space for fortifications
- Check enough space for elites
- Check enough space for slaves.
- Fix elite only raids returning with 1 elite.
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:
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());
}
Tuesday, November 06, 2012
Notoriously Databased v0.40
After a couple more discussions, I'm happy enough to include a notoriety limit as an end game scenario. The implementation was relatively straightforward to include a notoriety limit and a check to see if any player has been over the limit in successive turns. Also decided to limit the submission of turns once there has been a winner as it's not that hard to reset the "completed" game if there is a consensus to play further. This also adds to the finality of the game as all that is left is to read the story produced.
Now that it's a game in its own right, the next step will be to break out the game creation into its own form, and then lock off the admin tab completely. There shouldn't be any need for people to get into the admin tab once the game gets going.
Now that it's a game in its own right, the next step will be to break out the game creation into its own form, and then lock off the admin tab completely. There shouldn't be any need for people to get into the admin tab once the game gets going.
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.
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 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.
- 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.
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
Notoriously Databased v0.30
Strategy tests
I feel confident that the turn processing is at a point where I can attempt to test individual strategies and see where they would lead in the main game.The Digger
The first strategy will be just a simple turtle that digs as much as possible. This will be the baseline to judge all the other strategies against as it will have the least amount of risk. If it is also sustainable without going through a wipe, then we'll have a big problem attempting to get the other strategies to eek out an advantage, so the first test is to see how far I can go before a wipe occurs, and also how long to get to, say, 10 spaces.Since the hero attacks are predictable from your current notoriety, the strategy will be to only leave enough minions behind to fend them off and dig with the rest. It may pan out to be better to drop the defense and go through a wipe rather than holding out on the defense right until the end. We'll see.
Run 1 - Always defend: 15 turns to reach 10 size. Not too bad, but there are a couple of places where treasure could be utilized either for elites or on fortifications.
Run 2 - Defend until defenders more than diggers: 13 turns to reach 10 size (10.8). Seems a little wasteful throwing 9 into digging when it was already on 9.9, but 10 size is just an indicator and I'd rather keep the tests consistent to the strategy for the long run. Start certainly seemed better, and no drawn-out sections of no digging.
Run 3 - 1/2 Defend using elites: Elites look Ok on the first turn, but then break horribly. More debugging.
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
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
Thursday, August 02, 2012
Notoriously Databased v0.25
So much for esxprecting a fairly easy process to get the turn resolution complete. It's been over 15 hours, but finally is taking shape. Lots of effort in outputting stories as they will be the main interface for players to see what happened, and lots of code comments. I think it's teaching year 12 IPT that has made me comment more. It's a good thing, but adds time ...
Quite happy how the whole process turned out. Now to debug and make the stories more visible and enable a simple of triggering an end of turn.
Resolution Phases
- Validate the turn
- Town Raids.
- Hero attacks on Dungeon.
- Attacks by other Characters.
- Returning trops.
Hero Attacks on the Dungeon
The main component of the game will be dealing with the escalating amount of heroes attempting to rid you from the world. in this section there's not too much to do. The Heroes' level will be dictated by the last turn's notoriety, or be found by a level 1 scout if no notoriety. The tricky part is absorbing the amount of damage to the fortifications and elites. I'd solved this earlier in the spreadsheet, but the different variable types made this a little interesting.Attacks by other Characters
When other characters attack, there is the chance that more than one will be attacking at the same time. If this is the case, they first all try to get past the fortifications, then combine strength to take on the dungeon. If there are any survivors they fight it out so that only one returns with the treasure. In the case of a draw (both sent the same amount of minions), the prisoners overpower them and escape back to the city. The outcome is that the dungeon is definitely wiped one way or another, and the attackers either havethe winning troops return or lose everything. Once again converting elite strength to overall strength and back again is a right royal pain, but having elites adds an additional way of spending money so I hope it'll be worth it.Returning Troops
The raiding parties and attacks on other dungeons come back in this phase. Since there are data models set up to hold the results of these raids, it's simply a case of looking for any relevant data and integrating it to the next dungeon state. There is also an opportunity to clean up the amount of minions ready for the next turn, dig out any new space, build any fortificaitons, or bring back the ransom.Quite happy how the whole process turned out. Now to debug and make the stories more visible and enable a simple of triggering an end of turn.
Thursday, July 12, 2012
Notoriously Databased v0.24
The interface for submitting a turn is more or less complete, and I'm happy with the progress of MVC in this design. The next thing to work on is the turn resolution itself. Since I'd completed most of it in the Google Doc version, I was expecting it to flow fairly quickly...
Resolution Phases
For this version I'll be breaking down the turn resolution into 5 phases.
Validate the Turn
The validation itself was pretty easy to set up as I'd already done the logic for it, but the main sticking point in this section was creating a function to update the story with any errors. The story table will mainly be used to tell the player what happened in a turn, but it will suffice to also be the error reporting section for validation. The function itself should be pretty easy, but where to put it?
After another chat with Andrew, I decided on using a StoryRepository in the Models. Even though it's not technically a Model, the utility function does in a way act as a conduit to the model, and will not be doing much else apart from formatting and saving the Story into a new record. I played around with null values to allow optional parameters and unknown IDs, but it was cleaner to simply force IDs by seeding the optional parameters.
Town Raids
Initially I was hoping for the amount of defenders to be proportional to the amount of attackers as they would be pulled in different directions to defend all the resources (or go only one way if only one attacker). In the Google Doc version I'd dropped it in favour of a simple ratio of defenders per resource becuase of difficulties calulating all town attacks at once, but now that I can process them any way I like, I'll still use the ratio for now because it turned out to be simpler to calculate whether your attack will workor not by analysing the village state from the previous turn. It seems a little too controleld at the moment and I'd like a little more randomness, but for this large scale test it should be fine.
Once the raid has been calculated, the successful minions will return in phase 5. I could possibly merge this phase down to there, or merge up into validation, but I'm really unsure whether the town raid will need a different calculation method in testing, so it should be better in a self-contained section. Doing this means that I need a way to hold all raid data until phase 5. With my new-found love of Models, I made up a new class to act as a memory storage unit for raid data. This way I can create them into lists and process in much the same way as if it were table data.
Resolution Phases
For this version I'll be breaking down the turn resolution into 5 phases.
- Validate the turn: If there are any commands that will not be possible, drop to the maximum achievable number (Eg 5 minions available and request 6 to dig = 5 digging)
- Town Raids: Calculate all attacks on the town. Initially the attacks were to occur simultaneously and impact on the amount of guards for that turn, but for now a simple ratio of defenders to resources will suffice.
- Hero attacks on Dungeon: Process all incoming attacks from the village.
- Attacks by other Characters: Any incoming attacks from other dungeon will occur after the hero attacks. This will allow for potentially easier attacks, but also potentially nothing if the heroes wipe it first. If there are multiple people attacking the same dungeon, only one will survive (or none)
- Returning trops: Any successful raids or ransoms or dungeon attacks come back. Any digging or fortification building is also completed if not wiped.
Validate the Turn
The validation itself was pretty easy to set up as I'd already done the logic for it, but the main sticking point in this section was creating a function to update the story with any errors. The story table will mainly be used to tell the player what happened in a turn, but it will suffice to also be the error reporting section for validation. The function itself should be pretty easy, but where to put it?
After another chat with Andrew, I decided on using a StoryRepository in the Models. Even though it's not technically a Model, the utility function does in a way act as a conduit to the model, and will not be doing much else apart from formatting and saving the Story into a new record. I played around with null values to allow optional parameters and unknown IDs, but it was cleaner to simply force IDs by seeding the optional parameters.
Town Raids
Initially I was hoping for the amount of defenders to be proportional to the amount of attackers as they would be pulled in different directions to defend all the resources (or go only one way if only one attacker). In the Google Doc version I'd dropped it in favour of a simple ratio of defenders per resource becuase of difficulties calulating all town attacks at once, but now that I can process them any way I like, I'll still use the ratio for now because it turned out to be simpler to calculate whether your attack will workor not by analysing the village state from the previous turn. It seems a little too controleld at the moment and I'd like a little more randomness, but for this large scale test it should be fine.
Once the raid has been calculated, the successful minions will return in phase 5. I could possibly merge this phase down to there, or merge up into validation, but I'm really unsure whether the town raid will need a different calculation method in testing, so it should be better in a self-contained section. Doing this means that I need a way to hold all raid data until phase 5. With my new-found love of Models, I made up a new class to act as a memory storage unit for raid data. This way I can create them into lists and process in much the same way as if it were table data.
Tuesday, July 10, 2012
Notorious Monetisation
Random thoughts on ways to monetise a Notorious server as we drove home from Mackay. I'm not a fan of secondary economies, but this might be a way to set one up with a clear distinction between in-game and out-of-game interactions.
"The Club"
As the players are ethereal beings ‘competing’ for notoriety in the game world, there exists a number of services for these beings to interact with directly through the ether. Most of these services revolve around trading information. For now I’ll call this “The Club”
"The Club"
As the players are ethereal beings ‘competing’ for notoriety in the game world, there exists a number of services for these beings to interact with directly through the ether. Most of these services revolve around trading information. For now I’ll call this “The Club”
- Provide
access to a gem: The club has people scouring the world looking for suitable
gems to link to. For a fee they will provide the location of an unlinked gem.
Price is dependent on both maximum power of the gem and the closest city size
and current dungeon layout. Possible selling methods:
o
Auction system with random gems being placed on
there with a price. 15% value to AH for player-listed gems.
o
New gems generated in clumps on the frontier
zones, with some generated in more settled locations for people to advance to.
o
Offer a static price to ‘locate’ a new gem. ~$1
for a village level gem to ~$5 for a capital gem
.
- Player
power graphs: For a very small cost, players can see power graphs of other
players. It should indicate long & short term notoriety. From this players should
be able to deduce the best time to attack that player. Inactive players should
have a fairly regular graph. Active players should show advancement in fits
& spurts.
- Player
dungeon layout/minions. For a small fee, players can look up the last known
dungeon layout of the target player with possible minion information.
- Possible
black market for minions. Include minions that are already linked with gems.
This service provides access to the gem and possibly free teleportation to the
home stone. Minions bought this way may or may not know of the existence of the
ethereals. New gem keepers can be picked up this way.
o
Player auctions – additional 15% added to them
o
Football manager contract system opening payment
goes to either the originating player or the “Club” if newly generated. Once
the initial price is agreed upon it allows access to talk directly to the
minion to negotiate. Once the 1st negotiation for a minion has been
set, give 5 mins for competitive bids.
o
Possible alternative is that once a price is
settled upon with the original owner, they give access to the minion’s gem for
a non-refundable fee
o
Look at introducing a ‘trade band’ that has a
gem inside it specifically for talking to minions to set up contracts. Original
owners would then pick up a trade band from The Guild and place on minion. All
discussions and memories are then accessible through the new band. The Guild can
then use these to monitor the trade, set up filters of likely candidates to
accept a trade, and give independent information regarding the minion to the
buyer.
Multiple dungeons
An auction house would potentially mean having multiple gems
for the player to link to. Look into whether only 1 is active with an interface
to select the next active gem or have multiple gems active at the same time.
- If multiples active want so it is beneficial to have gems
in better places.
- ways to mitigate gem spamming. If pay a power maintenance
cost to link to a gem, maint cost increases by the amt of gems linked to. Eg: an inactive
gem 5 power, 1st gem 50 power, 2nd gem 100, 3rd
150, etc.
- potentially have 1st home gem link for free. Look
into a base amt of power for characters
Skills
Players may have the opportunity to tailor their character toward a certain playstyle:
Players may have the opportunity to tailor their character toward a certain playstyle:
- To
mitigate the multiple home gem links cost
- Mitigate
multiple gem links to monsters
- Decrease
costs of scanning
- Decrease
hiding/masking costs
- Raise
base power
Information tracking
Use roguelike monster info (observed weapons / damage / HP etc) for what they know about your minions. This will be
used in knowledge discovery for the “Club”.
Resurrection
If creatures are resurrected at the home stone with nothing
on them, how do they maintain the gem for communication?
- Make
the equipment they are carrying when bound be brought back too.
o
This would be the same as WoW / EVE and expected
of the NPCs In the city. Problem with this will be NPC heroes would not bring anything into the dungeon to drop.
- Make
equipment that has gems attached also returnable.
o
This would give the minions and NPCs a reason to
desire gemmed items.
o
Requires the Ethereal to pay an additional fee
to link to gemmed items? Maybe a link for returning purposes is not as strong
as a link for communication.
o
Look into linking gemmed items to the minion /
NPC. This way any binding of the minion / character will also include the cost
of the items.
o
If an item can be returned to a home stone, what
would happen if another Ethereal managed to establish a link to the item? Could
they return it to their own dungeon?
o
Gems allow access to sentient thoughts, so there
would be nothing to link to in the items themselves. Maybe a cost to return the
item itself is cheaper.
o
Once a link is established with a mind, maybe
other close gems can be added to the link for a minimal cost to strengthen the
link (allow more power). New items linked this way don’t add to the total gem
linking increases, but have an independent power cost escalation. Eg 50 power
for original link, 5 power for secondary, 10 for tertiary, 20, 40, 80. Items
linked this way must be strong enough in their own right to support the link.
Running a City
- Have
a high amount of NPC Heroes linking to your home stone.
o
Require a different build, with attributes
heavily focused on new minion link reduction to cope with the amount coming
through. Possibly too much for more than one stone’s worth.
o
Access to NPCs, but virtually no power left to
manipulate them.
- Charge a service fee for the resurrection
power that you will need to use to pull them back. This will typically be
through a front man, quite possibly a reputable person established in the city,
or a gemkeeper working undercover.
- Use
access to NPC heroes to sell dungeon layout / minions back to “The Guild”
o
Offer NPC heroes an in-game reward for
information regarding layouts / minions / etc.
o
Offer NPC heroes information on layouts for a
fee (miniature version of “The Guild”)
- Use
access to Heroes to sell their links to the club for people wishing to raid
targets
o
Make up bounties for certain dungeons with
potential upfront payment, confirmed wipe payment and loot division options.
- Act
like the “Adventurer’s Guild”
o
Branding all services as part of a corporate
entity provides all players that run individual sites to share the power.
o
New Adventurer’s guilds can be set up in the
city by paying for a large enough gem to be moved into place (and secured, they
are rather expensive in the game world too. Wouldn’t want anyone walking away
with your home base.
o
Run by exclusive members of “The Guild”
- Power
mainly generated from “good” thoughts about the owner. “Good” thoughts ½ as
effective as fear thoughts and reputation harder to maintain. Also less amount of population concerned about the service (adventurers) compared to the impact of character actions (whole city/village)
o
Good rep mutually exclusive to bad rep. linear linked scale.
Wednesday, June 27, 2012
Nototriously Databased v0.23
With the Admin panel finished, it's time to start working the the player's UI. Ideally I'd like the user to log in and go directly to a list of all his characters in the various games. From there they should be able to:
- submit new turns
- view the results of the previous turn
- view their current dungeon state
- view old turns
- view public information for the whole game
PlayerController
Off to build a new controller. Most of the UI will be the same as the CharacterController for now, so it's a good one to pinch. Pretty easy < 2mins.
Limiting PlayerController
Looks pretty good, but is showing all characters, not the currently logged in user's characters. Since I haven't created the link between User and Account, I'll leave that for now and see if I can limit the list to a single ID.
After a number of false starts, it seems that grabbing everything from CharacterController wasn't as good as grabbing the extensions I did on UserController's edit action. Changed it over so that I could pass in a User model that is limited to the single ID and includes Characters.
Currently Logged In User
The intenetion of using the ASP.NET default account management was to make sure passwords etc were handled a little more securely than if I did it myself. The upshot of that choice meant that I'd make a User table that shadowed the account and use it to link all the game data to. Since I'd successfully added other tables when generating the creation of games, I set about modifying the AccountController to also give me a User record if they successfully registered.
Username and email were simple as they already existed in the Register action, but I'd also wanted to link the user table to the account using the guid. Try as I might, the standard code to return the logged in user's Id simply returns null:
It would have been nice getting the account ID, but I'll have to suffice with the username. It'll be a little less secure, but fine for the scope of this little project. User record created and working!
Limiting to Logged In User
There should now be a User record for each account, and since the "User Info" page isn't visible until someone logs in, all I need to do now is find a way to get the current user. While searching for a way to get the account ID, there seemed to be a number of ways to get the current account name, so dropping back to username rather than ID has made this step rather easy:
Now that the page is working moderately well, I spent a little bit of time to rewrite the intro and remove / reword the character list fields to make it cleaner. All ready to make the submission...
Custom Data
For the next section I'll need to pass in some custom data to tell if the character is ready to submit a turn for their game. I might be able to do it in the view, but I confirmed through Andrew that it's definitely the controller's job to collect and prepare that sort of stuff. So how do I get it to the view when I am already passing in the User model along with associated Characters?
It seems that I need to create a separate model specifically for the view and pass in only the information that the view needs to display. I don't need all the Character fields, I do need some other fields from DungeonState and Game, and I also do need some custom variables to tell whether the turn needs to be submitted (or changed).
With Andrew's help, I made up a new ViewModel specifically for the Player controller with all the character information added as another class. In the end it felt more like creating a view in SQL from related data, but I could construct almost anything to put in there. A little bit of pre-work for a much more simple and clean implementation. I like it.
Now that the custom ViewModel is in place, I have to redo the way the Character table is laid out on the view. It needed a change anyway as I also took the opportunity to bring in all the data I'm expecting to show, as well as the IDs for all the relevant actions.
- submit new turns
- view the results of the previous turn
- view their current dungeon state
- view old turns
- view public information for the whole game
PlayerController
Off to build a new controller. Most of the UI will be the same as the CharacterController for now, so it's a good one to pinch. Pretty easy < 2mins.
Limiting PlayerController
Looks pretty good, but is showing all characters, not the currently logged in user's characters. Since I haven't created the link between User and Account, I'll leave that for now and see if I can limit the list to a single ID.
After a number of false starts, it seems that grabbing everything from CharacterController wasn't as good as grabbing the extensions I did on UserController's edit action. Changed it over so that I could pass in a User model that is limited to the single ID and includes Characters.
User user = db.Users.Include("Characters").Single(u => u.UserID == 1);Took a couple of hours of wrong turns and dead ends to get there, but at least it's working and looks pretty clean and simple. Now to change it to the logged in user...
return View(user);
Currently Logged In User
The intenetion of using the ASP.NET default account management was to make sure passwords etc were handled a little more securely than if I did it myself. The upshot of that choice meant that I'd make a User table that shadowed the account and use it to link all the game data to. Since I'd successfully added other tables when generating the creation of games, I set about modifying the AccountController to also give me a User record if they successfully registered.
Username and email were simple as they already existed in the Register action, but I'd also wanted to link the user table to the account using the guid. Try as I might, the standard code to return the logged in user's Id simply returns null:
Guid userGuid = (Guid)Membership.GetUser(User.Identity.Name).ProviderUserKey;I'm assuming that the Register action has just created the account and they haven't actually logged in until exiting the action.
It would have been nice getting the account ID, but I'll have to suffice with the username. It'll be a little less secure, but fine for the scope of this little project. User record created and working!
Limiting to Logged In User
There should now be a User record for each account, and since the "User Info" page isn't visible until someone logs in, all I need to do now is find a way to get the current user. While searching for a way to get the account ID, there seemed to be a number of ways to get the current account name, so dropping back to username rather than ID has made this step rather easy:
User user = db.Users.Include("Characters").Single(u => u.Username == User.Identity.Name); // assign currently logged in userTidy up
return View(user);
Now that the page is working moderately well, I spent a little bit of time to rewrite the intro and remove / reword the character list fields to make it cleaner. All ready to make the submission...
Custom Data
For the next section I'll need to pass in some custom data to tell if the character is ready to submit a turn for their game. I might be able to do it in the view, but I confirmed through Andrew that it's definitely the controller's job to collect and prepare that sort of stuff. So how do I get it to the view when I am already passing in the User model along with associated Characters?
It seems that I need to create a separate model specifically for the view and pass in only the information that the view needs to display. I don't need all the Character fields, I do need some other fields from DungeonState and Game, and I also do need some custom variables to tell whether the turn needs to be submitted (or changed).
With Andrew's help, I made up a new ViewModel specifically for the Player controller with all the character information added as another class. In the end it felt more like creating a view in SQL from related data, but I could construct almost anything to put in there. A little bit of pre-work for a much more simple and clean implementation. I like it.
Now that the custom ViewModel is in place, I have to redo the way the Character table is laid out on the view. It needed a change anyway as I also took the opportunity to bring in all the data I'm expecting to show, as well as the IDs for all the relevant actions.
Monday, June 25, 2012
Notoriously Databased v0.22
The next objective is to build an administration panel to link all the table controllers to. This will allow quick access to the game's internals in case the proper game fails.
- Added an AdminController with a simple list of table links.
- Tested all links and found that CharacterSubmission controller failed due to pluralisation issues.
- Fixed CharacterSubmission to CharacterSubmissions in the db, and rebuilt the model and controller.
- Located the creation of game objects and added code for creating a new Turn object once successful
- Reviewed changing ID fields for the new record, but it looks like it does that automatically once saved.
- Reviewed adding linked GameID fields from the original object. Does it pick up what the new ID field is once added? Yep, fantastic. Nice and easy.
- To check that all the IDs are working, I redid the display view for Turns. Entity Framework is a treat for getting related data out.
- Formatted GameDate to Now() until I know when the game will be pitched at.
- Added VillageState object, linked to the current turn, and saved.
Friday, June 22, 2012
Notoriously Databased v0.21
Now that the tables and relationships were mapped out on paper, I then put them into a fresh database. Pretty easy after finding out some autoincrement foibles in the previous testing. 8 tables in all:
Users will have Characters inside each Game. The Characters will have CharacterSubmissions for each turn in what to do with their dungeon, which, once processed, is stored as the DungeonState. The Game will also revolve around a single village, that has VillageStates stored for each Turn.
(Almost elemental facts, but meh ...)
Generating the App
Next step was to create the new MVC3 C# app. There were a number of steps that I needed memory jogging on, but I finally got the app set up with the database brought in by adding an ADO.NET Entity Data Model class to the Models directory.
Account Control
The standard template came with ASP users and login hooked into a separate db, and not having to recreate login scripts and password obsfucation seemed like a good thing so I set about attempting to integrate it. Since the final version will be hosted online in AppHarbor using only one database, it seemed logical to bring all the ASP database tables into my own db and possibly link into the User table.
After some research it turns out that placing relationships onto the aspnet_user table is a bad thing in the long run, so I left the original tables as they were and added another field to handle linking to the unique ID. Hopefully I'll be able to link them together using API calls once the whole thing gets going. Creating the aspnet_ tables was relatively easy with aspnet_regsql , and apparently there's a lot more stored procedures that I would have missed if I tried to bring it over from the generated db file.
Once the db's had been merged, the next thing was to get the models to be merged. After a little bit of frustration, it seemed that the AccountModels didn't like accessing the aspnet files under the entity data model, so it was easier in the end to leave the connection string as a separate connection adressing the db with a simple SqlClient. The future problem will be that once I move it all to AppHarbor, it will only migrate one of the connection strings internally, so I'll have to manually update the ConnectionString to permenently point to the online db. Shouldn't be too much of a drama as there's not going to be much separation between production and testing.
Adding Controllers
User accounts complete! Adding controllers for the new tables worked relatively well once I figured out that the Data context class it was after was the complete NotoriousEntities class. Since I had added and removed it a couple of times, I had to restart VS 2010 to get it to pick it up. I'd heard that I should be able to refresh the database if it changed (because dropping the entity model and recreating is a pain) and once you double-click on the edmx file you can 'Update Model from Database..' from the NotoriousModel. Tested and working MUCH better.
Moving to AppHarbor.
I followed the general instructions to set up the new application, but finding the git info still needed a visit to the knowledge base. After previous tests with local git, I'd settled on integrating it into VS 2010. Right click on the entire project in the project tree enabled me to start up a local git instance, then update it either with the Git Pending Changes addon, or straight to Git Bash. The shell will eventually be more useful, as once the remote git is set up I'll be constantly running the update and push commands. Update is nicer in the addon, but I can't see a push.
AppHarbor with SQL.
It was easy to pick the free SQL shared server, but finding the details of the server to manually connect once again seemed harder than I remembered. There some new configuation variables that indicated a different method for connecting, but I finally found the options I needed by going to the SQL server. The connection string is going to be the main one to the entity model, and because of that it also needed the resource metadata to complete the connection string rewrite. After looking at the output, I pinched the ConnectionString data for the server itself and placed it over the account model connection. Seems to be working, but getting errors. Doh! no tables!
Once connected using SQL Server Management studio, the next task was to get all of the tables across. From the local database I could run a 'Generate Scripts..' task and point to all the tables. Hopefully the aspnet tables will be fine coming across as I'm pretty sure I won't be able to run aspnet_regsql over on the server.
Databases look good, but running the app looks like there's still issues. No stored procedures. Looks like I can output generation instruction for all stored procedures as a script in itself, and with a bit of massaging I got it to work. Now I need a schema :/.
Looks like I can get all the elements from generating scripts, so back to square one. Generating the complete database brings in too much database specific changes, so I tried picking all the items instead. Some ALTER ROLE scripts were ging to fail, but the rest seemed Ok so I merged them and manually added the role members using the GUI.
Still having issues with the schema, stating that it's an older, incompatible version; a task for another day ...
EDIT: After a bit of Googling, it seems that the schema was fine, just aspnet requires some data to validate against. A quick merge of aspnet data files and it's all working. Now to build an integrated admin panel for manipulating the game data directly...
Users will have Characters inside each Game. The Characters will have CharacterSubmissions for each turn in what to do with their dungeon, which, once processed, is stored as the DungeonState. The Game will also revolve around a single village, that has VillageStates stored for each Turn.
(Almost elemental facts, but meh ...)
Generating the App
Next step was to create the new MVC3 C# app. There were a number of steps that I needed memory jogging on, but I finally got the app set up with the database brought in by adding an ADO.NET Entity Data Model class to the Models directory.
Account Control
The standard template came with ASP users and login hooked into a separate db, and not having to recreate login scripts and password obsfucation seemed like a good thing so I set about attempting to integrate it. Since the final version will be hosted online in AppHarbor using only one database, it seemed logical to bring all the ASP database tables into my own db and possibly link into the User table.
After some research it turns out that placing relationships onto the aspnet_user table is a bad thing in the long run, so I left the original tables as they were and added another field to handle linking to the unique ID. Hopefully I'll be able to link them together using API calls once the whole thing gets going. Creating the aspnet_ tables was relatively easy with aspnet_regsql , and apparently there's a lot more stored procedures that I would have missed if I tried to bring it over from the generated db file.
Once the db's had been merged, the next thing was to get the models to be merged. After a little bit of frustration, it seemed that the AccountModels didn't like accessing the aspnet files under the entity data model, so it was easier in the end to leave the connection string as a separate connection adressing the db with a simple SqlClient. The future problem will be that once I move it all to AppHarbor, it will only migrate one of the connection strings internally, so I'll have to manually update the ConnectionString to permenently point to the online db. Shouldn't be too much of a drama as there's not going to be much separation between production and testing.
Adding Controllers
User accounts complete! Adding controllers for the new tables worked relatively well once I figured out that the Data context class it was after was the complete NotoriousEntities class. Since I had added and removed it a couple of times, I had to restart VS 2010 to get it to pick it up. I'd heard that I should be able to refresh the database if it changed (because dropping the entity model and recreating is a pain) and once you double-click on the edmx file you can 'Update Model from Database..' from the NotoriousModel. Tested and working MUCH better.
Moving to AppHarbor.
I followed the general instructions to set up the new application, but finding the git info still needed a visit to the knowledge base. After previous tests with local git, I'd settled on integrating it into VS 2010. Right click on the entire project in the project tree enabled me to start up a local git instance, then update it either with the Git Pending Changes addon, or straight to Git Bash. The shell will eventually be more useful, as once the remote git is set up I'll be constantly running the update and push commands. Update is nicer in the addon, but I can't see a push.
AppHarbor with SQL.
It was easy to pick the free SQL shared server, but finding the details of the server to manually connect once again seemed harder than I remembered. There some new configuation variables that indicated a different method for connecting, but I finally found the options I needed by going to the SQL server. The connection string is going to be the main one to the entity model, and because of that it also needed the resource metadata to complete the connection string rewrite. After looking at the output, I pinched the ConnectionString data for the server itself and placed it over the account model connection. Seems to be working, but getting errors. Doh! no tables!
Once connected using SQL Server Management studio, the next task was to get all of the tables across. From the local database I could run a 'Generate Scripts..' task and point to all the tables. Hopefully the aspnet tables will be fine coming across as I'm pretty sure I won't be able to run aspnet_regsql over on the server.
Databases look good, but running the app looks like there's still issues. No stored procedures. Looks like I can output generation instruction for all stored procedures as a script in itself, and with a bit of massaging I got it to work. Now I need a schema :/.
Looks like I can get all the elements from generating scripts, so back to square one. Generating the complete database brings in too much database specific changes, so I tried picking all the items instead. Some ALTER ROLE scripts were ging to fail, but the rest seemed Ok so I merged them and manually added the role members using the GUI.
Still having issues with the schema, stating that it's an older, incompatible version; a task for another day ...
EDIT: After a bit of Googling, it seems that the schema was fine, just aspnet requires some data to validate against. A quick merge of aspnet data files and it's all working. Now to build an integrated admin panel for manipulating the game data directly...
Friday, June 08, 2012
Notoriously Databased v0.2
After discussing with Andrew the benifits of MVC3 and AppHarbor, I was finally convinced that it was the way to go for the next step of developing Notorious. Hopefully it will allow a little more freedom in testing as I'll be able to fully automate the process and serve it up as a web app rather than Google Doc forms. Been a pretty long journey to get all the setup in place:
- Looks like I'll need MVC3, EntityFramework, and AppHarbor testing
- MVC3 needed Visual Studio 2010 sp1. (250Mb)
- Downloaded Windows Platform Installer to speed up the process. It was able to get most, but not entity Framework.
- Tested MVC3 apps locally.
- Downloaded GIT and merged local app to cloud
- Needed to move data over to SQL, so downloaded 2012 SQL Management studio (600Mb)
- Needs Windows 7 sp1, so it and another ~100 windows updates later ..
- Management studio didn't seem to work by itself, so decided to move to 2012 express as well (200Mb)
- Installed and running, and apparently management studio 2012 now magically works.
- Played around with developing tables, and then merging them into MVC using entity frameworks. Lots of guidance by tutorials as this was not obvious. Eventual model first approach seems pretty slick rather than building LINQ.
- Merged to cloud and then needed to figure out cloud connection. I could see the db fine in Management studio using the given user / pass, but couldn't connect to it using the app. finally figured out that it's rewriting the connection string itself. All I needed to do was to provide an alias to the model's connection string and also the resource metadata. 5 hours :/.
- Looked at merging the data in case I neded to to that later on, but couldn't get a nice, simple way to do it across servers (I'm pretty sure the apharbour user doesn't have the right privelages for most options)
- Ready to go!
3 days to get into a position to develop, and possibly 20 hours. Most of that was waiting for downloads, so maybe 8 hours in watching tutorials and testing stuff.
With all the tucked away, I spent 1/2 hr designing the table layout for the new NotoriouslyDatabased app. After building the guts of it on Google Docs, it's going to be pretty easy to convert the logic, but the file layout changes might mean a different approach is possible.
- Looks like I'll need MVC3, EntityFramework, and AppHarbor testing
- MVC3 needed Visual Studio 2010 sp1. (250Mb)
- Downloaded Windows Platform Installer to speed up the process. It was able to get most, but not entity Framework.
- Tested MVC3 apps locally.
- Downloaded GIT and merged local app to cloud
- Needed to move data over to SQL, so downloaded 2012 SQL Management studio (600Mb)
- Needs Windows 7 sp1, so it and another ~100 windows updates later ..
- Management studio didn't seem to work by itself, so decided to move to 2012 express as well (200Mb)
- Installed and running, and apparently management studio 2012 now magically works.
- Played around with developing tables, and then merging them into MVC using entity frameworks. Lots of guidance by tutorials as this was not obvious. Eventual model first approach seems pretty slick rather than building LINQ.
- Merged to cloud and then needed to figure out cloud connection. I could see the db fine in Management studio using the given user / pass, but couldn't connect to it using the app. finally figured out that it's rewriting the connection string itself. All I needed to do was to provide an alias to the model's connection string and also the resource metadata. 5 hours :/.
- Looked at merging the data in case I neded to to that later on, but couldn't get a nice, simple way to do it across servers (I'm pretty sure the apharbour user doesn't have the right privelages for most options)
- Ready to go!
3 days to get into a position to develop, and possibly 20 hours. Most of that was waiting for downloads, so maybe 8 hours in watching tutorials and testing stuff.
With all the tucked away, I spent 1/2 hr designing the table layout for the new NotoriouslyDatabased app. After building the guts of it on Google Docs, it's going to be pretty easy to convert the logic, but the file layout changes might mean a different approach is possible.
Friday, December 30, 2011
Notoriously Databased
Over the holidays I've been building a google spreadsheet along with some forms to play a light version of Notorious. A play-by-email if you will. The game is intentionally stripped down as far as I can go while still retaining the higher design elements to test whether there is still any 'fun' or 'game' there. If there is, remove more. If there isn't, add some back in.
Notoriously Databased
Dungeon stats
At the start of each round, your dungeon is essentially a couple of stats:
Notoriety: How much the town fears you. Expect an attack each turn at a level based on this number.
Treasure: The amount of gold / equipment / tradeable stuff you have in your dungeon
Dungeon size: The amount of space dug out so far.
- Minion living space: Amount of space dedicated to housing minions
- Prisoner Space: Amount of space dedicated to housing townsfolk to help dig. Prisons can hold 10 prisoners per space.
- Fortification space: Amount of space for traps / secret doors / dungeon layout.
Total defense: Total defense = Dungeon security + Minion security
- Dungeon Security: Provides additional defense, as well as maintaining this amount of gold if a wipe occurs.
- Minion Security: Total amount of security offered by elites and normal minions.
Minion Defenders: Amount of minions allocated to defence.
Minion Elites: Elites are 2x more effective at fighting (Defending / raiding)
Minion Diggers / Builders: Amount of minions allocated to expanding your dungeon size.
Prisoners: Amount of captured townsfolk currently expanding your dungeon size.
Actions
Each turn a player assigns these actions to their dungeon:
Order digging: Amount of minions ordered to dig instead of defend
Raid town for treasure / prisoners: Choose the amount of minions to send on the raid and the amount of treasure / prisoners to go after. Monsters on a raid will not be in your dungeon next turn. If successful, returns the amount of treasure / prisoners requested. Can choose to disguise as another player to give them the notoriety instead. Raid success is calculated by the amount of town security compared to the amount of monsters sent. The town's prosperity will indicate how deep into the town they will need to go to get the required resources.
Raid another dungeon for treasure / prisoners: Choose the amount of monsters to send on the raid. They will not be in your dungeon next turn. Note that dungeon raids happen AFTER heroes have softened them up.
Ransom prisoners: You will receive 1 treasure per prisoner ransomed and reduce notoriety.
Increase fortifications: Requires 1 space and 5 treasure
Equip Minion: Requires 1 treasure per minion converted to an elite. Elites fight 2 times better and are last to be killed.
Hide Hide this many elites. Implemented as raiding 'no-one'. They just spend time away from the dungeon when you expect a wipe.
End of Turn resolution order
Hidden minions / treasure are set aside
Raiding parties are set aside
Ransom prisoners - Remove prisoner.
Convert minion to elite
Assign minion diggers
Increase fortifications - Remove money
Raid town - Add ALL player town raids together to calc total desired resources
Raid town - Calc defense per treasure and per villiager
Raid town - Assign defense to each player's raid and kill off raiders per defense. If they have minions remaining, raid is successful
Raid town - Successful raids either set (disguised) player notoriety to amount stolen, or increases notoriety by 1 if already higher
Hero Attack - Heroes (elite) of fighting skill equal to player's notoriety attacks. Player with highest notoriety has 1.5x notoriety heroes attack.
Hero Attack - Hero kills off an amount of minions equal to their fighting skill. If any heroes remain, wipe.
Hero Attack - If no heroes remain, add treasure to dungeon per hero (= 1/2 fighting power = 1/2 notoriety)
Raid dungeon - Add ALL player dungeon raids against that player together. If greater than the dungeon defense, wipe.
Raid dungeon - If multiple players attacking, highest army kills others and takes all spoils.
Raid dungeon - Successful raids remove all gold & prisoners
Amount of space is increased by remaining (diggers + prisoners) / 10
Increase fortifications - Assign fortification space if not wiped
Ransom prisoners - Add gold, reduce notoriety
Successful raids return
Hidden minions / treasure return
Fill remaining space with minions (or remove minions if space smaller)
Allocate 1 notoriety to each player that an adventurer didn't return from.
If all actions gain no notoriety for the player, and they have been wiped by the town, reset notoriety to 0.
Town report - Build a notoriety list
Town report - Add all actions against the town
Player report - Collate all actions that the player knows about
Notoriously Databased
Dungeon stats
At the start of each round, your dungeon is essentially a couple of stats:
Notoriety: How much the town fears you. Expect an attack each turn at a level based on this number.
Treasure: The amount of gold / equipment / tradeable stuff you have in your dungeon
Dungeon size: The amount of space dug out so far.
- Minion living space: Amount of space dedicated to housing minions
- Prisoner Space: Amount of space dedicated to housing townsfolk to help dig. Prisons can hold 10 prisoners per space.
- Fortification space: Amount of space for traps / secret doors / dungeon layout.
Total defense: Total defense = Dungeon security + Minion security
- Dungeon Security: Provides additional defense, as well as maintaining this amount of gold if a wipe occurs.
- Minion Security: Total amount of security offered by elites and normal minions.
Minion Defenders: Amount of minions allocated to defence.
Minion Elites: Elites are 2x more effective at fighting (Defending / raiding)
Minion Diggers / Builders: Amount of minions allocated to expanding your dungeon size.
Prisoners: Amount of captured townsfolk currently expanding your dungeon size.
Actions
Each turn a player assigns these actions to their dungeon:
Order digging: Amount of minions ordered to dig instead of defend
Raid town for treasure / prisoners: Choose the amount of minions to send on the raid and the amount of treasure / prisoners to go after. Monsters on a raid will not be in your dungeon next turn. If successful, returns the amount of treasure / prisoners requested. Can choose to disguise as another player to give them the notoriety instead. Raid success is calculated by the amount of town security compared to the amount of monsters sent. The town's prosperity will indicate how deep into the town they will need to go to get the required resources.
Raid another dungeon for treasure / prisoners: Choose the amount of monsters to send on the raid. They will not be in your dungeon next turn. Note that dungeon raids happen AFTER heroes have softened them up.
Ransom prisoners: You will receive 1 treasure per prisoner ransomed and reduce notoriety.
Increase fortifications: Requires 1 space and 5 treasure
Equip Minion: Requires 1 treasure per minion converted to an elite. Elites fight 2 times better and are last to be killed.
Hide Hide this many elites. Implemented as raiding 'no-one'. They just spend time away from the dungeon when you expect a wipe.
End of Turn resolution order
Hidden minions / treasure are set aside
Raiding parties are set aside
Ransom prisoners - Remove prisoner.
Convert minion to elite
Assign minion diggers
Increase fortifications - Remove money
Raid town - Add ALL player town raids together to calc total desired resources
Raid town - Calc defense per treasure and per villiager
Raid town - Assign defense to each player's raid and kill off raiders per defense. If they have minions remaining, raid is successful
Raid town - Successful raids either set (disguised) player notoriety to amount stolen, or increases notoriety by 1 if already higher
Hero Attack - Heroes (elite) of fighting skill equal to player's notoriety attacks. Player with highest notoriety has 1.5x notoriety heroes attack.
Hero Attack - Hero kills off an amount of minions equal to their fighting skill. If any heroes remain, wipe.
Hero Attack - If no heroes remain, add treasure to dungeon per hero (= 1/2 fighting power = 1/2 notoriety)
Raid dungeon - Add ALL player dungeon raids against that player together. If greater than the dungeon defense, wipe.
Raid dungeon - If multiple players attacking, highest army kills others and takes all spoils.
Raid dungeon - Successful raids remove all gold & prisoners
Amount of space is increased by remaining (diggers + prisoners) / 10
Increase fortifications - Assign fortification space if not wiped
Ransom prisoners - Add gold, reduce notoriety
Successful raids return
Hidden minions / treasure return
Fill remaining space with minions (or remove minions if space smaller)
Allocate 1 notoriety to each player that an adventurer didn't return from.
If all actions gain no notoriety for the player, and they have been wiped by the town, reset notoriety to 0.
Town report - Build a notoriety list
Town report - Add all actions against the town
Player report - Collate all actions that the player knows about
Saturday, December 10, 2011
Notorious: Rumour System
In an attempt to kickstart my programming of Notorious, I had a look again at the rumour system for the game:
Rumour System
As the player interacts publicly with the villiage or other players, the rumour system will transfer information between NPC’s to build their own world view. Ultimately this world view will generate the notoriety that each player needs to advance in the game. Players can also subvert, create or enhance events that others know about in an effort to manipulate the notoriety of themselves or others.
World Views:
Each individual NPC will have their own world view of the events that occur in the world. These events can either be picked up as primary sources (the character participated in the event or was an eyewitness to the event) or secondary sources if someone else told them about the event. Characters may have conflicting reports from different sources, but will attempt to resolve these into a consistent world view that they are satisfied with. Players will also have a world view of everything that has been revealed to them in the game, and can use this to compare against others for detecting or interrogating inconsistencies.
A world view consists of a list (or tree structure) of events. Each event will require:
Description: Written text describing the event / rumour.
Source: Person establishing the event / rumour. Primary sources would have their own name here, otherwise it will be the name of the person who passed it on.
Characters: List of characters involved in the event. May also include items if they are unattached.
Evidence: Direct evidence that was used to confirm this event / rumour.
Links: Other rumours that are related. May possibly be the same event witnessed by others.
There will also be a way for multiple events to be collated into meta-concepts, with links and evidence used to support the concept. As an example, a farmer notices an ogre approaching, the ogre attacking his cattle, then leaving with the corpses. Instead of running to the village and reporting each individual event, they can combine it into an “attack” rumour to talk about and link to each individual event. Multiple attacks with similar characteristics can be combined to generate a “pattern of attacks”. Ultimately these can be used to guide the creation of quests for heroes, and the general notoriety of the player.
When a character interacts with another, they have a list of events that they wish to tell others (depending on their personality; gossipy types will have a long list) ranked by their assumed importance, as well as a list of questions to ask to attempt to resolve internal world view conflicts. If a character hears a new rumour, that rumour is stored with a confidence level of how well they agree with it.Confidence can range from 100% (fully confident, adamantly so) to 50% (happy to accept as true) to 0% (not sure) to -50% (Rejected) to -100% (absolute rejection). Events left between -50% to 50% are contested and are issues that the character will attempt to resolve through conversation with others. [May need a sigmoid function for confidence]
Player interaction with the Rumour System
Any character holding a linked gem will give the player complete knowledge of their world view. The player can automatically merge this information into their own world view, bring in any consistent events / rumours and manually handle conflicts, or manually process each event. Even if the information is merged automatically, it should be up to the player to agree or dispute certain events to create a consistent world view. This would entail viewing all the known details of a conflict, highlighting what the general consensus is so far (eg: 3 in favour, 4 not sure, 2 against), and allowing the player to shift their opinion either one way or another.
Creating Rumours
To create a rumour, the player can inject a new event into the memory of a linked creature, then give the creature an action of gossip in town (if needed). If the new event is consistent with other NPC’s world view, it is likely to be adopted and spread.
If there is an internal conflict within the linked creature there will either need to be more changes to make space for the rumour, or more power to add additional certainty to an idea. Complex changes may have even more difficulty in conveying to others.
There should be a way of predicting whether the changes will “take” before accepting the use of power. Rejected rumours stay within their memory as an “idea” that was eventually thought to be inconsistent, which will make successive attempts even harder (and possibly even make the creature doubt themselves as a primary source)
This is also the technique for removing events or modifying events, although care will need to be taken to make sure that these events are not re-exposed to the creature through talking to others.
To make use of the rumour system, the player may wish to use a reliable villager to start rumours. They may be able to capture a local farmer, give him a gem (in a ring), link to it, then modify the event of him receiving the gem so that he thought it was given to him from his mother. Once you release the farmer, they can then be used to keep track of what is happening inside the city, as well as injecting and denying rumours. The credibility of the character is damaged if injected rumours are found to be false, or they are disagreeing with the general consensus on a rumour. Reduced credibility makes it harder to get others to support their primary sourced events / rumours. This could be used for “boy who cried wolf” scenarios too.
*NOTE*: Unsure whether power use should be continuous to support a rumour, or a once off that is either accepted and assimilated, or rejected.
Rumour System
As the player interacts publicly with the villiage or other players, the rumour system will transfer information between NPC’s to build their own world view. Ultimately this world view will generate the notoriety that each player needs to advance in the game. Players can also subvert, create or enhance events that others know about in an effort to manipulate the notoriety of themselves or others.
World Views:
Each individual NPC will have their own world view of the events that occur in the world. These events can either be picked up as primary sources (the character participated in the event or was an eyewitness to the event) or secondary sources if someone else told them about the event. Characters may have conflicting reports from different sources, but will attempt to resolve these into a consistent world view that they are satisfied with. Players will also have a world view of everything that has been revealed to them in the game, and can use this to compare against others for detecting or interrogating inconsistencies.
A world view consists of a list (or tree structure) of events. Each event will require:
Description: Written text describing the event / rumour.
Source: Person establishing the event / rumour. Primary sources would have their own name here, otherwise it will be the name of the person who passed it on.
Characters: List of characters involved in the event. May also include items if they are unattached.
Evidence: Direct evidence that was used to confirm this event / rumour.
Links: Other rumours that are related. May possibly be the same event witnessed by others.
There will also be a way for multiple events to be collated into meta-concepts, with links and evidence used to support the concept. As an example, a farmer notices an ogre approaching, the ogre attacking his cattle, then leaving with the corpses. Instead of running to the village and reporting each individual event, they can combine it into an “attack” rumour to talk about and link to each individual event. Multiple attacks with similar characteristics can be combined to generate a “pattern of attacks”. Ultimately these can be used to guide the creation of quests for heroes, and the general notoriety of the player.
When a character interacts with another, they have a list of events that they wish to tell others (depending on their personality; gossipy types will have a long list) ranked by their assumed importance, as well as a list of questions to ask to attempt to resolve internal world view conflicts. If a character hears a new rumour, that rumour is stored with a confidence level of how well they agree with it.Confidence can range from 100% (fully confident, adamantly so) to 50% (happy to accept as true) to 0% (not sure) to -50% (Rejected) to -100% (absolute rejection). Events left between -50% to 50% are contested and are issues that the character will attempt to resolve through conversation with others. [May need a sigmoid function for confidence]
Player interaction with the Rumour System
Any character holding a linked gem will give the player complete knowledge of their world view. The player can automatically merge this information into their own world view, bring in any consistent events / rumours and manually handle conflicts, or manually process each event. Even if the information is merged automatically, it should be up to the player to agree or dispute certain events to create a consistent world view. This would entail viewing all the known details of a conflict, highlighting what the general consensus is so far (eg: 3 in favour, 4 not sure, 2 against), and allowing the player to shift their opinion either one way or another.
Creating Rumours
To create a rumour, the player can inject a new event into the memory of a linked creature, then give the creature an action of gossip in town (if needed). If the new event is consistent with other NPC’s world view, it is likely to be adopted and spread.
If there is an internal conflict within the linked creature there will either need to be more changes to make space for the rumour, or more power to add additional certainty to an idea. Complex changes may have even more difficulty in conveying to others.
There should be a way of predicting whether the changes will “take” before accepting the use of power. Rejected rumours stay within their memory as an “idea” that was eventually thought to be inconsistent, which will make successive attempts even harder (and possibly even make the creature doubt themselves as a primary source)
This is also the technique for removing events or modifying events, although care will need to be taken to make sure that these events are not re-exposed to the creature through talking to others.
To make use of the rumour system, the player may wish to use a reliable villager to start rumours. They may be able to capture a local farmer, give him a gem (in a ring), link to it, then modify the event of him receiving the gem so that he thought it was given to him from his mother. Once you release the farmer, they can then be used to keep track of what is happening inside the city, as well as injecting and denying rumours. The credibility of the character is damaged if injected rumours are found to be false, or they are disagreeing with the general consensus on a rumour. Reduced credibility makes it harder to get others to support their primary sourced events / rumours. This could be used for “boy who cried wolf” scenarios too.
*NOTE*: Unsure whether power use should be continuous to support a rumour, or a once off that is either accepted and assimilated, or rejected.
Subscribe to:
Posts (Atom)
