Messages

1

Early Dev / Re: Ultima Ratio Regum development feedback

« on: August 03, 2013, 07:37:52 PM »

Many thanks for the detailed feedback.

#1 - "Start New Game" should flash red to denote it does not work. Is this what do you mean, or does it not flash for you playing on wine? If you don't see the flash, maybe I'll have it greyed out instead until you gen a world.
#2 - do you mean the double grey lines? If so... I don't agree, but interesting feedback. What would you suggest instead?
#3 - Are you using 8x8, 10x10, or 12x12? I'll look at the g/y.
#4 - Thanks
#5 - It should display instantly, and it always does for me. Do you mean you press Enter, the game "stops" as it's busy generating that area, then after a second or two the "Offloading..." bit appears? If so, I fear that is a wine-only problem, but I'll look into it.

Otherwise, very pleased it works in wine (apart from those two issues which may be wine-only). How long does it take to gen a map grid?

#5 yep, exactly what I mean.
#1: Yeah neither start new game nor load saved game flashes red if no worlds/saves exist.
As long as it works properly in windows I wouldn't worry much about it, #5 is only a (minor) issue for people on low end pc's I suspect.

#2: I mean the squiggly white overlapping (pretzel) lines along the main window border. It isn't a big deal, I just think they stand out.
#3: 12x12. I'm unused to read large amounts of monospaced text though, probably why.

Generating a new map grid takes about 10 seconds on an old Centrino 2 laptop.

I can't seem to tell whether there is water under a tree's branches. This could perhaps be a problem in the future if you are fighting something and start swimming without meaning to? Example: The tiles to the east and south of the player is here water. Image

Consider wrapping for the arrow-key-navigation in the guidebook.

2

Early Dev / Re: Ultima Ratio Regum development feedback

« on: August 03, 2013, 03:07:24 PM »

I'm a bit short on time right now, so some first impressions.
(I'll edit in more later)

Attempting to start a new game when no worlds exist gives no feedback, nothing happens.
The window border texture in the menus should perhaps be reconsidered, it's a bit big and stands out.
The font for the help text is hard to read. The g's and y's etc are very peculiar.
What I've seen of the visuals so far have been very impressive. I usually get lost in ASCII-ish graphics, but these are very well done.
If possible display the offloading dialogue instantly when walking across "zone borders" or what they're called, for me it takes a second or two for it to appear. The same problem appears when fast traveling.

The game works great right out of the box using wine, assuming there is no music or sound yet as I've yet to hear a sound.

3

Early Dev / Re: Axis of X

« on: July 26, 2013, 10:10:17 AM »

Error 404 for the "Ingame" screen...

http://i.imgur.com/V1iNfHx.png this should work, I had linked to the uploader's panel.

4

Early Dev / Axis of X

« on: July 26, 2013, 09:22:58 AM »

My first roguelike game is coming along slowly/nicely. It is nowhere near done, but I think at this stage it is possible to get a feel for the gameplay with the included prototype.

Setting:
The player is chased by the last boss, he knows at all times how many tiles said boss is behind him. The goal is to reach the end of the dungeon before it. Enemies can be skipped, but doing so feeds the boss - making it stronger. 

The player has two resources: Health and Energy. Energy is only restored by resting, but the player can do simple actions at 0 energy. Resting takes a significant amount of time.

(Planned) Core features:
The game is a one dimensional turn-based roguelike, levels and items are randomly generated. The combat mechanics are inspired by D&D's attack/damage/evade rolls, the player gains experience by killing monsters encountered.
Each turn the player may either do simple movement(move 1 tile, wait, rest, open door), simple melee combat (attack 1 enemy) or execute 1 to 4 skills (at an increasing cost).
Races, worn weapons and classes decide which skills the player may pick/use, on each levelup the player picks another skill. Skills are very powerful, but costly.
Monsters have some semblance of intelligence (a stack of prioritized behaviors unique for each monster type).

Implemented so far (%):
Procedural level generation. (40% simple prototype running, need to add monster levels, random items)
A working system for turn based actions. (60%, missing timed effects, delayed effects, the boss)
Combat, skill execution. (70%)
A halfway done model for races/classes/monstertypes. (40%, needs a revamp)
An ok model for monster behaviors. (80%)
A good beginning for skills and SkillEffectFunction factories. (30%)
Simple SDL 2D rendering, no animations. (100%, a tad ineffective but my computer don't seem to care.)
Game balance. (0.01%)
Content. (3%)

Glaring flaws:
The console output messages are bad, I need to rewrite them.
The game is not even slightly balanced (ogre fighters wtf).
Crossbowmen flee by default instead of seeking to maintain bow range.
Boss does not exist yet.
Some "GUI-boxes" are still misaligned, "speed penalty" is mislabeled.
A clock or some visual representation of time elapsed is sorely needed.

This how it looks:
Splash screen (oh my god it is ugly): link
Ingame: link

To play:
Build from source (multi platform): download zip https://github.com/halvorgb/axisofX -> extract, navigate to folder -> runhaskell Main or ghc --make Main
Linux binary: http://www.sendspace.com/file/i5qggw
I couldn't get haskell-platform to work under wine so I only have ready made linux 32bit binaries, sorry. I'll get hold of a windows PC and compile it, as I'm sure noone would want to install a development platform/compiler just to test a game.

Dependencies: libsdl, libsdl-image, libsdl-ttf.

A few specific things I am interested in hearing opinions of:
How does the skill queue interaction work for you? i.e. it always fills from left to right if you pick any unassigned skill queue number. Should skills be cleared when they are executed? (ENTER) right now they are not. That you can't cancel the skill choice menu is a weakness, you can only clear the choice or choose a skill. Is it important?

Is it okay to not be able to hold down A and D for repeated sideways movement? They aren't pressed for long distances.

Do I need to color code the combat log? Perhaps timestamp it + a visible clock. Right now it looks bad.

I'll think of more, but right now I'll boot up my old Pentium 4 windows machine.

5

Temple of the Roguelike / Re: Welcome to Temple of the Roguelike Forums! (a.k.a. Introduce Yourself Thread)

« on: July 24, 2013, 03:49:39 AM »

Halvor is a norwegian name, right? Old viking name.

Yep, Norwegian name.

snip

I'd love to see the evolutionary enemies RL... What language are you coding in?

I'm coding in Haskell.

That potential RL lies way ahead in the future, I'm still struggling with my first simple 1D game.
I'm baffled by people's ability to code a complete game in 7 days - hopefully it gets easier for each game made!

6

Programming / Re: Single Screen Procedural Platformer Levels...

« on: July 19, 2013, 12:08:57 AM »

Yeah, and in the end does it add much to your game? Does it up the fun factor at all?

Well, that depends on how you'd do it of course.

It's just that I have played some games where the procedurally generated content is too "transparent", i.e. you can easily distinguish the puzzle pieces used to generate the levels - making them less fun in my opinion. (Dungeons of Dredmor is a big sinner in this regard in my opinion.)

It's a bit unfair of me to assume your random generation would be bad simply because there are some bad examples, I see that, sorry.

7

Programming / Re: Single Screen Procedural Platformer Levels...

« on: July 18, 2013, 11:58:58 PM »

If you divide the level up in W * H vertices you can randomly generate edges between said vertices. Adding constraints on where the algorithm is allowed to place the edges.

Example constraints could be: Max nof. cyclic edges (a cyclic edge would be a solid unpassable block), max edge length, minimum horizontal/vertical edge distance, max number of corners in an acyclic edge, allow diagonal vertices?, etc...

Maybe it is a bit naive to assume that this would work well without lots of hassle, I don't know. It makes your levels more random than a puzzle of ready-made blocks though, and you could potentially make visiually nice levels if you limit max edge length as well - as there is a finite amount of shapes that can be made with a edge of length x.

You'd have to test&tweak a lot : )

Edit: This approach is not that different from assembling ready-made components now that I think of it, but you could create more diverse levels that are not as visually impressive with looser constraints and a high vertex resolution for your algorithm.

8

Temple of the Roguelike / Re: Welcome to Temple of the Roguelike Forums! (a.k.a. Introduce Yourself Thread)

« on: July 16, 2013, 05:30:19 PM »

Welcome to the forums.

Have you played Warning Forever?  It uses a similar concept to the evolutionary enemies thing you mentioned.

I haven't, it looks interesting though.

9

Temple of the Roguelike / Re: Welcome to Temple of the Roguelike Forums! (a.k.a. Introduce Yourself Thread)

« on: July 15, 2013, 10:28:04 PM »

Hey I am Halvor G.

I've just finished my bachelor's degree in informatics and I'm going to start my master's this fall. I like functional programming (although I'm not much more than a novice at it) and bio-inspired AI. The reason I joined up here is because I need to hone my skills more outside of schoolwork and I've decided to create my first (roguelike) game. The game will probably be shit and progress is really slow because I am coding in an unfamiliar language/paradigm, but I hope to learn much making a game from start to finish. Also, I'm having tons of fun.

I've played lots of ToME, some Dungeons of Dredmor, DCSS and DoomRL. I've never won any of these games, but I've come close in ToME.

If I keep putting some time into RL development I hope to make some more experimental RLs. An RL where you face enemies generated by an evolutionary algorithm would be cool I think, as your future enemies will be generated from the ones you struggled the most with - forcing you to diversify your tactics or get crushed.

Sometimes I daydream about making a roguelike/open world space/economy game set in a turn based dynamic 2d universe akin to that of the X games (the computer games, not the extreme sport games ), but 'tis a silly dream for now.

I've never been much of a forum poster, but from what I've lurked so far I really like these forums.

10

Programming / Re: Making a one dimensional roguelike interesting.

« on: July 15, 2013, 02:03:56 PM »

But- imo, at that point things are becoming uninteresting in the 1D sense, as you're just emulating 2D in 1D.

Good point.

11

Programming / Re: Making a one dimensional roguelike interesting.

« on: July 15, 2013, 12:53:38 AM »

I've experimented with lots of different methods of rendering the game, I've landed on SDL for now.

Simple combat is well on its way, but I am a bit stumped on how to show multiple enemies in one tile (currently 16x16) given that there will be more than a couple different kinds of enemy. (having n "subtiles" in a tile breaks if  there are n+1 enemy types)

An examine button would of course work, but that is not something that the player should be forced to do every other turn.

This is a snapshot of how it looks right now [http://i.imgur.com/VkHwvIm.png], please ignore the unaligned/overflowing text and rough boxes, everything is very temporary. I like the simple representation of the game world up top, but it isn't powerful enough to adequately show multiple enemies on the same tile.

If I limit the view distance a lot I could have a textual description of every enemy in sight available somewhere, I think that is the better solution right now. -- But I still want the player to have movement skills such as jump or charge available, which requires a minimum of view distance for it to make sense.

12

Programming / Re: Making a one dimensional roguelike interesting.

« on: July 04, 2013, 04:31:46 PM »

Thanks for the feedback, I like using time as a second dimension and as a constraint.

I've been thinking of a concept/setting where the protagonist must outrun the "last" boss until he reaches the end - and only then slaying it. I'm not sure why he'd do that as of yet, maybe the glorious king has promised a reward for whoever kills the Great Beast(tm) infront of his court? The reasoning is not important

Some core gameplay mechanics thoughts:
Resources: Energy and Health
Health is regained by picking up health globes like those from diablo 3.

Every action the player takes depletes energy, the player may do up to n actions per turn, but every additional action comes with an increased energy penalty.
Energy is only regained through resting.
 -- Resting takes a long time, the boss will gain ground while the player rests.

The chase:
If the player is too conservative on his energy consumption for each tile moved forward the boss will catch up to him.
If the player is too reckless with his energy consumption for each he will need to rest more often - the boss will catch up to him.

Almost any enemy can be skipped, but the boss will devour every skipped enemy. Gaining ground and/or strength.
If the boss catches up to you too early, you can still kill it(unlikely), but you won't get the bonus score you'd get if you had lasted all the way to the end.
--

As for combat, classes, skills, levels and such I have to think more on it, multiple actions per turn (at a penalty) sounds cool and all, but it has to be done in a way that ideally doesn't force you to navigate through different menus (something I'm not really a fan of). How characters progress etc. is almost arbitrary to me, provided the implementation is good.

Another cool thing would be (rare) random encounters like in FTL. (ex. if you do not help peasants on your way to the Great King(!) militias may show up later in the game to impede your progress [as the last boss wrecked havoc in your footsteps]). This is way into the future though and too much to start working on right now.

Barring major negative response I think I'll work on implementing the chase and a simple combat system for a first prototype.

13

Programming / Re: Roguelike with every (well not actually every) Genre!

« on: July 04, 2013, 03:56:33 PM »

I'm not sure I understand, do you want a game where these worlds/settings clash? Or do you want to make one roguelike with several optional themes?

14

Programming / Re: Making a one dimensional roguelike interesting.

« on: July 03, 2013, 03:04:42 AM »

Many good ideas here.

I'll sit down sometime this week to flesh out the design, thanks for the help!

15

Programming / Making a one dimensional roguelike interesting.

« on: July 02, 2013, 01:23:26 PM »

Hey, first post!

I'm learning a new programming language and figured I'd make a roguelike game, I have zero ambitions for success or whatever.

As I am new at this I decided to make it one dimensional, by that I mean that the player can only move left or right, not up and down. A simple screenshot to illustrate:

(seen from the side)

So obviously gameplay can get stale to say the least with no room to manouver, but I have some ideas to make more out of it than simply holding num 6 until you win : ).

The ideas I've tossed around in my head are as follows, nothing is implemented yet because I've worked on the "engine" if you can call it that.

Monsters must be able to stack.
Diverse set of weapons with various effects, i.e. spears can pierce through several tiles, axes can hit several enemies on one tile etc.
Minimum range for spells and ranged attacks.
Very unforgiving side scrolling, the game only wraps to the right.
Possible ability to leap over floor tiles, converting floor tiles to lava etc.
Usual features like doors,variable light radii or view distance and gear/levels/classes/races etc.

So what I hope is to get some ideas from you guys on how to make the gameplay slightly interesting!

(Code is here if anyone is curious, nothing to look at really. https://github.com/halvorgb/axisofX)