A text based adventure engine? If such a thing even exists today? Or ever did? Its such an old game type and so simple to code there may be no "engines". Did you try google search on "text based adventure game engine" yet?
Anyone has other examples of simple feedbacks and what they're used for in (primarily 2D) games?
Almost any special effect is a form of feedback. If it told the player absolutely nothing you wouldn't bother coding it. And since you're talking about bling bling chrome as opposed to game mechanics that have some impact on gameplay (like knockback), there's no need to code it except as feedback for the benefit of the player. So it would seem that the answer is that any chrome that conveys info as opposed to mere immersion is a form of feedback.
I'm adding NPC initiated dialog interactions to the game. Similar to Skyrim when a courier comes up to you. The NPC will have about a dozen dialog options and may trigger any or all in a row (usually 50% chance of any given option), The player will have a menu of response options for each thing the NPC says to them. They are basically of the form of: "do you want to trade/chat/gamble/etc?" "yes/no/leave me alone!" Where "yes" does the action, "no" goes to the next NPC initiated dialog option (if any) and "leave me alone" ends all dialog with the NPC.
1. should NPC's insult the player - perhaps based on relations? Its a dialog option when a player speaks to a NPC - and turnabout is fair play.
2. what about use of famous quotes? (and humor in these cases)
for insult: "Your mother was a homster, and your father smelt of elter-burries! Now goo away - or I shall toont yoo a secon-da time-a!" - Monty Python, Holy Grail.
possible IP / copyright issues? What if its cited? Don't think I'd do that, but....
"turkey don't want no hep, turkey don't get no hep!" - from the movie Airplane was another one as a response to the player declining to have a healer NPC staunch their woulds when they were bleeding out to death.
possible player response to "heard any good jokes lately?":
"Ok, ok - so a caveman, a sabertooth, and a mammoth walk into a bar..." i know - not that funny! <g>. what can I say, i've been at it for at least 9 hours already today, trying to finish up NPC triggered dialogs. Need a Monster! (the energy drink)
4. I almost had an issue with dialog option order, and continuing after certain responses:
NPC healer walks up to player who is bleeding out: "Want me to staunch your wounds?"
player: "Yes! Please!"
NPC (after failing success check): "Sorry - I couldn't stop the bleeding!"
NPC continues to next dialog option...
NPC "So - want to hear the latest news?"
as the player bleeds to death...
Just so happens there's no "NPC staunch PC wounds" game mechanic in the game - so that particular case won't arise - Its not going to be a dialog option for NPCs. Sorry folks - you'll have to staunch you own wounds! NPCs won't do it for you. <g>. But in the future, how should I handle these things? I mean - "Sorry you're bleeding to death and I can't stop it... so - how about them Dodgers, eh?" <g>. seems a bit silly to me. Rather Monty Python-ish was the first thing that came to my mind.
Definitely sounds like you've strayed too far away from lockstep in your zeal to make inherently slow software seem less slow for the user. Strayed so far that things stop working. While an arcade game can play faster and looser with physics than a simulation can, there are still limits as to how much you can fake. You're going to have to tighten it up some. When you have to start faking stuff because of other stuff you've already faked, you're building a house of cards - on a foundation of ethereal "sort of lockstep" physics.
That still leaves me with the question of: how much realistically can a single artist do at once? I'm looking for the artist to learn along with me, so it's not the skills I need - but the knowledge of how many skills they can realistically learn.
They can do one model at a time - just like anyone else. <g>.
A good 3D modeler can do a fully rigged and animated skinned mesh from scratch with multiple matching outfits in a couple of weeks. Maybe one week if they're really good. That's totally from scratch. Usually you have some sort of skinned mesh to start with which can cut that time required down a lot. A bit of editing of the skinned mesh, then its on to rigging, animation, and outfits.
If they are learning, the first one may take a month or more if totally from scratch. Modeling bodies and modeling faces are almost skills unto themselves, as is non-IK animation.
As to how far they can go, it depends on the limits of their talents. If they have the eye of a michael angelo quality sculptor (for the art side), and the brains of a 3D programmer (for the technical side), they will go far. Lesser candidates will go less far.
The title is irrelevant, except perhaps when advertising looking for someone. what you need is known as an "art girl" or "art guy".
the skills / talents are basically 3:
1. hand drawn artwork.
2. 3d modeling.
3, the ability to use tools to create game assets.
your artist doesn't have to be able to draw unless you need hand drawn artwork for the game in question.
your artist doesn't have to be able to do 3D modeling unless you need 3D artwork for the game in question.
your artist will need to be able to use graphics tools to create game assets - for pretty much any type of game you make. Even if you buy all your art assets, they'll probably need some tweaking before they are game ready.
As mentioned above, isometric is a view ( a specific camera angle ). It can be used with 2D or 3D graphics.
Ideally, you art person will have all three skills: hand drawing, modeling, and tool skills.
But at any given time, you only need the skills called for by the current game project. So you need tool skills, and maybe hard drawn and / or 3D, depending on the game in question.
The coords for start and goal passed to run_astar are ok, Both are collision map coords in the range 0-299.
The F=109 was just the fixed point I was using. I switched it to floats with distances of 1.0f and 1.414f, with no difference in behavior.
But a message at the start of add_to_open indicated g was always 1.0f or 1.414f, instead of an increasing value. IE parent's G was always zero (because it was coming from the blank astar map!).
If you take a look at the code posted previously for expand_neighbors, you'll note that its passing the g value from the astar map, not the g value from the node, which just came off the open list and went onto the closed list.
As I mentioned, I started out with a 2d array implementation to track open closed, etc. Then I switched to a more traditional two list implementation. While the astar map still holds the parent info, the open and closed lists now hold the f and g info.
But as you can see, the code is still using the G value from the 2D array, not the open list. DUH!
Looks like I'll have save off the g value before adding the node to closed, then pass the g value into expand_neighbors.
Ok, let me go fix that....
Looks like it works now. In_closed_and_not_removed no longer tries to remove any nodes.
Thanks all again for the help. Hopefully this will do the trick.
I suppose now that I've found the problem, i should keep my heuristic admissible, and turn off in_closed_and_not_removed, right?
I added a message to add_to_open that displays: x,z f,g and px,pz (parent).
The test is the long term playtest game (going on 4 game years now!): Shana Queen of the Jungle being followed by her pet wild dog Wolfgang.
If Wolfgang is more than 10 feet from Shana, he tries to Astar to Shana. I have the game saved with them about nine feet apart, so all I have to do is back up a little bit and Astar triggers.
So I back up, and the message pops up when it adds the start node to the open list before beginning the astar loop. There's the x,z location. Looks good. G=0. that's correct, the distance from the start to the start is zero. but wait! F= 109? They're only 9-11 feet apart!
So it looks like its a matter of scale of the start vs goal coords being passed into run_astar in the first place. I added a message there, and its linking right now. Odds are the start x,z is in collision map coords (0-299), but the goal x,z is still in world coords, or something like that. In the game, location in a collision map x,z = world x,z % collision map size. Collision map number cx,cz = world x,z / collision map size.
Time to see what coords run_astar is being passed for goal.
If you strictly were designing a game that only you would be playing, how would that game be different vs. designing a game that was meant for the mass populace? Would it be different? What do you enjoy to an extent that others might not enjoy? Or something like that.
i wouldn't have to worry about the quality of the graphics, or lack of audio, stuff like that.
i primarily build what i want to play that's not out there at the moment. so in that sense i'd still be making the same kinds of games.
right now i'm working on a caveman sim, a starship sim, and an airship sim.
in the past i've done:
"flying saucer shooter" (aracde)
Mordorventure 1 (text based rpg)
Armies of Steel (wargame)
Combat Zone (arcade wargame)
Tank (arcade tank combat)
Global War (grand strategy)
Cybertank (gravtank sim)
Combat Racer (armored gravcar racing sim)
Dominoker (poker with dominos)
Gamma Wing (space fighter sim)
SIMTrek/SIMSpace (starship flight sim)
Mordorventure III (2d grpahics rpg)
Caveman (FPSRPG/person sim)
combat zone was an arcade version of armies of steel, basically just a way to get another game out of the code. armies of steel was the game i wanted to play - and built first.
combat racer was built using the cybertank code, but was a game i wanted to make, not "just another game i can churn out with this existing code base".
dominoker was made for a client. otherwise i would have probably never made that type of game.
so combat zone and dominoker are the only two i didn't build primarily for me to play.