Messages

16

Feature requests / Flood fill

« on: August 23, 2010, 02:15:40 am »

Topic:

http://www.sfml-dev.org/forum/viewtopic.php?t=3037

Is support for this planned for SFML 2?

17

Window / mouse input not always registering

« on: August 23, 2010, 02:06:57 am »

It depends on where you're calling it. If it's not in the event handler code, then it could miss it.

18

SFML wiki / /!\ List of GUI based on SFML /!\

« on: August 23, 2010, 01:59:28 am »

BTW, cpGUI isn't inactive. I know this because I'm working on it (check the forum for more info). And it works on SFML 1.6 (stable). We'll port to SFML 2 after SFML 2 is released.

19

General discussions / Blocking

« on: August 23, 2010, 01:52:56 am »

Do we have the ability to put our program into the blocked state? This would be useful for non-game applications (so they don't suck up CPU).

IIRC we can call sleep( time ) but that's not really how it's supposed to work. It's not *really* getting blocked, it's just activating a timer to sleep every so many seconds (it's only partially blocked). It should stay in the blocked state until it has an event to handle.

If this isn't available in SFML stable then can it be in the next release?

20

SFML projects / Ultimate Zombie Fighters

« on: August 23, 2010, 01:43:01 am »

I'm not sure what you mean...

Sorry that was stupid on my part. That's what I meant (i.e. I wasn't paying attention and the game already does it).

But what benefit will standing, proning or kneeling have in a top down game where the enemies can only melee?

Each position will allow you different levels of accuracy (trades mobility for accuracy). It can also be used to hide better against zombies (man standing up in the open is easier to see than man crouched behind an obstacle sniping). Which ties into another thing:

Zombies shouldn't just automatically go towards where the player is even though they can't see them. They shouldn't be this "smart". They should only chase after the player when they can either see/hear them (or other zombies are chasing them). This will require they have weak AI.

I'll continue writing more ideas into the wiki but I need to focus on cpGUI (in order to release it by the end of the month).

21

Feature requests / Can SFML be used in java?

« on: August 23, 2010, 01:28:11 am »

Also, you'd have to consider that mobile devices probably won't run the full JRE, but only run the mobile runtime environment (certain things may be stripped out of the java package on cell phones).

If I had an Android I might be interested, but I have an S60 device

22

SFML projects / Ultimate Zombie Fighters

« on: August 22, 2010, 04:53:54 am »

So getting a direction for the hit might not be as useful.

I didn't mean red flash in direction of attack, I meant the screen flashing red. The point of this is so that when a player is in Scope Mode (i.e. when they can't see their character) they can tell if they're being attacked.

What I meant is that when single wielding, right click will be used for aiming...

What about just let players use different positions (Standing, Prone and Kneeling)? Holding a button down to aim doesn't really make sense. There are parts of the CoD series and other FPS games I don't agree with, and this is one of them. Example: In sniper mode you have to hold down a button to "steady" your aim. This is more of an obstacle rather than a feature (it's like a handy cap actually, i.e. you can't aim properly unless you hold down this button).

23

SFML projects / Ultimate Zombie Fighters

« on: August 20, 2010, 08:23:12 pm »

Also say you're sniping, you won't be able to see yourself if you zoom faraway and so you can't see your ammo.

I see. Then have the ammo donut (that sounds funny for some reason) around the mouse cursor. Then the reload and ammo donut will be right there (where you're aiming at).

Also make the screen flash red around the corners (like in those other shooter games) so that the player knows they're being attacked even if they're sniping.

(should I use a sub machine gun with faster fire rate or more accuracy?)

This doesn't provide enough of a difference to really matter. Having multiple weapons with the same main attribute (e.g. faster firing rate or accuracy) won't give players much options. As in, it won't *really* matter what they choose, since every weapon will be just variations of damage/sec, AOE, range, ROF, etc. There needs to be more attributes (e.g. pushing target back, piercing multiple targets, etc) to distinguish each weapon (option) from each other.

Also realistic weapons are harder to balance because they are (evidently) not balanced (e.g. a sniper rifle is more dangerous than a bow and arrow, this cannot be balanced, unless one just blatantly ignores the facts).

When duel wielding, left mouse button should shoot weapon one, right mouse button should be weapon 2. That way you can't zoom when duel wielding.

You can't dual wield sniper rifles anyway ( that's just silly ). But left/right for dual wield firing makes sense so that player can either shoot one at time (while other gun reloads) for constant ROF or shoot simultaneously (maximum damage).

And when zombie kills a team mate, they turn into zombie.
Maybe a game mode?

I was thinking to make it make sense (when zombies kill people, they usually turn into zombies).

OR: Instead of Mercenary Mode, call it Ultimate Mode. Also add when player is attacked by a dark green zombie, they'll turn into zombie after so many minutes ( 30 ? ) unless they get a serum/cure (only the dark green zombies can turn players so they gotta pay extra attention to them, cuz cures are rare).

Yeah. Also it's useful for confirming high-scores.

Replays can be faked though... We'd have to use public key encryption (digital signature) to prevent "counterfeit" scores (may be implemented much later when it really matters).

Wow thats a lot of ideas. It'll definately be hard to implement all of those.

Actually, I imagine it won't be that difficult. It'll mostly be time consuming (i.e. require lots of thought on designing the code).

Speaking of campaign, there should be civilians that you have to protect (if they die, they turn into zombies) If all civilians die, game over.

To better support extremely large maps, the sprites may need to be smaller (max 50%, probably shrink to at least 75% original size) to fit more details on the screen (this is 2D, we can squeeze *a lot* more stuff than 3D gfx) and make the screen size bigger.

24

SFML projects / Ultimate Zombie Fighters

« on: August 19, 2010, 10:30:14 pm »

Sure. We'd love to hear your ideas. You are welcome to use the project wiki if you wish.

I don't have permission to edit any of the pages.

25

SFML projects / Ultimate Zombie Fighters

« on: August 17, 2010, 07:31:58 pm »

I didn't think about having large number of zombies before... However there may be issues with CPU usage (due to pathfinding) and network bandwith.

200 units on the map shouldn't cause problems for now. Later when we try to support 1000s it'll be a problem.

My idea was that if the player goes too far out then he starts becoming affected by radiation and starts slowing down...

Better yet, have a radiation cloud surrounding the outskirts of the map (graphics). If the player walks off the map, they die (or perhaps get radiation poisoning, but make the damage high enough that the player won't walk off the map). This could also be used in other areas of the map so the player has to avoid them, and could be used to trick zombies into walking into them and taking damage.

I have a few thoughts about the HUD. The goal of these changes is to center vital information near the player's character:

• Instead of a health bar, show a health donut (or circle) under the player's character.
• Same with ammo bar (draw gray donut around the green health donut/circle) Then show pictures of clips rather rather than listing how much ammo they have.
• Move the reload bar near the mouse cursor. Perhaps change it also to a donut/circle.
• Only the level number and number of points is left. Move these to the top center of the screen.

Also I saw on the wiki a list of redundant weapons. Each weapon should be as unique as possible, so that the player has more of a choice (rather than it not mattering, i.e. each weapon actually has a purpose). Basically, multiple shotgun/machineguns should mean that they do different things. e.g.:

• Have a machine gun with a huge clip (shoots longer, already in the game tho) and another that pushes back the target.
• Sniper rifle that pierces through everything (including walls and windows) and another where if it hits the target in the head (passes near the middle of it) then it instantly kills. Sniper rifles have Scope Mode in which you can view any area by scrolling with mouse (camera lock turns off).
• Using real gun models (e.g. AK47, M4, etc.) may not be practical.
• Shotgun allows you to hit multiple targets in front of you.
• Sticky grenade, ice grenade, regular grenade. Targets that were hit by an incendiary grenade will light other nearby targets (only the original target hit by the grenade can spread fire, other targets that caught on fire don't).
• Bear traps. Land mine that instantly kills target and another that damages group of targets. Ice land mine. Barrels of oil to light areas on fire.
• Pistol and SMG can be dual-wielded (but slows down reload time).
• Player should be able to hold up to 2 weapons at the same time ( choose wisely )

Another interesting thing would be to have guns and supplies air dropped onto the map. Could be drawn with a circle that moves around until the box lands (with 4 lines connecting circle and box, i.e. you can see the box under the circle/parachute while it's swaying around until it drops). Once the box lands, the parachute automatically (magically) disappears.

Buildings should be used as choke points (easier to defend).

Zombie dogs slow you down when they attack you (25%). Would be fun to have level 10 or something where there's a lot of dogs, in which case it'd be best to setup traps (surrounded by dogs = can't move = dead).

Arcade Mode: You don't set off your own traps (if you step on a land mine, it doesn't blow up). No friendly-fire (can't hurt team mates). Among other things which make the game easier (more fun for casual gamers).

Mercenary Mode: Rules are more realistic (step on a land mine, you detonate it). Friendly-fire (watch your aim now). Makes game harder (more fun for hard-core gamers).

Also would be good if the player could sprint too.

And when zombie kills a team mate, they turn into zombie.

Also need a replay system so people can show off their kills

26

SFML projects / Ultimate Zombie Fighters

« on: August 16, 2010, 01:51:30 am »

That doesn't sound like what I'm talking about. It doesn't solve how to fit a thousand units on the map when you only have room for 100. The purpose of a leaking spawn system is to flood the map with units (of which 50 is way too low to do that, if the map is "clogged" with 50 units then it's either way too small or the units are way too big).

What I'm talking about is simulating the map as if there were a thousand units that were spawned instead of 100. The other 900 units can't fit on the map so make it look as if they were spawned outside the map. It's impractical to do it literally (try spawning a million units... yes, we mine as well crash the game as it's unplayable at this point).

Whenever a unit is killed, spawn another one. This way the map is always full until the player(s) kill however many units were supposed to be spawned. Better yet, rather than spawning another one, just recycle them (optimization). Whenever a unit is killed, move it to a spawning point and bring it back to life.

This way, it'll look like hundreds or thousands of units are coming at you because the map becomes a "view" (maximum viewing field). The max unit count should be a thousand, but to start with at least 200 (a thousand units may take more optimization tricks than recycling). It could also be dependent on a map, with larger maps (supporting thousands of units) for people with high-end hardware and smaller maps for low-end.

Also with larger maps you can have multiple buildings. So, the player will have an incentive to move around more (besides avoiding zombies).

Another interesting mechanic would be if more zombies were spawned near a player that is near the edge of the map. Perhaps it could be used somehow to prevent players from getting to the edge of the map (so you can't walk off the map, or you have to use an "invisible wall", zombies preventing you from walking off the map is better IMO).

I don't think zombies should upgrade with each level, but if they do then the player needs to be able to upgrade as well. This will make balancing the game harder (but it might make it more fun). I think upgrades should be left out at least until the game is more complete.

EDIT: Also, rather than having spawning points, zombies should be spawned at the edge of maps as if they were walking in from a random direction. This way when it becomes multiplayer, players can't farm spots and everyone will have a chance... I should probably write up a document or something because there are a lot more details that I could go into besides the above.

27

SFML projects / Ultimate Zombie Fighters

« on: August 15, 2010, 06:42:17 am »

Actually there is a leak spawning system in place but I kind of screwed up the parameters. The zombies spawn way too fast in the later rounds.

I'm not sure we're talking about the same thing. When is it supposed to kick in? Cuz i haven't seen what I'm talking about and got to lvl 15. Looks like a regular levelling system is used.

Also, a leaking spawning system (by design) can't spawn too fast. Only the levels may not be balanced. A leaking spawning system is used to deal with the fact that you can only fit so many units on the map at once. By spawn speed it sounds like you're talking about levels.

If you are using a leaking spawning system I hope it's optimized to recycle units instead of creating/destroying them (I haven't looked in the code yet).

28

SFML projects / Ultimate Zombie Fighters

« on: August 14, 2010, 12:15:53 am »

Got to lvl 15 with a laptop touchpad.

You should have someone or a team go through and balance it more. Currently it's about 10% balanced.

Also, it should spawn more zombies as the levels go up, not make them stronger. I noticed this around lvl 10. Took more than 1 shot to take down the yellow zombies (usually 1 puts them down). Since you can only fit so many zombies on the screen, you could use a leaking spawning system. I have more comments about it but I'll stop there.

I'm interested in working on a zombie game in the future (after rewriting cpGUI). I'm primarily interested in game mechanics (guns, # of zombies, equipment, etc.). Mind if I join you sometime?

EDIT: Also I read your blog about Mac OS. I have access to a Mac at my uni so can test there if needed.

29

SFML projects / Ultimate Zombie Fighters

« on: August 10, 2010, 04:17:38 am »

Thanks for fixing it. Interesting game. Some ideas:

* Menu
* Pause game
* Multiplayer - at least LAN
* Graphics upgrade - attack animations, running, etc.
* Don't allow player to repair window and shoot at same time.
* Dual wield guns
* Melee weapons, dual wield melee weapons
* Setup bombs, land mines, etc.
* Missile launcher
* Auto Turret (with limited ammo, etc)
* Gun that pierces through multiple targets (in a row, i.e. AP rounds)
* Flame thrower
* Don't make fast zombies. Only fast zombies should be dogs. Zombies should only get tougher and/or cause more damage. The whole point behind zombies is there are so many of them.
* There should be more zombies. The player should be avoiding getting surrounded by them, not them catching up to you.
* Be able to create barricades.
* Get bonus points for stuff (e.g. not getting hit at all during the round, not missing a shot during the round, etc.)
* Sound effects

Got to 6 rounds on first try with laptop touchpad.

30

SFML projects / Ultimate Zombie Fighters

« on: August 09, 2010, 01:01:44 am »

Code: [Select]

[ 17%] Building CXX object src/CMakeFiles/uzf.dir/include/micropather.cpp.o
/cache/home/recruit0/downloads/uzf-0.1.2-source/src/include/micropather.cpp: In member function ‘unsigned int micropather::PathNodePool::Hash(void*)’:
/cache/home/recruit0/downloads/uzf-0.1.2-source/src/include/micropather.cpp:357: error: cast from ‘void*’ to ‘MP_UPTR’ loses precision
/cache/home/recruit0/downloads/uzf-0.1.2-source/src/include/micropather.cpp: In member function ‘void micropather::MicroPather::GoalReached(micropather::PathNode*, void*, void*, std::vector<void*, std::allocator<void*> >*)’:
/cache/home/recruit0/downloads/uzf-0.1.2-source/src/include/micropather.cpp:515: error: cast from ‘void*’ to ‘MP_UPTR’ loses precision
/cache/home/recruit0/downloads/uzf-0.1.2-source/src/include/micropather.cpp: In member function ‘int micropather::MicroPather::Solve(void*, void*, std::vector<void*, std::allocator<void*> >*, float*)’:
/cache/home/recruit0/downloads/uzf-0.1.2-source/src/include/micropather.cpp:703: error: cast from ‘micropather::PathNode*’ to ‘MP_UPTR’ loses precision
/cache/home/recruit0/downloads/uzf-0.1.2-source/src/include/micropather.cpp:703: error: cast from ‘micropather::PathNode*’ to ‘MP_UPTR’ loses precision
make[2]: *** [src/CMakeFiles/uzf.dir/include/micropather.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/uzf.dir/all] Error 2
make: *** [all] Error 2