Messages

1

Programming / Re: What do you think of having books sharing the information instead?

« on: July 13, 2013, 04:45:33 PM »

I support this. There are some games that already use this mechanism to provide tutorial like information. I would recommend that after reading a book, the information gets put in a centralized journal so that it is more accessible. Things like fighting a monster can add information to your journal, but if you find a book about that creature, you can find out its strengths and weaknesses before fighting it.

2

Programming / Re: "Game state"-based game loop.

« on: May 29, 2013, 03:05:28 AM »

2. A finite state machine (where you only have one state at a time) does, not quite fit games. Instead I would have something more like a state stack. You push new states onto the stack and pop them off when they are done. You could go with something as simple as calling render() for everything in the stack or you could get a little bit more clever and only call render() down the stack until you reach a state to renders the entire screen. Similar rules can be applied to the other common functions.

However, what about the input and logic phases? Do you call that for every state on the stack or just the "top" one?

In a roguelike, you can probably go with just updating and drawing the top state.

3

Programming / Re: "Game state"-based game loop.

« on: May 28, 2013, 02:39:18 PM »

4. The player selects the item to be dropped.



X. The game goes back to the "main" state.

X+1. The game logic, informed by some unknown process of the item chosen, handles the drop in this turn.

So, what goes in the "" and what is the way in which the logic gets informed? How is that communication handled?

Once you have selected the item to drop, just call Player.drop(item_selected), then you can close the menu state and return back to the main UI state. It's probably easiest just to handle the item drop logic as soon as it is called, but you could also queue up the event so that it is done next time update is called. The main UI does not need to know that the item drop menu was just used. When it draws, there will just be another item on the ground and it doesn't really matter where it came from.

4

Programming / Re: "Game state"-based game loop.

« on: May 28, 2013, 03:34:41 AM »

So then you display all messages for the turn after the turn logic is finished, right? (And update the display.)

Yes, you can do it that way. Typically you will have an update()->draw()->update()... loop. The UI grabs whatever info it needs about the game state and draws it. If you want messages to last more than one loop, just save the results somewhere in the UI (the game logic could also store the history, but I would put this in the UI unless the game actually needs that information later).

5

Programming / Re: "Game state"-based game loop.

« on: May 28, 2013, 02:02:17 AM »

Thanks. I have another question about 5: you say "try to separate your game logic from the UI", but:

1. things happening in logic (e.g. combat) may need to access the UI ("you hit the monster for X damage" appears on screen)

2. when you do that drop command, the UI needs to be invoked to get the item to drop. In other words, to get the parameter "item" for the "drop(item)" function.

So what should one do?

There may be times when it is too inconvenient to separate the two, but you should try to avoid it. I also should have phrased this a little different. The UI can depend on the game logic (how else can it do anything useful), but the game logic should not need to know about the UI. In your damage example, instead of the game telling the UI every time someone is hit, just store those events. The UI can then grab that list and do what it wants with it. This way, when you want to change your graphics, you don't need to worry about breaking your game logic.

6

Programming / Re: "Game state"-based game loop.

« on: May 28, 2013, 01:07:22 AM »

Game states are used all the time in games and a very useful. Let's see if I can answer your questions.

1. Yes, it is possible to remove the singletons. In fact, I really have no idea why that tutorial used singletons. Going with individual instances will make your code much more flexible and it will cause fewer bugs and workarounds.

2. A finite state machine (where you only have one state at a time) does, not quite fit games. Instead I would have something more like a state stack. You push new states onto the stack and pop them off when they are done. You could go with something as simple as calling render() for everything in the stack or you could get a little bit more clever and only call render() down the stack until you reach a state to renders the entire screen. Similar rules can be applied to the other common functions.

3. Depends on how general you want to make your states. I would probably make conversations a state then just create an instance of it with the appropriate NPC specific data when you start a conversation.

4. This is another problem I have with that tutorial you linked. Changing the state at arbitrary times can lead to inconsistent behavior. Instead I would have a function like setNextState() and when the game loop will handle the switch at the end of the current loop.

5. Try to separate your game logic from the UI. When the player selects drop item, call some function in your game logic that says drop(item) or whatever. The game states should also probably know very little if anything about each other.

Hope that helps.

7

Early Dev / Re: Galaxy of Rogues: Spaceship movement

« on: May 20, 2013, 05:44:08 PM »

I'm curious as to how your efforts are progressing. Is your dev team in need of a sycophant? My rates are very reasonable.

Things got busy for I while, so I haven't made much progress. Now I have more time though, and have been diving in to a lot of the back end stuff. I'm also thinking about switching to a semi-realtime system. As long as you are holding down a direction key, time progresses in realtime. Releasing the key immediately stops the game. This gives a lot more flexibility as far as timing goes. We'll see if that works out. As far as your offer for help goes, thanks, I'll shoot you a message when things get further along and could use some testing.

8

Programming / Re: Input system and the "-More-" prompt.

« on: May 17, 2013, 05:05:03 AM »

8. Yes, walking on a wall would consume a turn the way it is now. I'd like it not to.

To fix this should be pretty easy if you are using a queue to order your actors. Just put the player back on the front of the queue if their action doesn't do anything.

9

Programming / Re: Picking The Right Language/Game Engine For My Idea

« on: April 23, 2013, 01:53:32 PM »

While I am not personally a big fan of Python, it is a perfectly viable language to make a roguelike in. I wouldn't worry about the performance issues to much as there are plenty of ways to work around any problems (there are compilers for python or you could wrap native libraries).

If you want to try out an idea quickly, Python could work for simpler ideas. If your prototype is going to include a lot of graphics though, I would say go for one of the existing engines, as they will save you a lot of time in that regard.

10

Programming / Re: Making a Roguelike in Gamemaker

« on: April 17, 2013, 01:26:37 AM »

Speaking of GameMaker, I bought it a while ago when it was on sale on Steam. I played around with a little, but was a bit lost. Do you know of any good tutorials for GM / how did you learn GM?

11

Programming / SQL Database

« on: March 17, 2013, 04:45:36 AM »

I'm thinking about using an SQL database (SQLite specifically) as the back end to store data for my rogue-like. Does anyone have any experience with using SQL for game programming and would like to share any tips or suggestions?

12

Early Dev / Re: Galaxy of Rogues: Spaceship movement

« on: March 07, 2013, 09:51:02 PM »

Are you playing to have tile-set support?

Not right now. I would love to have nice graphics, but taking the time to do all the art now would kill development. If the game makes it to version 2, that would probably be the main upgrade.

With that said, I have been trying to make the interface as modern as possible while keeping the classic ASCII look. You can check out my thread here http://roguetemple.com/forums/index.php?topic=2994.0 where I was asking for suggestions.

13

Programming / Re: game loops and information screens

« on: February 27, 2013, 11:14:38 PM »

You don't need to use objects, the solution is just a bit more elegant that way. You can use an integer to represent which state you are in, then, as Omnomnom said, you can use an if or switch statement to call the appropriate logic and drawing functions for that state.

14

Programming / Re: game loops and information screens

« on: February 27, 2013, 05:16:27 PM »

There are a lot of ways to do this. What you are making is a finite state machine. A search of the web should give you lots of results (just search "game finite state machine"). The way I would do it is by making a "game state" class then sub-classing that for each of my different screens. The main game loop keeps a reference to the current state and calls methods such as "update" and "draw" on that state. Inside each game state, you have all of your logic specific to that screen including when to switch to a different game state.

15

Programming / Re: User Interface suggestions

« on: February 07, 2013, 02:12:07 PM »

Out of curiosity, using LWJGL or Swing? I'm working on a little engine myself using LWJGL

It uses swing. I don't need the speed of OpenGL and by using swing I don't have to worry about native libraries.