Call the behavior methods in the Wumpus behavior interface from player actions.

The initial flyout has been written, but it never goes away.

Still needs:

• Activation (visibility, button to show it)
  • Animations
• Purchase button and UI

There was a small discussion of this in #1, but I'm opening a new issue to discuss our platform options in more detail.

There are three core categories for base frameworks that we can start with: barebones rendering engines, helper game wrappers/frameworks, and game engines. Here's a list of the pros and cons of each along with some examples of each (feel free to point out more details if you think of anything; this is just a braindump):

Low-down rendering engines

Examples:

• DirectX (with managed wrapper)

Pros

• Very performant
• I can't think of anything else...

Cons

• Complicated
• Not always well-documented
• Takes lots of work for even basic tasks
• Doesn't include UX primitives
• Assets become hard to manage
• Not cross-platform

Helper wrappers

Examples:

• MonoGame
  • open-source
  • cross-platform implementation of XNA
  • Hundreds of games already made

Pros

• Reasonably fast
• Handles some of the complexities of graphics
• Doesn't require much installation/setup for development
• Can be cross-platform using Xamarin (requires a paid license)
• Often open-source (developed in the open)
• Often available through NuGet

Cons

• Still requires some manual setup (custom boilerplate)
• Doesn't include UX primitives
• Assets become hard to manage

Game engines

Examples:

• Paradox3D
  • Very new, may be few examples but has nice documentation
  • Duality
  • WYSIWYG editor
  • Fully editable in VIsualStudio (instead of editor)

Pros

• Easiest of the three to get started with (not much boilerplate)
• Includes things like UI controls, physics engines, audio systems, etc
• Good maintainability
• Can be cross-platform using Xamarin (requires a paid license)
• Often open-source (although may be maintained separately/privately)

Cons

• Slowest (although not enough that it should become a problem)
• Requires most dependencies for development
• Probably largest binary footprint

Conclusion

In the end, I think this topic will definitely require more discussion. I think using a bare-metal library like DirectX is overkill and not worth the effort for our scale, but the other two options are open for debate. In the end, I would tend to vote for the third option ("game engine") because it will probably allow us to produce the best product in the shortest amount of time, but I am open to others' opinions.

So... what do you think?

Footnote

One other thing to consider is if we want to pursue cross-platform. With either of the last two options we should be able to do this, but either way it might require some more work. The main limitation is that they limit the size and API set of apps made using a free plan; more app means more money. If we do want to investigate this further, we should talk to the MS people (what are their names again?) and see if we can get some sort of a budget (:money_with_wings:).

Post-footnote afterthought comments

We should make sure that "The MS guys" are on this repo too so that they can see what's going on if they want to.

Post-footnote afterthought comment addition

I really need to remember their names.

Post-footnote afterthought comment addition extension

I think this is the longest GitHub post I have ever written. Glad I didn't attempt it on my phone.

Here's a list of "art" tasks that I think should be done:

• Crop the background image so that it can be repeated as a texture. This could be cropped so it's just one hexagonal cell.
• Create a background for the menu screens. I think it would be nice to have some sort of art here.
• A picture of the frame around an arcade machine display that we could overlay over the game.
• Along with the point above, images of "arcade buttons" -- the big round ones -- in different states (pressed, unpressed, hovered) would be cool.
• Dots for main menu animation
• "Alert" icon (some shape with an exclamation point in it?) for displaying next to the warnings
• "Turns" icon to put next to the move count (something like a circular arrow)
• An icon to signify buying stuff (a plus and a dollar sign?) to put in the "purchase " buttons

We should make a theme changer, I'll make assets. Get to work, slaves.

From spec:

• Display on the game screen a representation of the room, including the hexagonal form of the room, with each edge illustrated as either a tunnel to an adjacent room or a wall blocking access to an adjacent room. Include an illustration of the player, any present hazards, the wumpus if present, and any additional graphics that add to the realism of the cave.
• Display on the game screen the player’s score.
• Display on the game screen the player’s inventory.
• Display on the game screen any hints based on the player’s room. (For example: I smell a wumpus).
• Display on the game screen all actions the player can take on the current turn.
  • Move
  • Shoot an arrow
  • Purchase arrows
  • Purchase a secret

This is a bug in the UI lib that we use.

This is a two-part issue.

First, we are currently inefficiently iterating over the cave and updating the layout images according to the room array. We should probably remove the gold and pit images from the room layout and instead only use a single image that we choose at draw time based on the actual room object.

Second, when we hit a bat we immediately teleport to our new location and the bats relocate. This means that in normal operation you never actually see the bats. We should make it so that the bat reaction occurs after the animation to enter the room has mostly completed.

@kyranstar It looks like the active wumpus broke a fair number of the tests and I'm not really sure what's going on. Can you check it out? It might be good to just disable it in tests.

Currently, the first answer is always the correct one. Can we fix this? The two places that I think this would be easiest are on load, when it takes the questions from the file, and at render time (when it gives the set of answers from the context).

Anyone willing to give this a shot?

I think the turn number in the corner of the GUI is a bit confusing. At first, since it was next to hints, I thought i meant I had 85 hints ready.

I think we label it: Turns: 85

How do I render text to the screen? I saw the method SpriteBatch.DrawString (SpriteFont, String, Vector2, Color) but that needs a SpriteFont and I haven't figured out how to add one to a monogame project.

If you change the scale of a sprite, it doesn't render as scaled.

Make our code more fasterer.

This happens on my computer. I'm not sure why, I just hope it doesn't happen on the demo computer.

Open the Task List (View -> Task List) to see the list of TODO comments and start resolving them, whether that means making a change to clean up hacks or removing the comment because it was already resolved. As of now we have ~30 unresolved.

P.S. You should only look at the ones that are listed as being from the "Desktop" project. The others are mostly duplicates.

In the spec, they mention "hints" and "secrets". It is explained that secrets are contextual pieces of info that relate specifically to the map that the user is playing on. "Hints" are never explained, although it appears that they are the pieces of trivia that you give the user.

So, I think that we should use the current "hint flyout" to be a general space to show both hints (pieces of tivia) and secrets (map info). For this, I need a word to use to describe this information that could be put in a button -- any ideas?

I find that the Wumpus is often 1-3 rooms away when the game starts. This is a problem.

If you finish a game and then start a new one, you are put in the state that you ended with previously.

• Command to move into the Wumpus room
• Command to disable the particle system to improve perf on low-speed machines
• Command to disable losing (infinite or large number of arrows, reset on game loss, etc)

Also, we should probably refactor the commands into their own folder and put each into their own file. Also, we should optimize them to be easy and quick to type: "display" could be show, for example.

Quick list of things that will need to be done before the repo is ready for use:

• Add everyone as a collaborator (so that we can push directly)
• Push some initial content (a README.md, to start)
• Make sure that everyone was registered and added successfully (everyone should receive a notification for this over email)

• Make the camera slightly more zoomed in by default
• Make the Wumpus disappear when appropriate
• Run through the whole game to look for issues

@nikbyk

Okay. Will get to them tonight. Regarding the errors, should I roll back to 10074?

It's your choice. If you don't have an issue with not having the latest build and are O.K. with taking the risks of rolling back, go for it -- it'll make your life a lot easier if you don't have to get around these errors. Otherwise, I really don't know what we can do about it other than use a different machine...

I haven't gotten a chance to try out that VM, though.

Necessary:
-Render bats
-Render gold piles
-Render arrows
-Put a message for hazards
-Load trivia questions
-5 hard coded maps/randomly generated maps
-Buy arrows and hints with trivia
-Add the hint system

Optional:
-Animations (Hazards, moving, shooting)
-Additional looping from side to side
-Updated main menu graphics
-Render gold and score for the user to see

-restarting the game

TODO:

By next week:

• Be able to receive inputs
• Propagate inputs to classes that need them
• Unit tests for all classes
• Draw the player
• Be able to move the player from room to room (WASD?)
• Validate that the player doesn't move out of bounds
• Move the viewport based on the players location (center the player in the screen)
• Make the rooms pretty (pink is so ugly 😁)
• Deal with infinite cave
  • render phantom rooms adjacent to current room, rather than their location

Eventually:

• Figure out a theme
• Create assets

Since we determined that we don't want to follow a strict grid pattern, I think that we should disable the cave wrapping in the generator. Currently, I find myself in confusing situations where the wrapping just makes navigating more of a pain than an interesting element. What do you guys think?

The active Wumpus moves a lot. We should probably tune it back a bit.

The spec says that the cave is supposed to be something like a 5x6 grid. Personally, I think the current haphazard caves that we have are pretty cool, but if we want the rectangular cave we should add those constraints sooner rather than later.

I think we need a title and catchphrase for our game.

The title could be some play on words like "Pac-Man", "Ghost" and "Wumpus" ("Pac-Wumpus", anyone?). A catchphrase could be as simple as "Like Pac-Man, but different".

Any thoughts/suggestions? Putting something like this on our main menu along with a themed background would be pretty cool.

As I am debugging our game, I am repeatedly hitting debug error dialogs because assertions are failing in the cave generator. I think that we should replace these debug assertions with error/warning logging so that we don't show the judges a big error dialog when we start the game. I think it would be easiest to define an Assert method in our Log class that perforns the same core function as Debug.Assert but just logs instead of MessageBoxes.

In the spec, it says:

You can purchase 2 more arrows by getting at least 2 out of three trivia questions right.

There are two interpretations that I can take away from reading that:

• Asking to purchase arrows and then correctly answering 2/3 questions gives you two arrows, and you can do this as many times as you want
• Asking to purchase arrows and then correctly answering 2/3 questions gives you one arrow, and you are only permitted to do this twice

Which one do we like best?

We're looking for a comprehensive list of the items that we still need to add.

The spec is included as a link on the wiki.

Here's a list of the big things that I think we need to communicate to the judges (feel free to add more):

Code judging:

• Wrote the code like it was a production codebase
  • Easily maintainable
    • Mention the complexity analysis from Visual Studio
  • Broken up into classes and files
  • Duplicate code refactored into helper classes
• Used complex concepts
  • Flags enums
  • Pathfinding algorithms
  • Random cave generation algorithm
  • Stack traversal
  • C# Attributes (for XAML binding)
  • XAML-to-XNA generator
  • Used serialization to load/save high scores
    • Saved to proper location (ProgramData)
• Commented almost all code
• Game run using a state machine (SceneManager)
• Interactive console added for easy demoing and debugging
• Wrote lots of reusable code that would be helpful for other projects
  • Command-line parser
  • Math utils
  • Latch
  • Priority queue
  • MemberGroup attribute
  • Particle systems
  • Sprite class
• Contributed to open-source projects (filed bugs on UI lib)
• Didn't use any built-in Win32 APIs
  • Full cross-platform support, with very few #ifs
• Used GitHub/Git to make collaboration easy
• Wrote tests to assure code quality

Game judging:

• What is game judging, anyway?
• This list looks pitiful, so I'm just adding items

If the player moves into a room and then the active Wumpus moves into the same room, you can be in the same room as the Wumpus without being thrown into trivia. We should process the collisions after everything moves.

We already have some basic code to create the whole cave. Now we just need to make it limit the corrections to 0<n<4 connections. There is a method to verify this in the map class.

I am looking at this tool that we found and it really isn't working. It's glitchy and not easy to use, and you can't export without paying. Does anyone have any other ideas for tools to use?

• 2D: I think the game should be 2D because the scope of a 2D game is much smaller and easier to manage
  • Top down: It could be top down, like the original Hunt the Wumpus, but with more flushed out graphics presumably
  • Side scroller: I think this could be made to work if we really like the idea?
  • A "2.5D" RPG sort of look
• 3D: 3D might have more options for gameplay but would be harder and might look worse if not done right
  • First person dungeon crawler (Prelude of the Chambered)

The Lazy Wumpus Object
• Keep track of the current state the Wumpus is in (that is, asleep, awake, moving).
• If the player shoots an arrow and misses while the Wumpus is sleeping, the Wumpus wakes up and runs up to two rooms away from current position.
• If the Wumpus is defeated in trivia, it will run up to three rooms away.
• The Wumpus is slow and can only move one room per turn.
• If the Wumpus does not move for two turns, it falls asleep.

The Active Wumpus Object
• Keep track of the current state the Wumpus is in (*that is, asleep and awake).
• Keep track of the number of turns.
• Every 5 to 10 turns the Wumpus will wake up and move 1 room per turn for up to three turns before going back to sleep.
• Every turn, there is a 5% chance the Wumpus will immediatelyteleport to a new, random location.
• If the Wumpus is defeated in trivia, it will run up to two rooms away per turn for up to three turns.

How do we want to handle the fact that the map wraps from one edge to the other? I was thinking we could render the rooms adjacent to the edges and move the player to the other side of the map when they try to cross. In that case, we would have to manually store the information on which connection is supposed to wrap to make sure that the layout algorithm doesn't hit an infinite loop.

Any other ideas?

And while we are on the subject, how do we want to obscure adjacent rooms from the user? Fog?

Where should I put test methods? And how can I run them?

So that we can show off our code and claim that it's "good code" to the judges, we should try to get as much of it commented (at least at a basic level) as possible. We should be able to open any file and be confident that it has comments -- seeing comments (even without reading them) goes a long way towards making a code judge like you. I have included a list below of the files that we have in our codebase. Please pick some and:

• Add comments to at least every block of code, explaining what it does ("block" being ~1-6 lines)
• Add XML documentation to each method with an explanation of what it does. You can insert the framework for these comments by putting your cursor on a blank line before a method header and typing three slashes (/).

If a file already has comments and they are informative and up-to-date, mark that file as complete and move on. Once you finish a file, mark it here (and push the changes). If you aren't sure what some code does, or what a file does, just don't do it and leave a note here.

@anak4569 This is a good item to pitch in on if you're looking for ways to help out.

Here's the (very large) list:

• *Game Control*
  • ArgumentParser.cs
  • GameController.cs
  • Logger.cs
  • Scene.cs
  • SceneManager.cs
  • *God Mode*
    • DisableCommand.cs
    • DisplayCommand.cs
    • GodCore.cs
    • GoToRoomCommand.cs
    • ListRoomsCommand.cs
    • OutlineCommand.cs
    • RoomInfoCommand.cs
    • SetViewCommand.cs
• *GUI*
  • Camera2D.cs
  • HUDRenderer.cs
  • MapRenderer.cs
  • SnakePath.cs
  • Sprite.cs
  • StateAnimator.cs
  • TiledTexture.cs
  • WumpusChase.cs
  • *Animation*
    • AnimationCore.cs
    • SpriteFadeAnimation.cs
    • SpriteMoveAnimation.cs
  • *Generated GUI*
    • *Context*
      • GameOverHudContext.cs
      • HighScoreContext.cs
      • HUDContext.cs
      • MainMenuContext.cs
      • ScoreHudContext.cs
      • TriviaHudContext.cs
  • *ParticleSystem*
    • FogOfWar.cs
    • Particle.cs
    • ParticleSystem.cs
• *Helpers*
  • CaveUtils.cs
  • CsvFile.cs
  • DictionaryExtensions.cs
  • EnumerationExtensions.cs
  • FileUtils.cs
  • FrameCounter.cs
  • Latch.cs
  • MapUtils.cs
  • MathUtils.cs
  • MemberGroup.cs
  • MiscExtensions.cs
  • Pathfinding.cs
  • ReflectionUtils.cs
  • *PriorityQueue*
    • HeapPriorityQueue.cs
    • IPriorityQueue.cs
    • PriorityQueueNode.cs
• *High Scores*
  • GameOverState.cs
  • ScoreEntry.cs
  • ScoreManager.cs
• *Map*
  • Cave.cs
  • InvalidRoomException.cs
  • Map.cs
  • MapGenerator.cs
  • MapInputHandler.cs
  • MapStateEnums.cs
  • Player.cs
  • Wumpus.cs
• *Scenes*
  • GameScene.cs
  • HighScoreScene.cs
  • MainMenuScene.cs
• *Trivia*
  • Question.cs
  • Trivia.cs
  • TriviaQuestionState.cs
  • TriviaSet.cs

We still need a game over scene for the game.

I am currently writing the code to render a basic map. Can I assume that no rooms' connections are changed while the user is in a game?

Currently I believe we are unable to do this. Are we going to add this?