latestartstudio / hero6 Goto Github PK

We want to able to interact with any given room like the Sierra VGA Adventure games. This involves:

• A character must be able to walk in the room at legal walk areas.
• Player must be able to interact by "looking" at hot spot.
• Player must be able to interact by "touching" hot spot.
• Player must be able to interact by "talking" to hot spot.
• Player must be able to move between rooms.

It would really help if we had a build server for CI builds, automation of release builds, etc.

The Android build is unable to build because log4net is missing reference.

For better feel of our game world we need to render certain parts of the background image so that it renders in front of characters. Certain objects are obviously intended to in front of the player character, images from AGS should illustrate what I mean.

Several Open Source Licenses states that you must provide an actual physical copy of the license on distribution of the software, we should look into expanding our "LICENSE.THIRDPARTY.md" with the actual licences instead of just linking to them.

We should consider putting some research into a bug tracker software that will allow us to accept bug reports, feature requests, etc. from larger masses. GitHub Issues is great, however we fear that many from non-coding environments would shy away from reporting if they had to create new accounts just to achieve this task.

YouTrack for instance is feature complete and allows log-in by Google, Yahoo etc. Although conditions for use of YouTrack should probably researched.

We need the verb GUI commonly associated with Sierra VGA titles, and we need to support functionality for actions

• Walk
• Look
• Touch
• Speak
• Use Inventory

The rest of the buttons can prompt a text box saying "WIP" until later. It is required that #6 is complete before this can be resolved.

I've been able to reproduce this on two separate computers, for both WindowsDX and DesktopGL builds, and I'm curious if others are experiencing the same thing. When I start Hero6 I get excessive garbage collecting, I haven't looked into what might be causing this.

I want to consider navigation meshes for the pathfinder. I think it will really boost performance, as well as give us much smoother and nicer walk paths.

We need mechanics for the passage of time.

We need some GUIs for Hero6, no work has been put into this prior. For this introductory task it would be sufficient to implement a message box that displays some text. The real concern is implementing it architecturally into our project, as we would like to provide GUIs for Hero6 as plugins. The idea is that if we manage to implement GUIs as plugin modules we can easily modify existing GUIs, create new ones fast, or let the user base create their own GUIs if they so wish. This idea is inspired from "Mage's Initiation" that provides the Sierra VGA GUI and the Verb Coin GUI in the same game.

Some requirements:

• We must be able to call GUI elements in campaign modules. Right now we have "Hero6.Campaigns.RitesOfPassage" as an example.
  • In order to achieve this we must provide the API from the module "AdventureGame". However the actual implementation must be abstracted to reduce code coupling.
• Each GUI plugin must be separate projects.
  • We'll be actively developing the Sierra VGA look, so we'll just start there.

As far as I know the best GUI framework for use with MonoGame is EmptyKeys as it is feature complete, actively updated, open source and has designer support with Visual Studio. Although if there are other candidates I'd love to hear about it.

Check and make sure if all the URLs in the repository documentation (README.md, LICENSE.md, etc.) are valid.

We need to be able to save and load the game.

We also need a GUI to do so with. Before we can make the GUI we need to complete #6.

MonoGame supports both DirectX and OpenGL on Windows, with more graphics APIs for all platforms on the way. It would be neat if we could build Hero6 in such a fashion that the user could choose between graphics APIs instead of having to download one copy of the game for each API. Unfortunately however, because of the way MonoGame is setup it can't be made to work like this in a straightforward manner, so we need to engineer something smart, if that is even possible.

As the title says. We've recently introduced a new project module that contains the layout and design for UIs, this is rendering on top of everything else. However the mouse cursor was hacked in at early prototyping as a separate component with individual rendering, the ideal, if possible, is that the UI module should also handle the rendering of mouse cursors.

We need a concept GUI for the Sub Bar GUI (in lack of a better name). The Verb GUI should contain an extra button that is not normally included in the Sierra VGA template outside of the QfG series. This button should prompt a new menu with extra features. Running, sneaking, resting, character sheet and show time.

I would like that we had a game launcher utility with some basic functionality. Expected basic features would be to show the changelog, button to prompt to start the game, button to prompt to exit the launcher.

I would also like that we integrated an auto patcher, in such case we would need an additional button "Update" assuming an update is available.

Right click should cycle through the verbs interactions, walk, look, grab, talk.

We need mechanics for running and sneaking. In both cases animation for the player character should change and movement speed should go faster or slower. Option for toggling running or sneaking can be implemented by the Sub Bar GUI #14

The Windows installer was recently implemented, however we missed some warning messages when it was uploaded.

The source code is currently missing from the repository. It is currently maintaining its status as a private prototype on my account, and will continue to do so until we continue to do so until it has passed a review by @robertkety.

The text box will take the input text and only render it over a single line, we need to break it up over multiple lines somehow. Simply changing the UI element containing the text may be sufficient.

We need a concept GUI for Inventory.

Campaigns as they are structured contains only unique implementations of Character, Room, Item, etc. In C# this is involves a lot of boiler plate code for simple structures. I wonder if we shouldn't consider implementing our main campaign as a script module if possible. If for nothing else, the contents of any given campaign module is exactly what scripts are used for. F# is sometimes used as a scripting language I've heard, but the industry standard would be Lua.

I think we could benefit greatly from reducing the amount of nodes the pathfinder has to work with. Currently the pathfinder is working pixel-by-pixel, this results in:

node count = width * height
node count = 320 * 240
node count = 76 800

However I believe that if we modify our code to make every 5x5 (or something) grid of pixels to represent a node we can reduce the workload greatly

node count = (width * height) / (node width * node height)
node count = (320 * 240) / (5 * 5)
node count = 3072

Keeping in mind that the A* pathfinding algorithm has exponential complexity in not only CPU usage, but also memory consumption, I believe we'll get great performance improvements as there'll be less swapping between cache and RAM.

I also have a hunch that this will give us smoother and better looking paths as there should be less fidgety movements of the characters than it would be a pixel-by-pixel paths. Currently our character animations swap a lot back and forth between the directions the characters are facing.

We'll probably make our lives easier by implementing some kind of Debug Mode that allows us to rewrite game state on the fly. We had a debug mode by GUI in the AGS archived version, however extending the GUI for every time we gained new features quickly became painful as we would run out of space on the GUI control.

I propose that we implement a simple terminal that can be unlocked by pressing the '|' character. On debug build the debug mode would be accessible straight away for convenience, on release build it could be unlocked by having to type in first:

razzle dazzle root beer

or

suck blue frog

With this we should be able to access powerful editing to our game, for instance:

Get Hero Strength
Will print 45, assuming the Hero character strength stat is 45.

Set Hero Strength 100
Will edit the strength stat for the hero so that it now is 100.

Get Time
Will print 12:00.

Set Time 08:00
Will set the time of the current day to 08:00.

Geonbit.UI, a new framework has been posted public. It would be worth looking into if this is something we could use instead of EmtpyKeys

http://community.monogame.net/t/geonbit-ui-ui-extension-for-monogame/8529/2

Our current UI is just a black background with a white/gray foreground on it. We should look into making it better looking with actual graphics as backgrounds. Similar to the text box in the AGS prototype.

Clicking the middle mouse button should reset the cursor to walk

We need a proper font.

We need a concept GUI for showing the current time. Mechanics for passage of time in a separate issue #17

If Hero6 throws any exceptions and crashes the game it will do so silently, throwing the player back to the desktop without any feedback. In the interest of improving the user experience we should probably improve this experience, and at the same time maybe make the game produce a dump file that would make debugging release builds easier.

Proposal if exception is thrown

• The application produces a dump file (simple .txt file is probably good enough?).
• Name of dump file must always be unique, "HERO6-DUMP-21.09.16-23:30:05.txt" or something to that effect.
• The dump files must be stored somewhere conventional and valid for that purpose.
• The application forwards the player to the dump file.

We're probably not going to be able to have art assets ready at all occasions so we could benefit from placeholder art components

• Background
• Item (Room object)
• Inventory Item
• Character, with animation and movement in 8 directions

We need a start menu with the most basic options. It is required that #6 is complete before we can do this.

The current EULA is the standard lorem ipsum whatever, we need to figure out what we're going to do with the EULA and then add it to the installer.

It may be an interesting experiment to see if we can get better performance by the pathfinder being written in C/C++ instead.

Currently we're using NuGet to manage 3rd party dependencies into our C# modules. However there is a new hip and happening tool on the sphere that is called Paket which is supposed to be more simple, flexible and all that.

I don't have the time to research it any time soon but this issue will be left as a reminder for anyone who wants to dive in and investigate new technology we can use.

The size and scale of the UIs are hard coded, like this this.rootView = new RootView(320 * 3, 240 * 3);

We should probably look into adding a size and scale property to our user interface logic so that we can assign size and scale from the actual game logic instead.

Move all documentation in root folder (except Readme.md) to a sub-folder "doc/" or "docs/", remember to check that all links are still valid

We should be able to change language in the game, and we need mechanics for that.

Scrolling the mouse wheel should cycle through the inventory items.

Currently we're using the default MonoGame icon as our application icon and this should preferably be changed. We have an icon in the archived AGS game, however the problem with this is that this icon is 16x16 only, whereas the MonoGame icon is 256x256 at max and supports various sizes. This is important as it gives us safety that the icon will display in the correct size and quality for all situations where it may be used.

We may use this opportunity to consider if we actually want to use the logo at the archived AGS game, or if we would like to consider other designs.

We should implement every step of GitHub's guide for setting up repository to help people get around our repo

• Setting guidelines for repository contributors
  To help your project contributors do good work, you can add a file with contribution guidelines to the root of your project's repository. Then, whenever someone opens a pull request or creates an issue, they will see a link to that file.
• Adding a code of conduct to your project
  Adopt a code of conduct to define community standards, signal a welcoming and inclusive project, and outline procedures for handling abuse.
• Adding a license to a repository
  Include an open source license in your repository to make it easier for other people to contribute.
• Creating an issue template for your repository
  When you add an issue template to your repository, project contributors will automatically see the template's contents in the issue form body. Templates customize and standardize the information you'd like included when contributors open issues.
• Creating a pull request template for your repository
  When you add a pull request template to your repository, project contributors will automatically see the template's contents in the pull request form body. Templates customize and standardize the information you'd like included when contributors create pull requests.

Our current implementation of a text box is just a confirmation dialog for placeholder purposes. We probably need something more custom made, if possible something that derives or inherit from a conformation dialog as that contains a lot of the same functionality we'd like for a text box.

The text box must

• Scale in size dynamically from the content contained within.
• Render in center of screen.
• Any click will dispose of the text box
• While a text box is visible, the game must pause

Our text box will also need some kind of skin, but we can create a new issue for that once the mechanics are established.

We need to:

• Figure out what we need of 3rd party programs to run Hero6 on a Windows computer
• Bundle said 3rd party programs with Hero6 installer

Solution files are currently being stored in the root of the repository. We had reasons for doing so, but I'd like to move the solution files in the /src folder.

We need a Windows installer, pure and simple. No work has been put into this prior. Presumably we first need to find a good framework for creating installers. An installer will probably be a stand alone application so it does not even have to be of the same programming language as the rest of the code base.

We currently have some basic UI functionality, however a flaw with it is that when certain UI elements like message boxes are showing the game should obviously pause, which it doesn't. Using the text box as an example, it is currently legal for the player to move around and interact with the game world even though a text box is showing, this includes prompting new text boxes while there is currently one already rendering.

The paths made by the pathfinder are incredibly rough and unnatural, essentially the problem is that it works on a granular level. We should look into applying a post processing smoothing algorithm to the paths made by our pathfinder.

The verb bar icons for looking and opening the sub bar menu are distorted, it's really obvious if you continuously move your mouse in and out on either of the icons. The reason for this is that each icon in the verb bar has a light and a dark alternative, where the light icon will display on mouse over, however for these two specific icons the image files doesn't match up with each other, they're significantly different, causing a distortion effect.

For the looking icon the the dark alternative doesn't match up with the rest of the verb bar, for the sub menu icon the light icon doesn't match. The easiest fix is possibly to take the dark looking icon and make it darker to match the rest of the verb bar, and the opposite for the sub menu icon.

There's also a possibility that I did something wrong when I imported the images over from the AGS demo

Screenshot:

Look Icon:

Sub Bar Menu Icon: