Messages

31

Programming / Re: Procedural Plot

« on: November 04, 2012, 04:34:39 PM »

That usually comes from having lots of different interactions between elements.

Otherwise, so long as you expand your levels as a tree you should be able to put on a new branch that is relavent to the player's inventory and history. A story will appear to have occurred because of these "coincidences".

32

Early Dev / Re: Red Rogue (platformer roguelike)

« on: October 10, 2012, 06:36:58 PM »

The game is now at the bugs and polish stage. I've got some outstanding issues to fix, then I need to let the game cool down before playing the shit out of it to make sure it's stable and balanced for release.

Lots have been added since I last posted. Mostly bug fixes:

Altars to Rng: basically like magic slot machines - more a way for me to show off mechanics that are hidden by esoteric usage of runes really. Encourages players to experiment with magic to replicate the altar's effects.
Torches: I realised that the Dungeons is a low CPU area so I could afford some lights to help new players explore. It also helps make the Sewers feel different.
Endings: Multiple!
Saving: The game saves every at every level now, you can continue from the title screen.
Start in Dogmatic Mode: The option is there from the title screen so everyone can be a purist about the mechanics.
Easter Egg Items: Tribute items for people who have helped tune the game.
Elite mobs: With special powers and yummier loot.
The Boss: A sneaky bastard who's too smart to fight you directly.
Various UI and Balance Shit: Lots and lots of little tweaks and bug fixes across the game.

33

Programming / Re: Trouble implementing A*

« on: October 07, 2012, 08:08:20 PM »

Eh, this is what I did for my A*:

https://github.com/st33d/red-rogue/blob/master/src/com/robotacid/ai/MapGraph.as

It's uses some optimisation hacks based on some shortcuts I realised you could take in the representation of the closed and open lists. It also defaults to a metaheurisic path if the steps limit is reached, perfect path finding over large distances isn't essential for close combat.

The function that does the magic is getPathTo()

34

Programming / Re: Finishing a Game

« on: September 30, 2012, 01:53:44 PM »

I'm supposed to be programming the set-piece for the ending to the game right now. 

35

Programming / Non-random roguelike

« on: September 30, 2012, 01:52:45 PM »

So I've made a DRODlike recently: http://www.nitrome.com/games/turnament/

Due to the puzzle design, there is literally no call to a random number generator in the game code. Even when the AI is stuck it considers nodes anti-clockwise starting from the next step round each turn. There is a perfect solution to every battle and level.

This got thinking about making a roguelike that was completely non-random as well. It would appear random - however, it would be the player's movement that would change what the next room was or what was in it. It would somewhat be like exploring a fractal landscape.

It's a coffee-break idea so I think it deserves a single hit point model. The starting position is the most interesting bit of the game, so you should see it a lot and play with it.

-

So has anyone done stuff like this before? I know Ulf at the roguelike conference did a presentation on sequential combat and that has parallels with this idea of mine.

36

Traditional Roguelikes (Turn-based) / Re: Let's Ascend - Cardinal Quest

« on: September 29, 2012, 03:03:28 PM »

Played it a bit and eventually rolled thief and got two sneak skills early on. I then slaughtered everything by chaining sneaks and buffs with an aim to never receive strikes.

Didn't get far with the fighter as it's easy early game and few options late game. The wizard I thought I'd save when I feel like trying to beat it again.

37

Other Announcements / Re: Roguelike Radio podcast

« on: September 10, 2012, 08:59:58 PM »

An episode on Mercury would be good. I find it a bit pointless to play, but it's fun for a quick dip in dip out. Since it changes regularly it tends to stay fairly fresh. I find myself playing it not for the score but for just a quick and simple dive without all the frills.

-

Regarding yours and Andrew's discussion on cardinal/diagonal/hex - pillar dancing is irrelevant. In a cardinal movement system, if you are a multiple of two tiles away you will always be hit first unless you can perform a wait action. Thus if you are an odd number of tiles away you will always hit first.

Therefore: if you only have cardinal movement and no wait action, your distance to one monster is irrelevant. It is whether the distance is a multiple of 2 that matters. Try it for yourself on paper.

With diagonal movement you get to jump back and forth each side of the binary system. Distance now matters.

I thought that with hex you would have the same issue with cardinal grid movement, but on trying it out on paper I'm not getting the same result. I can spend a turn but still be the same distance from the enemy - thus distance does matter in hex, yet it doesn't have the binary system that grids impose.

Not that the binary system isn't fun. But it does have a big impact on AI and on survival.

edit: multiple of 2 not factor of 2 

38

Other Announcements / Re: 50 Days till the Annual Roguelike Release Party

« on: September 08, 2012, 11:23:55 PM »

I've got two endings left to write and the outstanding bugs list.

Wouldn't have time for polish if I tried to finish in time. Oh well.

39

Traditional Roguelikes (Turn Based) / Re: Steam Greenlight

« on: September 03, 2012, 10:34:39 PM »

*cough

Really should give Epilogue a spin. There a Mac build of it?

40

Early Dev / Re: AURO Gameplay footage (alpha)

« on: August 12, 2012, 02:09:12 PM »

Looking interesting as well as pretty slick.

Will there be any environmental features to the maps? (I guess I mean ice or flame patches that aren't just from skill usage - or perhaps you may have some other ideas.)

41

Early Dev / Re: Red Rogue (platformer roguelike)

« on: August 12, 2012, 01:51:37 PM »

Current release is stable enough for me to announce that the game will now save all of your menu settings (including Lore unlocked).

Also:

Portals are now permanent. That means you can create permanent shortcuts to later levels and move the underworld portal to that level where you keep losing the minion (the underworld portal resurrects the minion).

And:

A Shiren the Wanderer warehouse mechanic! In the story the underworld and overworld are supposed to exist "outside of time". That means you can drop off as many items as you like in there and grind up a suitable arsenal. Keep in mind that you have to leave a level for the game to save your item collection to the save file.

I'm currently working on save and quit so you'll be able to go for a decent dive and then come back to the game later.

42

Other Announcements / Re: Roguelike Radio podcast

« on: July 30, 2012, 10:16:18 PM »

A good interface should probably reflect the developer's preferences.

You need to play some of the Dev Log games on TIGSource to find out why this sentiment is utterly, utterly wrong. Developers often have the least idea of usability. Developers are also notoriously lazy.

I think what you need is an entry point for newbies, but support the wishes of the hardcore players. The hardcore are going to play your game the most. But the hardcore may not become hardcore if you don't let them pick up your game quickly.

43

Early Dev / Re: NDRL: n-Dimensional Roguelike

« on: July 26, 2012, 07:17:26 PM »

I escaped three worlds by blindly scrubbing back and forth until I found the exit. Then I got killed somehow by something I couldn't see.

The main problem is that you can only see where you're going on one axis . This would be fine except that it reduces the game to a scrub-fest, which doesn't really involve much thought.

A few things would be nice:

Don't represent blocked tiles with a few sparse rocks - walls are walls, don't be shy about it, fill the fuckers in. The fact that you have to explain that they are walls is a fundamental visual design flaw.

Make the maps smaller - don't fill it half in with wall. If you can't access half the map - don't have half the map.

Strip the input down to cursor keys. Left and right changes column, up and down moves between the planes.

Using the cursor key model, with a smaller map, you can now show a preview of the plane above and the plane below. This would allow players to understand how they are manipulating the map. No more random scrubbing.

Lastly - if you really want to push it into roguelike territory then you could add some items. I'm not sure it needs it, but it's an option.

44

Other Announcements / Re: Roguelike Radio podcast

« on: July 25, 2012, 06:25:53 PM »

You could post on reddit that you'd cured all forms of cancer and you'd still get about 19 downvotes.

Rogue has the rule baggage from RPGs and then dumps a load more exploration rules on top. I quite like "world" rules on top personally. It's more immersive than it being boiled down to a game of chess.

But rules beget dogma.

45

Programming / Re: Grid-Based Lighting

« on: July 22, 2012, 09:26:24 PM »

Perhaps you want to actually do a grid based version of polygon shadow casting. Here's a tutorial on the subject:

http://forums.tigsource.com/index.php?topic=8803.0

It doesn't actually involve a load of hit and hope raycasts. There are already less vertices to consider around the light source than firing out 100 odd rays.

The actual brightness of a tile referred to in the original post isn't actually realistic. Light doesn't fade, it gets absorbed. Your best bet would be to track the slices of light that get through then perhaps colour based on coverage.

Though after all that effort, I really doubt the player is going to care or notice the difference between that and one of the standard LOS algorithms with a few hard coded tweaks.