Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Floirt]

Hehe, I just saw your game, Rhodan, and one thing crossed my mind:

So you're busy building your death star, and all is well, but there's still stuff to be done on one side, and then, unexpectdly, a fleet of fighters attack you, one lone fighter goes in a vent, and blows up your main reactor, causing the explosion of it all. Star Wars, anyone?   

[Rhodan]

I'm considering the following setup:
Each turret, shield, truster, cloaking device, whatever can be assigned to one or more keys.  They can also share keys.
This way you can set up your own controls and finetune which turrets you fire with when energy begins to run low and stuff like that.
Each object can also be set to 'automatic', so they are on all the time.  (Turrets only fire with enemies on-screen)
You can also define objects to turn off or on depending on energy levels.  This way you can automatically stop your automatic turrets when your shields are about to lose power, or only begin charging your giant "laser" when you have spare power.

A thruster probably gives enough power for itself and one laser, for smaller ships.  To boost the thruster you'd have to give up power to your laser for a bit.  Reactors are very expensive but required if you want shields or more firepower.

Shields are 'regenerating armour', while your hull just breaks and goes kaboom when hit too often.

A special element I really want are the '{}' curly braces.  They will form a "dock" on your ship, constructing new ships when they have power.  So having a {>O<} on your ship would constantly produce weak-shielded TIE-fighters.  You could have your own capital ship producing it's own fleet on the fly.

To make giant ships possible but stop being overpowered, I'm just gonna limit ship size/total energy for certain missions.  Your capital ship will be useful for travelling between missions or whatever I come up with.
Giant ships will also make great bosses.

Localized damage would be neat, but I'm not sure it'll be implemented.  It would limit ship design too much, I'd like people to go crazy building ships and showing them off.  I wonder if I should make them readable from a file, so people can share designs and add them as enemies.

[qwertyuiopas]

Would this work?
(Bonus for those who can recognise what it really is)

Code: [Select]

>+++++-
  +++++++-
   [-[->+<]+>][<-.]<-
  +++++++-
>+++++-


[deadlycairn]

Localised damage is really quite awesome as far as ships go, and I'm not sure how it limits the players. Just adds a whole new level of strategy.

Try Battleships Forever to see localised damage done right.

[Willfor]

Okay, question:

Applying math sort of breaks my brain, so for the purposes of answering this question, please assume my IQ is sub average. I need to wrap my head around building a line tracing algorithm where I give it the starting x and y (and z, but for the purposes of learning, I am not doing z yet), and the destination x and y, and it gives me a list of the tiles between the start xy, and the destination xy.

What I have: The ability to extract a tile from the map based on its x and y (and z), the ability to (once I have the list) immediately apply it to several applications within the code for great effect, and the ability to read this board.

What I don't have: The ability to understand what the hell this or this is saying. It's embarrassing, but I honestly can't read this, and have it actually sink into my head to the point where I can comprehend it.

That's pretty much the gist of what I need explained.

[magellan]

I've come to the conclusion that bresenham errors aren't necessary for RLs LOS. So what you do is this:

l=length using pythagoras sqr(dx^2+dy^2)
dx=end.x-start.x
dy=end.y-start.y

now you want the dx and dy for 1 unit of l, thats
dx=dx/l
dy=dy/l

Now you just add dx &dy to your starting coordinates with a for - next loop. some (not all) iterations of the loop will give you a new point in the line towards your target.

Bresenham does the same, it just makes sure that every iteration is a new point and makes it a bit more "straight" for lack of a better word.

Hope this helps willfor.

(of ocurse with a z it gets a tad trickier figuring out the l, but the rest is the same)

[Willfor]

Yes, I think I understand the formula now. At least to the point where I should be able to figure the rest out in implementation (Which is where I have learned a metric ton of other things)

Thank you!

[Rhodan]

Woo, more progress.  Moving entities are now properly polymorphed so now I can draw and update them in a single loop while still having lots of different classes.  Next up is collision detection and creating new entities dynamically, like weapon fire, enemies, asteroids and perhaps particle effects.

I still have to do stuff like the interface, proper menus, stage selection and win conditions.  But right now I'll be happy if I can just get an infinite shooting level going.
Getting there, slowly but surely.  I hope to have something playable soon.

[Willfor]

I sat down at lunch break (at work) today and wrote out the formula (on paper) since it wasn't working for me very well last night. After working through it with pen, paper, and a calculator for about 10 minutes I came to an understanding of what I was doing wrong. I also came to an understanding by making a visual representation for myself exactly how it was working. Now that I actually understand the process a lot better, it will really help me in future endeavors. Also, one of the cashiers is majoring in maths, and she helped me at least get a hint at how I can pull it off with a z axis, so I'll eventually get to that.

I got it working about 5 minutes after I got home from work, and besides a few bugs that are project specific, it works in good order. When I start programming again tomorrow I am either going to work on applying this new method to pathing for a ranged weapon, or the basics of an AI protocol. I won't know until I sit down and look at what I want in the game more next.

[Singularity]

Hmm... I haven't actually started working on a roguelike just yet, and I'm not sure if this thread is the right place to write up concepts and design.  But I'll plow ahead anyway. I'm not all that great at coming up with original ideas, to be honest - I'm far better at stealing looking at other's ideas and taking them a step further.  But anyway, here goes:

One thing I've been mulling over is the sort of skill system I'd like to use.  I'm pretty fond of the Elder Scrolls style of having skills improve through use.  However I never liked the concept of alloting attribute "picks" when you leveled.  Instead I would rather have attributes increase as their associated skills increase.  A rather subtle difference from the way Morrowind and Oblivion work, yes.  But it eliminates the min/maxing of grinding misc. skills just to get a 5x bonus to a stat.  In fact, with my system I could probably eliminate the traditional XP-based level entirely.  I could simply average the player's (and enemies) combat-related skills to give a rough measure of their "danger level".  Vitals like HP could be based on stats, such as Endurance, rather than on character level.

In addition, what I'd like to do is avoid restricting people's play style as much as possible.  That is, there would be no hard and fast restrictions based on character class.  It would be a lot harder for a barbarian to cast spells, but it shouldn't be outright impossible.  The only penalty would be the lower starting skills.  Of course, to avoid the oblivion syndrome of 100's across the board, I would also like to have skills and stats decrease if they aren't being used often enough.  Basically, you should be able to master anything -- but not EVERYTHING.

Finally, although it's probably a pain to code, I'd prefer not to have hard caps on anything if possible.  So no skills magically maxing out at 100, though it would be exponentially harder to increase after a point.  The idea of soft caps always appealed to me more, for some reason.

Well, I have several more ideas I'd like to throw out for discussion, like a refined reputation system... but this post is long enough already, and I'm sure I've bored you by now.

[Zironic]

Wouldn't the problem with extremely large ships involve gravity, space matter (asteriods, rocks, gasses etc) and most importantly inertia? It'd take so much more time for a huge ship to change directions versus a small ship. If I had 400 small swarming ships and 1 large ship 400 times the size, I could simply out gun and out run the larger ship. Unless it has 400 super accurate lasers, rockets, and rail guns.

[Virex]

Hmm... I haven't actually started working on a roguelike just yet, and I'm not sure if this thread is the right place to write up concepts and design.  But I'll plow ahead anyway. I'm not all that great at coming up with original ideas, to be honest - I'm far better at stealing looking at other's ideas and taking them a step further.  But anyway, here goes:

One thing I've been mulling over is the sort of skill system I'd like to use.  I'm pretty fond of the Elder Scrolls style of having skills improve through use.  However I never liked the concept of alloting attribute "picks" when you leveled.  Instead I would rather have attributes increase as their associated skills increase.  A rather subtle difference from the way Morrowind and Oblivion work, yes.  But it eliminates the min/maxing of grinding misc. skills just to get a 5x bonus to a stat.  In fact, with my system I could probably eliminate the traditional XP-based level entirely.  I could simply average the player's (and enemies) combat-related skills to give a rough measure of their "danger level".  Vitals like HP could be based on stats, such as Endurance, rather than on character level.

In addition, what I'd like to do is avoid restricting people's play style as much as possible.  That is, there would be no hard and fast restrictions based on character class.  It would be a lot harder for a barbarian to cast spells, but it shouldn't be outright impossible.  The only penalty would be the lower starting skills.  Of course, to avoid the oblivion syndrome of 100's across the board, I would also like to have skills and stats decrease if they aren't being used often enough.  Basically, you should be able to master anything -- but not EVERYTHING.

Finally, although it's probably a pain to code, I'd prefer not to have hard caps on anything if possible.  So no skills magically maxing out at 100, though it would be exponentially harder to increase after a point.  The idea of soft caps always appealed to me more, for some reason.

Well, I have several more ideas I'd like to throw out for discussion, like a refined reputation system... but this post is long enough already, and I'm sure I've bored you by now.

The danger with sucha  system is that ypu're taking out the risk/reward aspect of leveling up, or at least greatly dfiminishing it. That means that there's less reward for doing troublesome tasks, because you don't get the "YES! Level up!" feeling. This means you've got to build in another kind of reward strategy to keep people hooked.

[Zironic]

Hmmm, I just did one of the tutorials for making a rogue, it was a shame that it ended early, because the man behind it was a powerful teacher.

[Singularity]

The danger with sucha  system is that ypu're taking out the risk/reward aspect of leveling up, or at least greatly dfiminishing it. That means that there's less reward for doing troublesome tasks, because you don't get the "YES! Level up!" feeling. This means you've got to build in another kind of reward strategy to keep people hooked.

Well, I imagined it being a quest-heavy roguelike, so the rewards would come more from the townspeople than from grinding.  Still, I could make it so that difficult tasks increase your skills far more quickly than easy ones.  And perhaps after a certain point, the menial tasks stop increasing your skills entirely.  That would encourage deeper diving and eliminate grinding skills off of rats.  Obviously, I'd be playing with the system as I went along, and once I actually have something I'll gather user input on it. 

Now, a couple words on the previously mentioned faction system:  Most rpgs, when it comes to reputation / alignment, are 1 or even 0-dimensional.  Often you're a Good Guy (tm), end of story.  Oblivion has a limited 1D system, with Fame and Infamy.  Neverwinter nights has a basic 2D axis, with "Lawful - Chaotic" and Good - Evil" as axes.  Daggerfall came closest to what I really want, which is individualised opinions of your character.  In my mind, not all "good guys" are liked by everyone, and not all bad guys are hated by everyone.  If you're helping the common people out, the criminals are probably not too happy with you.  On the other hand, you shouldn't be alienated if you're doing evil deeds... The criminals may well take you in, and you should certainly should be able to be a Robin Hood type of character, where the guards hate you but the general public looks up to you.

I suppose it's becoming increasingly clear that my ideas are not only over-ambitious, but not much roguelike material. I guess my game would have far more RPG elements than the standard dungeon crawl.  Not that there's anything wrong with dungeon crawls.  I just want something akin to DF's (future plans for) adventure mode, where your actions could have lasting impact on the world around you.

[qwertyuiopas]

Morrowind and probably oblivion(non caps, as I feel it is a vastly inferior game, especially as it has an invisible world edge wall of doom) have a faction reputation system where NPCs like/dislike certain factions, as well as each faction, so you get a slight semi-dynamic system, amplified with the variance of factions in Morrowind.