begin

Coordinator
Jul 26, 2011 at 2:25 AM

A few things need done, but we shouldn't work silently.

  1. display needs it's own lib\*.vb file if we're going to make a HUD. con.vb may be reused, but that may cause confusion.
  2. input is fine as controls.vb
  3. AI is fine as entity.vb, but will need attacks, talk, movement, ect.
  4. level file reading needs work, text could use a different format. For a HUD, we cannot allow MapParser.vb to write to the screen buffer.
  5. TileSystem.vb is an important part of display, and the only problem is that the background could use color, too.

map format doesn't matter much, considering the game, but it should be able to expand beyond 10 tile types, and not waste so much on commas.

Any other suggestions?

Coordinator
Jul 26, 2011 at 2:38 AM

I agree with your points OLH. This was made in approximately a day, and should be considered a "rough draft" as I have never made one of these before without a library.

If you have suggestions to optimize the screen buffer, I would be all for it.

I had considered storing entity and game information (quests? (far off), player data, npc info) in an SQLite database. Too complex for this game? Would flat files be better?

Where do you think would be the most appropriate place to begin?

Coordinator
Jul 29, 2011 at 10:57 AM

HI, are there any tasks I can do for example the HUD ?

Coordinator
Jul 29, 2011 at 11:48 PM

Jonas, we're working on concepts, could you think of any structural improvements?

  • I think that the display buffer should be in it's own file, accepting rectangles of text/BG/FG.
  • The map should be handled in RAM in it's own file, as to allow towns larger than a screen to be scrolled.
  • The tile system needs BG color, but we'll need to be able to display it.

Of course, the text/BG/FG format of the possible display would allow for serious optimizations, such as not changing colors if the colors are the same, using a console buffer, not writing hidden rectangles, ect.

jtokarchuk, I think that entity info and game info could be done using simple objects, and a good piece to start on would be the display.

cCon could be a rendering list, set up with a 16 element array of list items looking like:

Dim X As Integer

Dim Y As Integer

Dim Z As Integer ' when do I render? 1=first, 16=last

Dim Width As Integer

Dim Height As Integer

Dim Text As String ' VB.NET should make it screen sized, but dynamic is even better

Dim FG As ConsoleColor ' ForeGround

Dim BG As ConsoleColor ' BackGround

Coordinator
Jul 30, 2011 at 12:15 AM

I guess somebody has to ask this, but what is the game value of this project?

What is the story, and what sets this game apart from the original Rogue?

What is gameplay like for this game beyond movement?

Coordinator
Jul 30, 2011 at 1:07 PM

Hi, i think we should write a specification where the game is described from start to finish, please let me know what you think of this Idea.

Also I have an idea to make this Rogue different from the others. We can attach a Multiplayer modus. This is often more liked than the single player. But the Multiplayer first should be an idea, because first the game must run.

The story shouldn’t be so complex, because I think we become more Ideas when we think about the details of the story.

Because of this I suggest that the story is about a warrior who get a mission from his old grandfather (or another person who lives in his town). In this mission he must search for a treasure (or something like that) on his way he must ask old people about their help and their knowledge. The character must fight against monster and must help village people in different villages to become more information about the right way.

I would leave it as this, because all other details and ideas come by developing and think about the sorry. When we now fix the story we can’t use the ideas we become when we are at the point of the story. (I hope you know what I mean).

After the Game starts there should be a Main Menu where the User has the different choices.

Single Player

Multi Player

Options

About

Exit

 

  1. Single Player

After selecting the single player all saved games are displayed and the user can delete old games ore start a new one.

  1. Multi Player

This should be discuss later

  1. Options

Hear can the user change settings for e.g. His user name.

  1. About

A sonny normal about box like in other games or applications to.

  1. Exit

Exit the game J

 

 

ESC-Key

By press the ESC-Key in game, a menu opens where the user can Save and Close the game. The game is paused in the time the menu is displayed.

 

 

 

In the end i would suggest something, because I think the single Console is too small.

 

If the character later chat with village people to complete a Quest the dialogs becoming longer.

Also we need an HUD and I thing an Inventory is a good idea to.

 

I would add to other Commend line windows. In the first window (1) is only the map displayed. With the scroll bars can see the whole map.

In second Window (2) (please think the scroll bars aren’t there) can displayed different thinks. There are two ways to swath between the commences that is displayed in (2)

  1. To switch over keyboard with specific keys
  2. Or to switch the view in the Window (4).

 

In the Window (4) is only a list displayed, of thinks that can display in (2).

For e.g.:

  1. HUD
  2. Inventory
  3. Quest info
  4. Note

 

In the Window (3) are all the text displayed, that currently displayed below the map.

 

I uploaded a Picture to show you how I think it should look like (Only an example and with normal Comment prompts)

Bilder hochladen

Please give a feedback about my ideas.

Coordinator
Aug 1, 2011 at 3:18 AM

The last MS-DOS video cards supported 80x50 characters, and all versions of Windows that had DOS prompts support it.

Maybe we could just get a bigger prompt, 25 taller?

Coordinator
Aug 1, 2011 at 6:33 AM

I found an way to set the Size bigger than normal:

Module Module1

    Sub Main()
        Console.WindowWidth = 240
        Console.WindowHeight = 91
        Console.WriteLine("New Size Width: 240 Height: 91")
        Console.Read()
    End Sub

End Module


But what are the next steps. What about the story or the other thinks I had an Idea for.

I think we need in spesification because in this disscussion it don't make so muche sense to plan the Game.

I think we now need a plan because the Ideas are there.

 

Coordinator
Aug 1, 2011 at 3:42 PM

Okay, we'll start a "story" and a "code" discussion to clean things up, but post back here for general coordination.

The story is good, and oddly enough, I had a story much like that, except that the hero saw that his country needed a hero. (I wrote it before I watched Fullmetal Alchemist, so I shouldn't use much of it.)

Multiplayer mode and pause menu are great features, and I find Quest Info to be a requirement.

We'll need separate save files with load and save methods in the main menu, but that's as far off as multiplayer.

For everybody (except the creator of the project), I suggest visiting the Java game http://www.hexatron.com/rogue/index.html , I think it's good to just have the URL posted here.

Jonas, you've came up with some great ideas so far, and it's nice to have you on this project! By the way, do you know how to read and write English, or do you use a translator?

  • Looking back at my posts: "Wow, I state in a noticeable pattern, and I can't stop!" Sorry about this pointy post style, it's just how I think.
Coordinator
Aug 3, 2011 at 7:10 AM

I am really liking where this is going.

I vote that we scrap the current design and note it as a "rough draft" of sorts.

I agree wholeheartedly that we need map scrolling, an assortment of menus (pause, inventory, quests, equipment, dialog boxes) etc.

Should we be using a framework such as XNA for this? If that's the case, should it be a graphical roguelike? (Note: I can do pixel art). I am fine with ASCII as well.

Anyhow, in scrapping the first project (As I doubt the code is reusable, we would need:

  • Character display and movement
  • Map drawing, scrolling, and collision detection
  • interaction with certain tile properties (doors, stairs, exits to other levels)
  • a method of linking levels together
  • NPC movement (to come later: AI)

I think we need a system where we do not have to press a certain menu button to see our HUD. I think the HUD should be visible at all times. I really like Jonas

 ideas on this.

I had a dream one day, and noted that it would be really cool if a roguelike in ascii form somehow became massively multiplayer (note: I know this is a pipe dream and many tasks need accomplished first)

 

Let me know what you think, and where we all can agree that we should begin.

 

What do we want to use for source control? Everyone good with TFS?

 

Coordinator
Aug 8, 2011 at 1:21 AM

Uh, XNA, SQL, and TFS are beyond me and my computer, and I'm already having a hard time with the .NET code. If you guys go that far out with backwards combatability (http://foldoc.org/backward+combatability), then I may have to be an artist only.

 

C and C++ would be nice for the new code, since C++ works like C# without .NET, but it seems very selfish of me to even post all of this, but I'm just getting kicked out with all this new stuff!

I hope we can make a version for Win98, but just don't go beyond XP please.

Coordinator
Aug 9, 2011 at 3:24 AM

I would be fine with c++ for backwards compatability.