1
Traditional Roguelikes (Turn Based) / Re: Rogue Wizards (now available) $
« on: October 06, 2016, 11:46:27 AM »
It's as meaty as vegetable broth. Looks deceive. It's casual and kinda dumb.
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.
2
Traditional Roguelikes (Turn-based) / Re: Can anyone suggest a RL with:
« on: June 29, 2016, 03:26:51 PM »...
lastly no how could i've known that?! deaths(fuck you nethack)
...
Well, that's part of the charm of the genre, no? Live and (die and) learn
3
Programming / Re: Generic algorithms for complex data?
« on: June 22, 2016, 01:03:20 PM »
I have something similar but even simpler, the shapes are just a vector of 2D points, you don't need to have a class hierarchy for that (Generic_Whatever). Just have a bunch of functions e.g.
void make_circle(std::vector<point2d>& shape, point2d center, int radius)
void make_rectangle(std::vector<point2d>& shape, point2d lower_left, point2d upper_right)
etc...
void make_circle(std::vector<point2d>& shape, point2d center, int radius)
void make_rectangle(std::vector<point2d>& shape, point2d lower_left, point2d upper_right)
etc...
4
Design / Re: Corridors considered harmful
« on: June 22, 2016, 12:02:54 PM »
Even though I love corridors, here's a good example of space-efficient, kinda corridor-less dungeons:
http://worldofortix.blogspot.ch/2012/02/mordor-11-maps.html
http://worldofortix.blogspot.ch/2012/02/mordor-11-maps.html
5
Programming / Re: Generic algorithms for complex data?
« on: June 22, 2016, 10:38:46 AM »
Use what you said. A list of 2D coordinates. It's enough to define a shape in a 2D grid. Then you can do with them whatever you want. Templates would replicate code needlessly. Any other crafty stuff just adds unnecessary complexity.
6
Design / Re: Info line idea
« on: June 14, 2016, 10:45:04 PM »
This fits like a glove:
https://xkcd.com/386/
It's a bit sad when "hot" topics have nothing to do with the actual subject matter and more about people resorting to intellectual variants of name-calling.
https://xkcd.com/386/
It's a bit sad when "hot" topics have nothing to do with the actual subject matter and more about people resorting to intellectual variants of name-calling.
7
Design / Re: Info line idea
« on: May 12, 2016, 10:41:19 AM »
This "info line" is also called "status bar", and it has been useful since kinda forever in GUI (and shell?) applications ...
If you'll have mouse cursor, do it, can't hurt.
If you'll have mouse cursor, do it, can't hurt.
8
Off-topic (Locked) / Re: Game research - 4x and card games
« on: May 10, 2016, 12:54:21 PM »
Your "Pro" parts are not favorable; you are misusing the term (https://en.wiktionary.org/wiki/pros_and_cons). It looks like it's the main observation from the graphs. Similarly, the "Cons" do not show anything unfavorable - they rather look like suggested courses of action.
9
Incubator / Re: My Rogue Like Pixel Art
« on: March 04, 2016, 08:40:32 AM »
imho looks much better now -- not sure I like the fog though
-- not sure I like the fog though
10
Incubator / Re: My Rouge Like Pixel Art
« on: March 02, 2016, 08:32:46 AM »
You have 2 different variants on the same "title" screenshot. The big blue letters (spelled correctly) and the white letters in the black box, where you spell it wrong. I can understand typos and spelling mistakes (e.g. "Challange", bottom-left), but not in the *product title*...
By the way, sorry to be nitpicky, I just hate this misspelling -- tiles look good, they probably need some masks to shine. I'd also agree with Krice on that the background tiles have too much contrast and stand out too much, therefore making it a bit difficult to say what's foreground and what's background
By the way, sorry to be nitpicky, I just hate this misspelling -- tiles look good, they probably need some masks to shine. I'd also agree with Krice on that the background tiles have too much contrast and stand out too much, therefore making it a bit difficult to say what's foreground and what's background
11
Incubator / Re: My Rouge Like Pixel Art
« on: March 01, 2016, 06:51:52 PM »
They are not as red as I thought they would be, mon ami 
12
Programming / Re: Can someone explain "Dijkstra maps" to me, please? Are they even a thing?
« on: February 24, 2016, 12:01:53 PM »13
Design / Re: OOP, ECS, Roguelike, and definitions
« on: February 15, 2016, 10:59:20 AM »
Don't get me wrong, I'm all pro ECS (especially for RPGs/roguelikes), and I've been using it already. Ok, if the implementation is indeed very optimized, it's rather unlikely that they would have done a bad job at this. I guess my problem is that the creation/deletion of a component to prevent a process from accessing is nonsense nowadays, but if conditions A, B, C etc apply (optimised implementation, simple initialisation, cache limitations, etc), then it could have some foot to stand on. But if you don't include this context along with it, it's bad idea and bad advice I think.
14
Design / Re: OOP, ECS, Roguelike, and definitions
« on: February 15, 2016, 09:33:05 AM »
An example I read elsewhere that made sense, was consider a healthy mob. There's no reason for it to have a health component. It isn't wounded, so its automatically at full health. Since our natural healing process only runs on entities which have a health component, it'll automatically skip the ones at full health. It'd be pointless to process them anyhow, but without a health component, its an automatic de-selection.
What do you do when the mob gets wounded? Simply add a health component to the entity that represents the mob. You can apply the same general ideas to command flow, to effect calculation, and so on. It gives a nice, well defined, clear step by step route through your code. That is the Systems part of ECS.
That sounds like premature optimisation to me, and actually not well defined at all. Actually sounds like a terrible, terrible idea!
1) What if you need to check if an entity has health? Do you keep another variable for that? Otherwise, if a mob doesn't have a health component, it's either invulnerable, or at full health.
2) Do you think the cost of creating a component and defining its data is computationally more efficient than N Processes iterating over the component?
3) What do you do if a monster goes back to full health? delete the component? Again, you think that creating and deleting components would be cheaper than iterating and checking for a condition?
15
Development Process & non-technical / Re: a question regarding balance
« on: November 04, 2015, 08:17:53 AM »Even if they are turn-based, if actions cost *varying* amounts of action points/units (or whatever it's called), then it starts again making sense, no? My in-the-works game plans to use such a system, so I'd be interested to hear any strong (but reasonable) opinions against such a systemActually, it still does not. If I press the attack buttons very fast my rusty thoroughly corroded -5 tin opener will do more damage per second than your broadsword.
I think that's then what you have flat damage reduction for, as all your tin opener attacks will be absorbed. Also, being turn based and all, mashing won't help much besides wearing out your keyboard, I'm talking about damage-per-game-second...