I don’t know if anyone noticed, but the title of this thread is quite fitting. This is a nice rouge-like game with all this red 
I would never have considered that!
I thought any comments would be that they had noticed the error in the MST. Every time I look at it I’m seeing red - always some problem to fix!
I think the hero of the game may be called Vin - like say in ‘Vin’ Deisel
I have read the word Rougelike, and even after 2 people mentioning it I still did not see the error.
I have now re-named the game 3d Roguelike . The hero Vin Rouge may not now feature. But the colour red will perhaps still be a prominent feature of the graphical debug of the room generator.
Spelling the name of your game and thread wrong is quite silly, I even got one of those social JGO medals for being thorough. Now I just feel thoroughly stupid
[quote=“Vermeer,post:37,topic:41467”]
The layout looks great, but the point I wanted to make about the graph structure wasn’t just making the rooms accessible, but ensuring actual cycles in the room network. The reason for this is that cycles allow for choices in how to approach specific targets or problems.
If I might take the liberty of illustrating the point with an example dungeon populated with various frivolous yet terrifying dangers-
http://s22.postimg.org/d1k65n3a9/dungeon_layout.gif
Let us suppose that our Noble and Photogenic Hero wishes to secure a lifetime’s supply of chocolate. S/he now has at least three options for tackling the problem- go through the Lohan-Montana hybrid followed by the Grue, go through Rube Goldberg and then the Dragonz, or discover the secret passage that allows the latter to be bypassed. The Grue can be kept at bay simply by lighting a torch, but those are in limited supply, and might be used up searching for traps (such as those laid by Mr. Goldberg) or secret passages (which also reveal the S.V. Love-Shrine, which confers immunity to the Lohan-Montana Hybrid.) So there are quite a few tradeoffs and decisions to be made within that pretty simple framework, which might be further complicated by how much the player knows or can find out about impending obstacles. And of course, terrain along the way could be used as an asset to the player (e.g, flooded passages being impassable to Dragonz.)
Anyway, sorry to derail. Like I said, the layout looks very varied and the algorithm is fascinating. But my point is that if there were only one way to reach the lifetime’s supply of chocolate, then regardless of the obstacles presented, there are far fewer tradeoffs to be considered, because the player has no choice in the matter.
I have read the word Rougelike, and even after 2 people mentioning it I still did not see the error.
I have now re-named the game 3d Roguelike . The hero Vin Rouge may not now feature. But the colour red will perhaps still be a prominent feature of the graphical debug of the room generator.
Spelling the name of your game and thread wrong is quite silly, I even got one of those social JGO medals for being thorough. Now I just feel thoroughly stupid
[quote=“Vermeer”]
The layout looks great, but the point I wanted to make about the graph structure wasn’t just making the rooms accessible, but ensuring actual cycles in the room network. The reason for this is that cycles allow for choices in how to approach specific targets or problems.
If I might take the liberty of illustrating the point with an example dungeon populated with various frivolous yet terrifying dangers-
http://s22.postimg.org/d1k65n3a9/dungeon_layout.gif
Let us suppose that our Noble and Photogenic Hero wishes to secure a lifetime’s supply of chocolate. S/he now has at least three options for tackling the problem- go through the Lohan-Montana hybrid followed by the Grue, go through Rube Goldberg and then the Dragonz, or discover the secret passage that allows the latter to be bypassed. The Grue can be kept at bay simply by lighting a torch, but those are in limited supply, and might be used up searching for traps (such as those laid by Mr. Goldberg) or secret passages (which also reveal the S.V. Love-Shrine, which confers immunity to the Lohan-Montana Hybrid.) So there are quite a few tradeoffs and decisions to be made within that pretty simple framework, which might be further complicated by how much the player knows or can find out about impending obstacles. And of course, terrain along the way could be used as an asset to the player (e.g, flooded passages being impassable to Dragonz.)
Anyway, sorry to derail. Like I said, the layout looks very varied and the algorithm is fascinating. But my point is that if there were only one way to reach the lifetime’s supply of chocolate, then regardless of the obstacles presented, there are far fewer tradeoffs to be considered, because the player has no choice in the matter.
Thank you for that detailed scenario. Yes that is something I am concerned about. I plan to try and fix this by inverting the weighs of the graph edges and running the MST again and adding this to the original paths. The overlap of the 2 MST will yield info about key areas of the map that must be visited -such as a specific corridor features in both routes.
I perhaps wont go into as much detail as what you have outlined, but will need to implement this type of structure for using keys and locked door, and offer some choices, such as different types of enemies or play for different routes. Where a melee approach may be more or less favourable, or having a ranged weapon may be better…
I intend to do this by using A* path finding to carry out checks on placement of enemies, keys, door, goals, etc… to ensure the logic of the map is preserved.
Thank you again for taking the time to outline this, and with such humour to.
I take it from your use of Rube Goldberg that you are from the USA >in England we say Heath Robinson…
Thank you for that detailed scenario. Yes that is something I am concerned about. I plan to try and fix this by inverting the weighs of the graph edges and running the MST again and adding this to the original paths. The overlap of the 2 MST will yield info about key areas of the map that must be visited -such as a specific corridor features in both routes.
I perhaps wont go into as much detail as what you have outlined, but will need to implement this type of structure for using keys and locked door, and offer some choices, such as different types of enemies or play for different routes. Where a melee approach may be more or less favourable, or having a ranged weapon may be better…
I intend to do this by using A* path finding to carry out checks on placement of enemies, keys, door, goals, etc… to ensure the logic of the map is preserved.
Thank you again for taking the time to outline this, and with such humour to.
I take it from your use of Rube Goldberg that you are from the USA >in England we say Heath Robinson…
[quote=“Vermeer”]
Hmm. Have to blame global monoculture for that. Not from the states myself, but that’s the name I picked up. Learn something every day, I guess…
Anyway, I should probably apologise, since I’ve taken up far too much space already, but I just wanted to say that I wouldn’t automatically expect that kind of complexity. It’s just an illustrating example that I hoped wouldn’t be taken too seriously.
[quote=“Vermeer,post:47,topic:41467”]
Hmm. Have to blame global monoculture for that. Not from the states myself, but that’s the name I picked up. Learn something every day, I guess…
Anyway, I should probably apologise, since I’ve taken up far too much space already, but I just wanted to say that I wouldn’t automatically expect that kind of complexity. It’s just an illustrating example that I hoped wouldn’t be taken too seriously.
Are you still working on this Vermeer? It’s an awesome project!
Are you still working on this Vermeer? It’s an awesome project!
Thank you for the positive comments. I am putting it on hold for a short while to inversigate some other programming techniques.
I’ve been developing the blockworld game, and will be updating that soon. I’m looking at using shaders, multiplayer, and I’ve added sound.
Will come back to this armed with a bit more knowledge. hopefully!
Thank you for the positive comments. I am putting it on hold for a short while to inversigate some other programming techniques.
I’ve been developing the blockworld game, and will be updating that soon. I’m looking at using shaders, multiplayer, and I’ve added sound.
Will come back to this armed with a bit more knowledge. hopefully!
You said, in that thread, that you would be willing to share your knowledge. Do you think you would be able to point me towards some interesting multiplayer resources? I’d love to do some reading.
You said, in that thread, that you would be willing to share your knowledge. Do you think you would be able to point me towards some interesting multiplayer resources? I’d love to do some reading.
[quote=“Vermeer,post:53,topic:41467”]
Looking forward to it.
[quote=“Vermeer”]
Looking forward to it.
I will continue to share all block world code. Multiplayer is not done yet but look here…
Also here is a good resource:
http://www.java-gaming.org/index.php?board=19.0
I learnt how to start multiplayer from van zeben a video tutorials:
Such as opening sockets, making packets of data, parsing them, game flow, and concurrency.
[quote=“Morgan_Allen,post:57,topic:41467”]
Thank you, will be coming back to this.
I will continue to share all block world code. Multiplayer is not done yet but look here…
Also here is a good resource:
http://www.java-gaming.org/index.php?board=19.0
I learnt how to start multiplayer from van zeben a video tutorials:
Such as opening sockets, making packets of data, parsing them, game flow, and concurrency.
[quote=“Morgan_Allen”]
Thank you, will be coming back to this.