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.


Messages - requerent

Pages: 1 ... 18 19 [20] 21 22 ... 24
286
Programming / Re: Cars in a roguelike
« on: May 02, 2012, 10:08:18 PM »
A car should have to be driven with respect to its rate of movement. If a car is moving faster, then it should do so without the player being able to control every discrete step. If you turn while going too fast you'll enter a drift-- you can intentionally turn too early to drift into the turn, but you do so at a loss of exit speed.

With these qualities of driving in consideration, it may be better to have cars 'jump' to a target tile based upon their speed rating-- you can then interpolate to the target tile and see if any collisions occur. I ask about the rendering engine because you can render the full 10 tiles worth of movement while only passing 1 turn worth of gameplay.

Based upon these things, you can have the player 'plot' their movement based upon the constraints of their velocity. IE- car is facing west moving at 5 tiles per turn. The car has a breaking speed of 3 tiles per turn and can accelerate 2 tiles per turn. That means that the player can move the car west a number of tiles within the range of 2-7.
That's about as much as I'm "with you" regarding the mechanics for using the car. While it would be totally awesome to work in pseudo-physics handling and rendering the car at an arbitrary rotation, I don't think it works given the level of discreteness going on. Based on what I can see in the images provided, the car is two units big, and BrightBit doesn't seem to be doing a whole lot with regards to interpixel collisions: include the factor that the aesthetic is going more for simplicity (sacrificing, if you want to call it that, the mechanics by doing so) and the complexity you were describing doesn't really fit all that much into what's going on.

Basically, what I'd do with car movement is allow the player to increase or decrease the speed (maximum and increment dependant on the car), which determines how many units it crosses in a single turn. (The input for this should be independent of movement, as it will predetermine the distance traveled.) Naturally if there are obscales between the two points, the car will crash, with the damage dependant on speed. The idea will be that the player will have to decrease speed accordingly in order to make sharp turns. For example, this is what I'd expect for a car turning at 1 speed and 2 speed, respectively, given the current model:

...     ...
.X. --> .XX
.X.     ...

...     .XX
.X. --> ...
.X.     ...

Turning at faster speeds could also take longer, if only because there are some obvious braking requirements. Alternatively, you could force extra horizontal movement, changing the obstacle tiles. Here's an example for a 3 speed car, where the asterisks indicate collision checks:

.....     ..*XX    ..*XX
.....     .**..    .***.
..... --> **... OR ***..
X....     .....    .*...
X....     .....    .....

The collision indicators could easily be shown during the confirmation. (A lot of this is repeat of requerent, but I figure that pictures help.)

You may also want to take into account "stafing": that is, moving to the left or right without actually turning the car. This can probably be accomplished with the use of diagonal keys, which would otherwise have limited use in the car.

I essentially agree with the interpolated collisions for moving objects. You don't need to do into TOO much detail, I guess, but there should be a difference between high-speed and low-speed collision damage.

I was actually thinking more along those lines-- but it really just depends on what role driving a car has in the game and how punishing the mechanics are to the player. If we consider the ruleset, a player skilled in knowing how the car moves will essentially have a range of end-states/positions available on each turn. If the game is more tactic or strategy oriented, I think it's prudent to give all available states each time the player makes a decision (and then they just click on the one they want).

Is the player the driver or is the player tactically commanding the driver? We often say that 'the player is the character' in roguelikes, but in most cases we're really just making tactical commands to increase survival. We're never concerned with the mechanics of combat (parry/riposte/lunge/block etc), we just sort of have faith that our 'warrior' knows how to be a 'warrior.' So... does the driver know how to drive or are we the driver?

I think the novelty of being the driver would be a lot of fun, but the punishment for anything short of perfect driving might wear on even a very good player (because 'skill' here is NOT reflexive), especially if cars have different properties. However, it'd only be interesting to provide a set of possible outcomes for the player to choose from if the game itself was tactically intuitive.

In the end I think your method is best-- driving is a fun gameplay mechanism in and of itself.

287
Programming / Re: Cars in a roguelike
« on: May 02, 2012, 01:23:26 PM »
What rendering engine are you using?



A car should have to be driven with respect to its rate of movement. If a car is moving faster, then it should do so without the player being able to control every discrete step. If you turn while going too fast you'll enter a drift-- you can intentionally turn too early to drift into the turn, but you do so at a loss of exit speed.

With these qualities of driving in consideration, it may be better to have cars 'jump' to a target tile based upon their speed rating-- you can then interpolate to the target tile and see if any collisions occur. I ask about the rendering engine because you can render the full 10 tiles worth of movement while only passing 1 turn worth of gameplay.

So a car has a few features to consider- rate of acceleration, turning speed, and breaking speed (you can base all of these values on the actual physics- but imo that's pointless)- don't forget current velocity.

Based upon these things, you can have the player 'plot' their movement based upon the constraints of their velocity. IE- car is facing west moving at 5 tiles per turn. The car has a breaking speed of 3 tiles per turn and can accelerate 2 tiles per turn. That means that the player can move the car west a number of tiles within the range of 2-7.

Now- suppose we want to initiate a turn while we're moving forward. Graphically, it would be useful to have a 30 and 60 degree tile for the car, so that the renderer can communicate the progress of the turn. Otherwise-- A player has the option to initiate a number of turns based upon their turning speed. IE- suppose turning speed represents the number of 90-degree rotations possible in a single turn of play. You don't even need to make the player do anything complicated, you just widen the range of possible moves (inclusive of facings) available for the player to choose from. The player just chooses a target tile and whatever facings are available for that given tile. The current speed is then adjusted based upon whatever speed was necessary to reach that particular tile at that particular facing.

This gives you a lot of flexibility-- a player could make a 180 degree turn or do other fancy maneuvers. If you wanted a less forgiving system, you'd want to force the player to consciously choose how much they're braking- this would put the player into positions where they might spin-out, over-turn, or drift off of the road.


Now- the last thing to consider is interpolation and collisions. Two cars, one heading north and one heading west, both approaching an intersection-- one is moving 9 tiles per turn and the other is moving 5 tiles per turn-- You can either logically subdivide the game-loop so that we evaluate logic at a discrete step equivalent to 1/45th of a tile (this would not effect rendering)- that way we can deterministically see if the objects collide, or you can evaluate the paths of all objects within their respective bounds to see if their movement paths cross, and then test reasonably possible collisions. Honestly, you won't do much harm to your simulation if you run a logic-loop to step the game forward. It's technically more expensive, but with a turn-based game it's no biggee. If your game engine allows it and you're interpolating the graphics between tiles, you can just use the built-in collision detection provided by the engine.

Nice pics!

288
Programming / Re: Ease of Implimentation...Major Consideration?
« on: April 27, 2012, 12:43:11 AM »
I've just resigned myself to the notion that RPGs take a lot of time to make.

Seven days?

289
Off-topic (Locked) / Re: Foreigners
« on: April 25, 2012, 12:52:18 PM »


Sometimes there is no difference between natives and foreigners, if both of them are creeps.

Oh fuck! Zing!

@Req - Normalize the numbers however you want, the effect is still racism. The stats take into account criminal history. The intent of the system is not racist, the racism comes from the human factor. A manifestation of the human fear of 'the other'. Note that criminal history is the only thing properly taken into account in sentencing out of the things you listed. The others are likely considered at a more subconscious level, but amount to no more than racism by proxy. Or more accurately, classism.

Well- I wouldn't say at a subconscious level, but rather at a functional or pragmatic one. I think the reason why it isn't racism is because the system is not targeting members of that race. They just happen to be in the statistical majority of crimes committed warranting more severe punishment. The statistics will make it look like racism no matter how you wind it. Judges most definitely take into account your station in life-- if you get caught for possession as a student in a 4-year university, you're less likely to see significant punishment as you would from, say, an unemployed 40-year old single man living in section-8 -- even if in both cases there were no criminal records.

I may be completely off-basis, but my experience with judges suggests that they take personal character, location, and position in life into account when sentencing people. This is most definitely classist, but if we look at the stats irrespective of race and focus solely on class, then the trends show that poor folk commit crimes more often. Even if that bias isn't held against someone in court, the fact that they live in an area where there is a zero-tolerance policy toward crime will bone them.

I will certainly concede that blatant racism exists in a number of places in this country- but I don't think that the statistical racism that your talking about is as substantial as the statistics may imply.

290
Programming / Re: Ease of Implimentation...Major Consideration?
« on: April 25, 2012, 03:38:10 AM »
 Let's assume, for just an instant, that we are on a forum full of people that develop games as a hobby. How often do you cut out fun stuff, or discard ideas, because it would be hard to implement? I tend to discard a ton of stuff because I lack the programming skill or the years of time it would take to implement it. That's part of why I went back to making card games for awhile.

  I wish I lived in the fantasy world where design was harder than implementation.

  Here's a design. Modern Warfare 3, the Roguelike. It'll be epic! A tried and true design. So Req', now that all the hard work is done when can I expect the game? Feel free to illustrate my point, and my question, by actually trying to answer that silly question.

Lol, okay- sure.

Modern Warfare 3, the Roguelike-- just aesthetically mod DoomRL. Done!

Let me ask you-- How many of your ideas do you actually develop to the point at which they're ready to implement? What I'm getting at here is that the discouragement in designing something tends to not involve implementation, but fleshing out a truly complete concept.

If you have a complete design for a game, I would be happy to try and implement it... y'know, if I found it inspiring and all.

291
Programming / Re: Ease of Implimentation...Major Consideration?
« on: April 25, 2012, 03:37:07 AM »
Yea, that was a stupid thing to say.

I definitely misused the word 'problem.' The most important quality of a programmer is stubbornness- The assumption that with continued effort any problem can be solved. The persistent belief that one is always good enough to solve any given problem will inevitably result in a solution for the problem being found (unless the sun burns out first).

In this vein- most of the 3d problems have been solved and packaged into libraries that are easy to use. The developer just needs to brush up on the literature and pick tools appropriate for the job.

Even if you're going to program a 3d engine from scratch-- mesh loader, input handler, frustrum culling and a scenegraph aren't particularly difficult problems. Ignorant of 3d concepts, I don't think an experienced programmer would have trouble figuring the basics out. Tutorials and literature is plentiful... or you can just use unity, ogre or flash3d.



That said- A designer should not concede design for programming difficulty- ever. It's the programmer's responsibility to interpret the design and implement it in a progressively functional manner.

If the design objectives revolve more around the effect of gameplay on the player instead of gameplay being a particular way, the rules tend to be more easily reduced in a way that doesn't cause problems for the programmer. If a designer says, "I want to make the next mmocrpgfps of awesomeness" and works toward that specific goal, it's going to suck for a programmer. Any story could be told in a number of ways, picking the most appropriate, concise, and interesting ruleset makes for easy programming.

292
Off-topic (Locked) / Re: Foreigners
« on: April 24, 2012, 08:47:47 AM »
 Racism is a major problem in the US and has been for a long time. It's become tied with immigration in the last couple decades. If you are black in the US you are many times more likely to go to prison for the same crimes as a white person.

You make note ONLY of the binary relationship between going to prison or not. This implies rate of conviction, not sentence severity.


Conviction and sentencing depends on a number of factors including current wealth, criminal history, education, and crime rate in current residence. If a white person commits a crime in an area with a low crime rate, the DA probably isn't trying to make a point of 'cleaning up the streets.' If a person commits a crime in a high-crime area, the need to inflict harsher sentences is important to a number of parties- The local political platforms probably focus more heavily on creating a safer environment. In this way, there are a number of other factors that are important explicit and implicit confounders to your claim.

Statistically, black people are more boned in these regards- but these aren't racial factors. It's just coincidence that they are black. I'm willing to bet that if we look at data socioeconomically or as a proportion to local crime rates or through other more significant perspectives, we'll find that racism isn't nearly as pronounced as you may think.

293
Programming / Re: RogueArena - Looking for Feedback
« on: April 24, 2012, 07:09:58 AM »
One thing that may be interesting is if characters are persistent. A player who wins an arena now has absorbed all these abilities-- What if that character could be used in a subsequent arena against people of equivalent power levels?

Could become interesting to see how powerful a single player is able to become without dying.

294
Programming / Re: Ease of Implimentation...Major Consideration?
« on: April 24, 2012, 07:07:24 AM »
Wait- what's your problem?

Are you having trouble designing the rules of your game, or programming it?
  There is no problem. It was a question. Asking how often people go for ease of implementation over fun factor.

I don't see how the two are mutually exclusive. 3D and ports to x-box, for example, are now one-man jobs.

You described HeroRL being complex and hard-- Is it complex because your rules are difficult to implement or because you haven't decided on how the rules fairly and appropriately represent your idea/objectives?

Basically- I'm asking what your question is asking-- is it asking it from the point of view of a game designer or from a game programmer?

There are 4 branches of game development--
Production/Game Design (rules, story, gameplay)
Software Development (tools, shaders, mechanics, physics, engine)
Asset Development (art, music, models)
Level Design (scripted events, areas, gameplay implementation)

Procedural generation lets us cut out or greatly reduce our need for Assets and Levels. The only two things a roguelike developer needs to think about are design and programming (including the emulation of level design and, if necessary, assets).

Is your question one of design, or one of programming?



Typically- a designer has a certain set of objectives they wish to accomplish in regards to how they effect the player. The programmer develops a paradigm, or set of features, necessary to accomplish these tasks as simply as possible. It is the designer's job to determine what the mechanics are- what stats each creature has, how combat is handled, and everything else that matters. The programmer just finds a way to implement it.

Complexity exists relative to one's perspective of a problem- Is an idea too complex to describe the rules or are the rules too complex to program?

In my personal opinion, if the rules are well-defined then there isn't really any problems when it comes to implementation.

295
Off-topic (Locked) / Re: Foreigners
« on: April 24, 2012, 06:40:57 AM »
  Troll and Req you were way off. I was saying the US has an issue with racism and it can be shown statistically. Blacks commit more crimes statistically, so what? That's not racist. The systematic racism comes when blacks get put in prison at a higher rate for the same exact crime.

  No need to call names and freak out.

I was being sarcastic- but then ended up taking the post in a non-humorous direction. Didn't mean to offend-

My point of contention implicitly dpends upon the fact that people have to be convicted to go to prison. If black people do in fact commit more crimes, then it is logical for the rate of convictions to be higher. It might also be possible that convictions against white people tend to fail because they are in fact innocent.

296
Programming / Re: RogueArena - Looking for Feedback
« on: April 23, 2012, 10:29:29 AM »
Is the game multi-player and turnbased? Is it primarily PvP or is it PvE or a mix?

I like the premise of gaining powers, especially if there is no conventional leveling. Creates incentive to battle early and often at the risk of over-extension. It all depends on implementation though.


Doesn't look that interesting. Also I think using 3D graphics for 2D map isn't worth the trouble. Actual 3D map would be something.

Pfft- those graphics are cute.

297
I willingly sacrifice control for productivity-- I don't really want to deal with pointers or memory management. I like code-completion and every form of spoiling that Java developers are used to.

Some time ago i really liked messing around with lots of languages like Vala, D, OCaml and so on. But now i'm feeling really tired und lazy, so i keep working with java. Every now and then i'm thinking about using c++ again, but i don't want to work with header files and pimpl-idioms... don't want to talk about compile times in c# / c++ / c ... background compilation ftw. I wanted to try haxe - but where are my refactorings?

Maybe you should just stick with java as i do if you're as lazy as me :-)

Edit:
Since you want to try haxe maybe you can tell me if the tool/ide support is getting better.

I've been having some trouble building the NekoVM (which is used to compile HaXe) on my all-from-source linux boot. FlashDevelop, however, has a plugin that enables refactoring. The newest version comes preloaded with HaXe, but for a number of reasons you should point it to your own installation. NME is one of the project types- it's a set of libraries designed to abstract the functionality of Flash to other targets- allowing you to compile to JS, SWF, or a native binary (not a crappy wrapped SWF). I have fooled around with it in FlashDevelop, but I really want to set up my development environment in a new linux boot. There is also an Eclipse plugin for HaXe, but I haven't tried it yet.

HaXe is very mature and feature-complete for the existing targets (a java bytecode target is on their development stack), but there isn't a HaXe-oriented IDE that gives you happiness out of a box yet. I would highly recommend checking out http://www.haxenme.org/ and http://haxe.org/. It seems too good to be true! There's also a list of ides on their sites that outline exactly how much support there is for each one.

298
Off-topic (Locked) / Re: Foreigners
« on: April 23, 2012, 09:42:39 AM »
 Racism is a major problem in the US and has been for a long time. It's become tied with immigration in the last couple decades. If you are black in the US you are many times more likely to go to prison for the same crimes as a white person. The same is true for other races of Americans but not as bad as for blacks. Something like 1/3 black men will be in prison in their lives. We currently have 1/100 men in prison in the US. 3% of the total population is incarcerated or on restriction (probation/parole). It's just crazy.

Jo is a racist- Categorizing actions taken against individuals BASED UPON RACE is without respect to each individual case in which crimes are committed and sentences made. If it turns out that black people just happen to commit more crimes, THEN IT'S OKAY. THE SYSTEM IS FINE. It may also be that white people just happen to  be innocent more often than blacks.

The hilarious thing is that MOST of the crimes black people commit are against OTHER BLACK people. The FBI publishes (on their website) yearly statistics of crimes that result in murders- the last time I was doing research on it (2003), 80% of ALL crimes involving murder (since the 70's) were black people killing black people (in most cases involving theft of some kind). The statistics DO NOT FAVOR black people!

That said- If you submit two job applications where the only thing different is the name and one person is named "James" and the other is named "Shiquandaniqua," it's shamefully racist who is going to get the job. Statistics show that "James" will find a job significantly faster- unless the hiring agency needs to satisfy race/gender hiring requirements for tax breaks.

Companies look at statistics and see that black people, historically, commit more crimes. The fact that the former is true results in the latter. I was working in retail on Manhattan right in Union Square. Our store raked in 100k of sales each Saturday. Probably 80% of the shoplifting that took place- split evenly between Blacks and Latinos. We can call this racism, but the reality of it is that these conceptions developed organically.

The days of senseless lynching racism has been over (at least in places where it matters) for a long time. Now it seems to be predicated on the body of behavior that they have provided.

299
Programming / Re: Ease of Implimentation...Major Consideration?
« on: April 23, 2012, 09:19:15 AM »
Wait- what's your problem?

Are you having trouble designing the rules of your game, or programming it?

300
HaXe has completely won me over. It can target HTML5/JS, Flash, and Native without any changes to code (using the NME library). The language/syntax is very Flash-like, but the actual HaXe language features are superb for my needs/paradigm.

@aave,
I'll just DIE without pixel shaders! I'm not opposed to WebGL or OpenGL, but I'd rather not use up development time on non-gameplay oriented components.

Pages: 1 ... 18 19 [20] 21 22 ... 24