1
Early Dev / Re: Grand Rogue Auto 0.3.8
« on: May 06, 2011, 10:02:19 PM »
double post, sorry.
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.
Pages: [1]
2
Early Dev / Re: Grand Rogue Auto 0.3.8
« on: May 06, 2011, 09:58:21 PM »
Version 0.3.8 is available now.
Main Features:
- Damage types for weapons
- Run/walk toggle
- Armors
- Health system overhaul (localized health on each different body part)
- GFX and User Interface have been rewritten/improved
I'd really like some feedback from this board, even if it's purely negative. I deal well with criticisms so don't be afraid to do so. I do understand that GRA isn't technically speaking a roguelike, yet. But what I am going to introduce next (mission system) will definitively make it a RL. My main point, until now, was to build a coherent environment for the game to take place. I'm basically done with that, so randomized "dungeons", missions, and loot are going to be next.
If you have concerns, remarks, ideas, feel free to post here or on my blog.
Cheers,
SK.
Main Features:
- Damage types for weapons
- Run/walk toggle
- Armors
- Health system overhaul (localized health on each different body part)
- GFX and User Interface have been rewritten/improved
I'd really like some feedback from this board, even if it's purely negative. I deal well with criticisms so don't be afraid to do so. I do understand that GRA isn't technically speaking a roguelike, yet. But what I am going to introduce next (mission system) will definitively make it a RL. My main point, until now, was to build a coherent environment for the game to take place. I'm basically done with that, so randomized "dungeons", missions, and loot are going to be next.
If you have concerns, remarks, ideas, feel free to post here or on my blog.
Cheers,
SK.
3
Programming / Re: Advanced AI techniques in roguelikes (GOAP and HTN planners)
« on: February 16, 2011, 06:11:35 AM »
From what I gather from your post the player is against squads of enemies. This is a bit short to say the least. Knowing exactly what you want to achieve and the general combat mechanics would help a lot 
More importantly the efficiency of an AI is usually depending on the map information / environment. Without knowing about it doesn't help providing any advice (and explaining those can be overwhelming to the reader anyway).
I have not dabbled into planning systems in any projects I have done before. From what I (think to) know they are more suited to strategical game than tactical ones, but I could be wrong. Still, here's a thing for you to consider:
Is the player going to see the difference between this (quite obviously) very long to write, test and debug AI system and a simpler model? As a programmer interested in AI, I perfectly understand that this is quite fun to experiment with, compare to other systems and so on. But if you're planning to publish it as a public/popular game, this may be not the most important factor to look for. Roguelikes (and most fps, tactical games) usually have somewhat modified FSM or Fuzzy Logic systems for combat mechanics, usually because they don't need more and because it's efficient enough.
I realize that this paragraph could be read as "don't do it". I apologize for that. On the contrary, I would be very interested to get updates from you on this game, or even the prototype and general logic you've put in it. If you're doing the project for yourself in priority, go wild with any idea you have, otherwise you may want to consider what users are expecting in priority.
This said, it probably won't help you much, but last time i had a try at squad combat I did something a bit different (that may be reused partially in my own project, GRA). There's probably an official name for it, but let's call it "dynamic terrain" for now. The concept is the following:
Each square of the map have a bunch of combat related variables that can be assigned to it like the amount of cover, the ability to shoot easily from this square, the level of sound made while walking on it, and so on.
Each time the player moves, all squares in a given radius around him recalculate those variables based on his position, and eventually the position of other NPC (if X is there then my cover will be better because he'll be shooting at the player). For example a square at a distance of 5 from the player with 2 squares occupied with crates or other furniture will have a high cover rating but a low offensive rating. Once calculated, you'll get obvious positions around the player for your NPC to hide (reload and heal), somewhat secure paths to flank the player, positions from where your NPC can get a ranged shot easily before going into cover again, and so on.
So each NPC depending on his stat / needs will choose the most appropriate square to go to without having to rely on anything else than a FSM/Fuzzy mechanism. The NPC look like they are coordinating an attack to the player's eyes when in reality the terrain is dictating where they should go to satisfy their current state.
But it really depends on the combat system here. If it's a regular roguelike with no possibility to run, burst shot, or well do at least 2 actions in a single turn, any advanced AI system is kinda pointless, IMHO.
Cheers,
SK.
More importantly the efficiency of an AI is usually depending on the map information / environment. Without knowing about it doesn't help providing any advice (and explaining those can be overwhelming to the reader anyway).
I have not dabbled into planning systems in any projects I have done before. From what I (think to) know they are more suited to strategical game than tactical ones, but I could be wrong. Still, here's a thing for you to consider:
Is the player going to see the difference between this (quite obviously) very long to write, test and debug AI system and a simpler model? As a programmer interested in AI, I perfectly understand that this is quite fun to experiment with, compare to other systems and so on. But if you're planning to publish it as a public/popular game, this may be not the most important factor to look for. Roguelikes (and most fps, tactical games) usually have somewhat modified FSM or Fuzzy Logic systems for combat mechanics, usually because they don't need more and because it's efficient enough.
I realize that this paragraph could be read as "don't do it". I apologize for that. On the contrary, I would be very interested to get updates from you on this game, or even the prototype and general logic you've put in it. If you're doing the project for yourself in priority, go wild with any idea you have, otherwise you may want to consider what users are expecting in priority.
This said, it probably won't help you much, but last time i had a try at squad combat I did something a bit different (that may be reused partially in my own project, GRA). There's probably an official name for it, but let's call it "dynamic terrain" for now. The concept is the following:
Each square of the map have a bunch of combat related variables that can be assigned to it like the amount of cover, the ability to shoot easily from this square, the level of sound made while walking on it, and so on.
Each time the player moves, all squares in a given radius around him recalculate those variables based on his position, and eventually the position of other NPC (if X is there then my cover will be better because he'll be shooting at the player). For example a square at a distance of 5 from the player with 2 squares occupied with crates or other furniture will have a high cover rating but a low offensive rating. Once calculated, you'll get obvious positions around the player for your NPC to hide (reload and heal), somewhat secure paths to flank the player, positions from where your NPC can get a ranged shot easily before going into cover again, and so on.
So each NPC depending on his stat / needs will choose the most appropriate square to go to without having to rely on anything else than a FSM/Fuzzy mechanism. The NPC look like they are coordinating an attack to the player's eyes when in reality the terrain is dictating where they should go to satisfy their current state.
But it really depends on the combat system here. If it's a regular roguelike with no possibility to run, burst shot, or well do at least 2 actions in a single turn, any advanced AI system is kinda pointless, IMHO.
Cheers,
SK.
4
Traditional Roguelikes (Turn Based) / Re: DoomRL 0.9.9.2 released
« on: February 15, 2011, 07:02:06 AM »
Nice!
Glad to see a new update as DoomRL is one of my favorite roguelikes.
by the way, months ago, a graphical release was in discussion on your board (with screenshots if i recall correctly). Is this still planned?
Glad to see a new update as DoomRL is one of my favorite roguelikes.
by the way, months ago, a graphical release was in discussion on your board (with screenshots if i recall correctly). Is this still planned?
5
Early Dev / Re: Grand Rogue Auto 0.2.1 [test build]
« on: February 14, 2011, 07:23:08 PM »
version 0.2.1 is now available.
Comprehensive changelog:
- Add items (healing, food stuff) and related shops
- Items can also be bought in hospitals and restaurants
- Item Editor Included (effect editor will follow in next version)
- Gang members roaming the streets (very basic at the moment)
- GUI overhaul: Inventory and shop windows show info regarding selected item
- Numerous Bug fixes and speed optimizations.
Windows 32.
Works with Linux when using Wine (no visible issue so far).
Cheers,
SK.
Comprehensive changelog:
- Add items (healing, food stuff) and related shops
- Items can also be bought in hospitals and restaurants
- Item Editor Included (effect editor will follow in next version)
- Gang members roaming the streets (very basic at the moment)
- GUI overhaul: Inventory and shop windows show info regarding selected item
- Numerous Bug fixes and speed optimizations.
Windows 32.
Works with Linux when using Wine (no visible issue so far).
Cheers,
SK.
6
Temple of the Roguelike / Re: Spam Filter for Forum
« on: January 28, 2011, 05:25:16 PM »There's several solutions to deal with spam bots.
- Using ReCaptcha for user registration is usually enough to get rid of 90% (or more) of the spam bots. Very few pass this kind of protection. Usually only those using 'paid' people in poor countries instead of algorithms are successful here.
- Black list well known spam related IP ranges.
- Forbid users with less than X post to post links on the board.
- Most forum and website systems have relatively well working anti-spam plugins. I'm using Akismet myself on some of my websites and so far it has been 100% successful. I'm pretty sure they have a plugin for SMF too.
7
Early Dev / Re: Grand Rogue Auto 0.2.0 [test build]
« on: January 28, 2011, 02:25:58 PM »
Weird, I have no issue with Mediafire myself. Anyway, I posted a mirror link on one of my other websites.
Note to others: use this mirror only if mediafire doesn't work for you, my bandwidth is limited.
Note to others: use this mirror only if mediafire doesn't work for you, my bandwidth is limited.
8
Temple of the Roguelike / Re: Welcome to Temple of the Roguelike Forums! (a.k.a. Introduce Yourself Thread)
« on: January 28, 2011, 09:14:47 AM »
Hi everyone.
So I'm Serial Kicked, a Delphi/Pascal coder and modder from France and the author of Grand Rogue Auto, a graphical roguelike currently under development.
I've discovered the roguelike genre with Angband (a variant). Loved it, even if I have to admit that I never finished it. I've played most of the major recent roguelikes like DF, rogue survivor (hi roguedjack! btw), Crawl, DoomRL and so on. In general, I am a big consumer of indie and/or open-ended games.
I'm also the author of several popular modifications for X2, X3: Reunion and X3: Terran Conflict games from Egosoft.
Cheers,
SK.
So I'm Serial Kicked, a Delphi/Pascal coder and modder from France and the author of Grand Rogue Auto, a graphical roguelike currently under development.
I've discovered the roguelike genre with Angband (a variant). Loved it, even if I have to admit that I never finished it. I've played most of the major recent roguelikes like DF, rogue survivor (hi roguedjack! btw), Crawl, DoomRL and so on. In general, I am a big consumer of indie and/or open-ended games.
I'm also the author of several popular modifications for X2, X3: Reunion and X3: Terran Conflict games from Egosoft.
Cheers,
SK.
9
Early Dev / Grand Rogue Auto 0.3.8 [May, 6th, 2011]
« on: January 28, 2011, 08:51:22 AM »
Hi everyone,
I'm the author of the newly released Grand Rogue Auto (GRA).
The game is still in a early stage of development, but it's now publicly available on my website.
GRA, beside being a graphical (kind of) roguelike, aims at being a highly customizable city simulator with persistent NPC including different factions and a relatively complete trading and production system. The player will gain money by completing random missions, wreaking havoc, and working for different factions. This money can be used to buy ammo, weaponry, armors, locations and so on. As you can easily guess the gameplay is heavily influenced by the GTA games. I am trying to mix the open-ended aspect of GTA with the complexity and replay value of roguelike games in a modern setting.
Of course I am very far from that goal. GRA is basically 6 months old and I work on it on my free time only. It is written in Delphi (for Win32), but there's a good chance that it would works on Linux using Wine as I don't use any fancy library.
You can also read the development blog I put in place.
It's full of design documents, screenshots, videos and information about this first project.
Anyway, this first Test Build (not even alpha) has the following features:
You can download GRA here.
Note: I can't stress enough that this is a test build and not a fully functional game. There's no quest, no goal other than survival, but there's probably a lot of bugs.
Questions, ideas and such are more than welcome.
Cheers,
SK.
I'm the author of the newly released Grand Rogue Auto (GRA).
The game is still in a early stage of development, but it's now publicly available on my website.
GRA, beside being a graphical (kind of) roguelike, aims at being a highly customizable city simulator with persistent NPC including different factions and a relatively complete trading and production system. The player will gain money by completing random missions, wreaking havoc, and working for different factions. This money can be used to buy ammo, weaponry, armors, locations and so on. As you can easily guess the gameplay is heavily influenced by the GTA games. I am trying to mix the open-ended aspect of GTA with the complexity and replay value of roguelike games in a modern setting.
Of course I am very far from that goal. GRA is basically 6 months old and I work on it on my free time only. It is written in Delphi (for Win32), but there's a good chance that it would works on Linux using Wine as I don't use any fancy library.
You can also read the development blog I put in place.
It's full of design documents, screenshots, videos and information about this first project.
Anyway, this first Test Build (not even alpha) has the following features:
- 4 zones types: city centers, suburbs, industrial districts, and city streets.
- A dynamic faction system
- A localized damage system
- Several building types: weapon shops, houses, parks, work places, restaurants, hospitals...
- Customizable city size
- Living citizens who work, eat, sleep and go to a hospital when wounded
- A complex combat system with a rather effective (but stupid) AI
- Cops patrolling the streets, looking for criminals
- Ability to use beds and other items to satisfy your needs
- Wanted Level
- Unsupported modding tools to break the game
- Tons of weapons to choose from.
- Keyboard and Mouse compatibility for all commands
You can download GRA here.
Note: I can't stress enough that this is a test build and not a fully functional game. There's no quest, no goal other than survival, but there's probably a lot of bugs.
Questions, ideas and such are more than welcome.
Cheers,
SK.
Pages: [1]