76
Other Announcements / Re: 50 Days till the Annual Roguelike Release Party
« on: July 27, 2012, 06:32:40 PM »
Looking foward to this!
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
77
Early Dev / Re: Left Field Hotel (Horror Roguelike)
« on: July 26, 2012, 08:26:26 AM »Not at all! I've played a lot of games with horror feel where you were able to slay monsters and they were still scary. If a game is balanced properly, even killing a monster doesn't give you a sense of ultimate power. You rather think: "Damn, I've barely killed it, if I didn't have so much luck I'd already be dead!".
There definately are ways to make combat scary, especially if every fight can be worth your life. But either way, you need to feel weak and pathetic. I should probably consider having some sort of enemies that tie into the story (which the current build won't show, so don't look yet!). However, I'll still include "?" enemy, since I think it's a change of pace and tension
. 78
Early Dev / Re: Left Field Hotel (Horror Roguelike)
« on: July 25, 2012, 10:48:26 PM »No. I like horrors where only one thing is worse than the hordes of monsters that can be encountered: me. Running and hiding makes me feel pathetic. I hope this is not the only planned way to play this game
At the moment it kind of is. Feeling weak and pathetic makes a game scary. If you can just kill all of the monsters than it loses the scary feel of it. But I'll take your feedback into consideration
.
79
Early Dev / Re: Left Field Hotel (Horror Roguelike)
« on: July 25, 2012, 07:53:46 PM »Some remarks from me:
1. When I pressed "u", it took me a long while before I figured out what to press then to select a flashlight. Expected [enter] or [space].
2. Player is unable to control movement with arrow keys, only numpad arrows seem to work.
3. No 'Look' command or something that would allow to learn what certain objects are.
4. No way to comfortably pick up several items in a row.
Besides, it was fun to explore the building, at least until that Pacman-like characted jumped out and ate me. Looking forward to see a more playable version soon
I'll be adding a tutorial and a better control scheme later on, but I probably should have made it more clear on how to select things (I just think it's easier to always keep your hand on the numpad).
As for the enemy, did you figure out how to hide from it? Since this playable version, I've made it a bit easier.
80
Programming / Re: Multiplayer in Roguelikes
« on: July 25, 2012, 09:13:10 AM »I'd give MAngband a try, if I were you.
If you're shy of interacting with the playerbase (which is, like, 4 people.) it's easy as pie to set up your own server.
I'll give it a try.
81
Early Dev / Re: NDRL: n-Dimensional Roguelike
« on: July 25, 2012, 09:02:56 AM »
I tried it, and it's not really a roguelike per say, but a unique puzzle game. It's a bit confusing. I'm not sure what I'm supposed to be looking at with the different axis views (is it in a third dimension?), but oh well. I thought that it was a bit of fun, but it got a bit repetitive. The levels are mostly the same except for the position of the portal, horror, and the space you have. I'm interested as to where this game goes in the future.
82
Programming / Re: Multiplayer in Roguelikes
« on: July 25, 2012, 07:07:28 AM »Player A hits the Enemy on turn 1. Enemy flees.
Player B runs into the Enemy on turn 2. He throws a potion at Enemy, which happens to be a potion of gigantism. It lasts 10 turns. Player B and Enemy pillar dance for 8 turns.
In the meantime, Player A gets a cup of coffee, comes back and takes turn 2.
Player B hits the Enemy and it flees back to Player A on turn 11. According to B, Enemy has gigantism for 1 more turn. According to A, it's turn 3.
That's a good point. I'd say that having a queue based turn system would solve that, but there's still the problem of waiting for the other person. It would just be too slow.
I keep going back to the idea of "real-time". Everyone says that it kills the roguelike experience, but what if it was "sort of real-time"? Let's say that every few seconds the players' turns end, and the enemies get to move. During each players few seconds of each turn, they may move up to once, attack once, or eat some food once. It's still a turn, but it's faster. However, it's also pressured...
83
Programming / Re: Tablet ideal device for a roguelike?
« on: July 24, 2012, 05:57:24 PM »
I've tried a few free roguelikes on my iOS device, so I think i can give some feedback.
Rogue. It was laggy, and the controls were apsolutely horrible. You have to swipe in different ways to get different things to happens. Swipe halfway down and across to the right to pick up item....swipe left and to the bottom right corner to attack....Not sure if those were the exact commands but I never bothered to learn the swipes. Nethack also had those commands.
iNethack was better. The commands would be on the sides of the screen. Easier, but each button had a picture of a key. Like "99" waited 99 turns. The "#" would do, uh, I don't remember. It was pretty good, but then you get to the menus...They are hard to navigate, annoyingly pop-up on screen at random times to show you what items on the ground, and there are too many of them. Why not just have one menu where you can drop, throw, or eat items? Each of these commands has to open a different one.
Powder has the best controls of these. Moving is easy, and most of the commands are on screen as buttons. As an added bonus, they have pictures so it's easy to remember which does what. It's not perfect, but pretty good and casual.
Rogue. It was laggy, and the controls were apsolutely horrible. You have to swipe in different ways to get different things to happens. Swipe halfway down and across to the right to pick up item....swipe left and to the bottom right corner to attack....Not sure if those were the exact commands but I never bothered to learn the swipes. Nethack also had those commands.
iNethack was better. The commands would be on the sides of the screen. Easier, but each button had a picture of a key. Like "99" waited 99 turns. The "#" would do, uh, I don't remember. It was pretty good, but then you get to the menus...They are hard to navigate, annoyingly pop-up on screen at random times to show you what items on the ground, and there are too many of them. Why not just have one menu where you can drop, throw, or eat items? Each of these commands has to open a different one.
Powder has the best controls of these. Moving is easy, and most of the commands are on screen as buttons. As an added bonus, they have pictures so it's easy to remember which does what. It's not perfect, but pretty good and casual.
84
Programming / Re: Multiplayer in Roguelikes
« on: July 24, 2012, 05:40:56 PM »S'alright. Basically MAngband works by advancing the game 1 turn ahead every second (maybe a bit less than a second?
Annoying, pressured combat doesn't sound very enjoyable. I suppose that if you want more than a few people playing, then it needs to be real-time. Waiting for 8 other people to take their turn would be more of a waste of time than fun. I agree with you and kraflab, real-time makes it not feel like a roguelike.
Before I continue though, I strongly suggest you use the search bar on this forum because this topic has already been fairly discussed recently
I actually did do some searching, but I didn't find anything!
One solution that comes to mind is turn-based but asynchronous - so you can go up to say 10 turns ahead of or behind another player in your party. It would have issues with people doing actions together they didn't intend (accidentally bolting friends, etc) which would be especially bad with lag, but it would solve the whole moving around slowly problem.
Moving more than once per turn could work. It seems that the player who gets somewhere first would have the major advantage though. Especially if there was any type of PVP. If one player got to another first, stabbed them 8 times, then the other player wouldn't be able to even react. Well, certain moves could take up more of the turn. For example, attacking will end your turn instantly. Moving will use up a fifth of your turn. So on and so on.
85
Programming / Multiplayer in Roguelikes
« on: July 24, 2012, 10:05:24 AM »
I don't think I've ever even seen a multiplayer roguelike. And I don't think I'll see one that connects people online anytime soon.
But if a multiplayer roguelike was made, how would the multiplayer work?
I thought about this, and I just can't figure it out. It could be turn based, but then whenever someone moves their character they can't move until the other player does. So if you're trying to move around it would just be awful. I can imagine a lot of waiting. If not turn based, then real time will work, right? Well, everything is in tiles, so you would have to line up your moves just right to get anything done. Controls would have to be simplified, to allow fast commands in the middle of a fight, possibly with other players.
What's everyone elses opinion on multiplayer in roguelikes? Is it even possible to get multiplayer to "work" well with them?
But if a multiplayer roguelike was made, how would the multiplayer work?
I thought about this, and I just can't figure it out. It could be turn based, but then whenever someone moves their character they can't move until the other player does. So if you're trying to move around it would just be awful. I can imagine a lot of waiting. If not turn based, then real time will work, right? Well, everything is in tiles, so you would have to line up your moves just right to get anything done. Controls would have to be simplified, to allow fast commands in the middle of a fight, possibly with other players.
What's everyone elses opinion on multiplayer in roguelikes? Is it even possible to get multiplayer to "work" well with them?
86
Traditional Roguelikes (Turn Based) / Re: ADOM: Resurrection IndieGoGo now live
« on: July 24, 2012, 08:46:04 AM »It doesn't look good, the funding seems to have stopped on halfway. I think it's revealing how limited interest there is for roguelikes.
I'd say it's more so the limited interest in ADOM. Or maybe $48,000 is too much for the roguelike community.
87
Early Dev / Re: Left Field Hotel (Horror Roguelike)
« on: July 22, 2012, 10:15:59 AM »
News Update:
I finished staircases and elevators. Up to one of each can appear per floor. Later, elevators will be much rarer as they lead you out of the hotel.
I added note items, which will later be used to tell a story.
I made it so that you start the game with a single match as your only source of lighting. Your first goal will primarily be to find a flashlight as a more permanent solution for light. Flashlights are far less common than other items, however. I'm not going to update the playable build yet. There's still a few things I want to add.
I finished staircases and elevators. Up to one of each can appear per floor. Later, elevators will be much rarer as they lead you out of the hotel.
I added note items, which will later be used to tell a story.
I made it so that you start the game with a single match as your only source of lighting. Your first goal will primarily be to find a flashlight as a more permanent solution for light. Flashlights are far less common than other items, however. I'm not going to update the playable build yet. There's still a few things I want to add.
88
Programming / Re: Grid-Based Lighting
« on: July 18, 2012, 08:26:31 PM »
I have light fade away with distance in "Left Field Hotel". If you want to see what it looks like I have a picture on the thread, http://roguetemple.com/forums/index.php?topic=2509.0.
On to the point. What I did was have every tile have a brightness variable. This can range from 0 to 10. If it was a 5, for example, then the tile would be half lit. If 10, it would be fully lit. So after giving the brightness to the light source, it would loop through all of the tiles and find the distance between them and the light source. Then, a brightness would be given to said looped tiles based on the distances. If a light source crosses another light source, then the surrounding tiles' light would combine and become more bright. To find the distance from the light source and the tiles around it, I used the pythagorean theorem (a*a+b*b=c*c). Let's say that the light source is 10. Well the tile two tiles to the right is two tiles away, right? 10(light source)-2(distance) would be 8. So the tile would have a brightness of 8. If a wall is in the way of the tiles, then the brightness would not change.
I'm not sure about having non-integer based lighting. Light wouldn't be grid based anymore.
On to the point. What I did was have every tile have a brightness variable. This can range from 0 to 10. If it was a 5, for example, then the tile would be half lit. If 10, it would be fully lit. So after giving the brightness to the light source, it would loop through all of the tiles and find the distance between them and the light source. Then, a brightness would be given to said looped tiles based on the distances. If a light source crosses another light source, then the surrounding tiles' light would combine and become more bright. To find the distance from the light source and the tiles around it, I used the pythagorean theorem (a*a+b*b=c*c). Let's say that the light source is 10. Well the tile two tiles to the right is two tiles away, right? 10(light source)-2(distance) would be 8. So the tile would have a brightness of 8. If a wall is in the way of the tiles, then the brightness would not change.
I'm not sure about having non-integer based lighting. Light wouldn't be grid based anymore.
89
Programming / Re: Copyright!
« on: July 18, 2012, 06:12:10 AM »
Many other games use graphics taken from copyrighted sources. For example, a free game named "I Wanna be the Guy" uses graphics taken from multiple nintendo games and has gained much popularity. As long as you don't sell your game commercially or anything then I really don't think you're going to have any problems 
.
.
90
Early Dev / Re: Left Field Hotel (Horror Roguelike)
« on: July 13, 2012, 05:39:08 AM »
News Update:
After spending a few days working on the fire system, I felt that it just didn't "work" with the game. Too bad too, I already had the player able to catch fire, have the fire spread, have the fire travel across gasoline trails, and have fire burn down tiles. I had to get rid of all of that.
After getting rid of the fire and the fire items (Gasoline, ect) I started on the stairwell room. Stairwells will be the third type of room you may encounter. They will bring you up and down floors, creating a new environment each time. I also limited the amount of bathrooms you can have per floor to 1, as well as the stairwells.
As well as all that, I added a new item. A Flashlight. Using (u) it will turn it off and on. By default, the flashlight is in your hands as soon as you start the game. It's brighter than the match, so I probably should add a charger to the flashlight later on. This will not be the case in the future.
I added an updated build for windows in the first post. I still haven't fixed item transparency though, something I'm saving for once I get all of the item images done for the game (And I still have to think of many of those items).
After spending a few days working on the fire system, I felt that it just didn't "work" with the game. Too bad too, I already had the player able to catch fire, have the fire spread, have the fire travel across gasoline trails, and have fire burn down tiles. I had to get rid of all of that.
After getting rid of the fire and the fire items (Gasoline, ect) I started on the stairwell room. Stairwells will be the third type of room you may encounter. They will bring you up and down floors, creating a new environment each time. I also limited the amount of bathrooms you can have per floor to 1, as well as the stairwells.
As well as all that, I added a new item. A Flashlight. Using (u) it will turn it off and on. By default, the flashlight is in your hands as soon as you start the game. It's brighter than the match, so I probably should add a charger to the flashlight later on. This will not be the case in the future.
I added an updated build for windows in the first post. I still haven't fixed item transparency though, something I'm saving for once I get all of the item images done for the game (And I still have to think of many of those items).