SFML community forums
General => SFML projects => Topic started by: priomsrb on July 30, 2010, 10:08:32 pm
-
Hi,
My friends and I have been working on a game for the last month. It's called Ultimate Zombie Fighters (uzf). It is an open source, cross-platform, 2d top-down zombie shooting game inspired by Call of Duty 5: Nazi Zombies.
The aim of the game is to survive as long as possible. The zombies will try to break the windows and try to get you. You will need to kill them and repair the windows to stay alive.
Screenshot:
(http://uzf.sourceforge.net/screenshot.jpg)
We just released a 0.1 version which is kinda playable. You can get it from it's website: http://uzf.sf.net
There are executables for windows available, but for linux(tested) and mac(not tested) you will need to compile.
To compile from source you need:
cmake
SFML >= 1.5
Box2D >= 2.1 (I think)
Please try it out and let us know what you think.
=========================
Using SFML has been an awesome experience. Compared to SDL it has a much nicer syntax and accelerated rendering makes the game feel smooth. Big thanks to the developer for a great library.
Just one small gripe though: It seems from 1.5 to 1.6 the rendering is slightly more glitchy. You can see in the screenshots that there are some faint lines which are the borders of the zombie sprite. It's small but I hope that it improves in the next version of SFML.
Game Features on the SFML side:
- using sf::Views to simulate camera
- custom ImageManager to cache already loaded sf::Images
- custom code to implement tiling
The source code is available from the website so feel free to look around.
Thanks!
-
I played it. But first, here's a tip, don't copy a commercial game directly, not because of copyright issues, but because of originality. If you made a few tweaks that made your game funner then wouldn't that be better than making a clone?
Anyway:
1. Easy install, might wanna use a more "common" compression method, specifically .zip
A lot of windows users don't know any better, dont make them download another program to get yours running(7zip)
2. Easy controls, just like COD
3. The camera's mouse integration(something I wanted in my own game) is great
So is the various weapon loading bars(rate of fire, ammo)
that one is a very good idea.
4. Thought of adding particle effects?
Why not vehicles?
5. Lastly, how much planning have you done? Cause professional games usually start off with a 10 page thing outlining all the aspects of the game, try doing this
Good luck, *russian accent* I hope your game is downloaded many times, comrade.
-
Thanks a lot for your feedback.
You're right the game does take heavy inspiration from COD5. However we also have some ideas that are different. For example the ammo is more realistic: you lose entire clip while reloading. I think once we get more progress, more original ideas will start coming up.
If you made a few tweaks that made your game funner then wouldn't that be better than making a clone?
I agree. The purpose of the game is definately to be fun rather than a strict clone. Do you have any specific ideas in mind?
1. Yeah. After your comment, I've uploaded a zip version as well. However the zip file is 1.8Mb compared to the 1.1Mb .7z file. Hopefully this will convince more people to use 7zip. ;)
2. Yes box2D moves the objects smoothly and handles collisions nicely.
3. Thanks. The camera and weapon bars were actually inspired by the multiplayer game soldat.
4. Particle effects are planned. Vehicles are an interesting idea. Will need to think of a way to balance them though.
Lastly, how much planning have you done? Cause professional games usually start off with a 10 page thing outlining all the aspects of the game, try doing this
Haha. We're pretty unprofessional at this stage. We do most of our work in our free time and in between classes. In fact I'm starting to fall behind now ;)
There is no formal plan yet. We have a rough idea of what to do and I just keep a todo.txt file around where I check things off. Again once we start making more progress this might change. Things planned for future releases include:
* Sound
* Particles
* Corpses
* HUD effects
* More weapon types
* Camera effects
* GUI
* Multiplayer
Multiplayer is actually one of the main objectives. But it seems quite hard to do. I've looked at a few libraries it looks quite compicated. Once the single player is in a decent state I might start on that.
I noticed that you are also developing a similar game. How is your progress? I looked at some of your screenshots from your previous game and it looks quite nice. Hope it goes well.
It's really good to get some feedback from someone who has some knowledge in this genre. Thanks again for the advice. Hope your game is downloaded many times too ;)
-
If your using SFML and looking for network library just use the sf::Network class for it and you might want to read bjee's guide to network programming. Not that complicated, but some problems might come like how to send a packet when your waiting for a packet. To get around this you either use threads or use selector and both are provided with SFML too.
Networking for like 4 players you can easily keep sending movement packets constantly. Like you could have packet "PMU1" (Player Move Up ID1) that's 4 bytes. Send it to the server and server broadcasts it to the 3 other players it becomes 12 bytes. If everyone moves constantly the most it would use is 4 bytes * 4 players * to 3 players = 48 bytes, but this of course raises quite fast the more packets are sent per second.
Anyway looking nice. :) Survived 7 rounds with touchpad on my laptop ran out of bullets. More player sprites would be nice to have like with different weapons, seems bit idiotic to use a rifle when the sprite has a hand gun.
For the matter of 7zip quite many extractors support it and after this week i've never downloading zip from sourceforge anymore as all of them have been corrupted.
-
I looked a little at sf::Network and some other low-level networking libraries recently. I think I might choose enet (http://enet.bespin.org/) since it doesnt require threads and makes it easy to send reliable packets.
I've never done netowork programming before and so it seems really interesting and challenging. It's almost like a new way of thinking. However every time I think about it I get scared because of all the issues that can occur (high lag, cheating, synchronisation problems). Perhaps I should try to get a basic system working and worry about those later.
Have you made any networked apps before? Is it really as hard as I think it is?
Survived 7 rounds with touchpad on my laptop ran out of bullets
Wow must be hard on a touchpad. You can buy more ammo from where you bought your gun. I'm guessing you ran out of mp5 ammo ;)
-
My game is in a development standstill, but only because my compute or windows or sfml or code::blocks or explorer.exe or something on my computer didnt wanna co-opeate, so i stopped making the game in c++
BUT i have been planning a lot and i have a bunch of ideas, just nothing playable
And i ordered a few programming books to help get me started
i think ill make a screensaver then a AI demo then ill start making my game, cuz im WAY in over my head, ive barely finished making the console apps. But whatever, the only thing i really need is the will to do it
And hers some more ideas for your game...
in the main menu(when you make it), put sumthing cool in the background, like a AI battle, or conways game of life
zombies should have a LOT of variety, and a few special zombies that fire weapons randomly, cuz the guns are glued on to them for some reason, maybe fat zombies that can crush you?
add easter eggs
keep the game as small, fast, and efficient as possible
you should do a quick pong game to learn how to do multiplayer games
have teammates
have a scripting language for variables like.... AI reaction time, deafult health for player, speed of player turning
Thanks for replying
*UPDATE*
make your zombies have a dancing mode, so when thats activated they stop what thyre doing and dance
maybe f8 activates dancing?
dancing = spin around wildly
-
HAI!
I uploaded my game's graphics, use them well
also.... i used an obscure compression algorithm called balz
you need 7zip
It has backgrounds, and sprites
15.3 MB
.svg, .png, and .jpg files included
all the images are very high resolution, none of that 32X32 pixel crap
Here's he link:
it goes to uploading.com, i am an unregistered user
http://uploading.com/files/d8c4bab7/HAI%2521.20100802-125013.tar.balz/
I think i may wanna contribute to your project, if you need any more help just ask
-
Tried and failed building it on Fedora Linux.
./build.sh
-- Configuring done
-- Generating done
-- Build files have been written to: /home/recruit0/downloads/uzf-0.1-source/build
[ 1%] Building CXX object src/CMakeFiles/uzf.dir/include/micropather.cpp.o
/cache/home/recruit0/downloads/uzf-0.1-source/src/include/micropather.cpp: In member function ‘unsigned int micropather::PathNodePool::Hash(void*)’:
/cache/home/recruit0/downloads/uzf-0.1-source/src/include/micropather.cpp:357: error: cast from ‘void*’ to ‘MP_UPTR’ loses precision
/cache/home/recruit0/downloads/uzf-0.1-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-source/src/include/micropather.cpp:515: error: cast from ‘void*’ to ‘MP_UPTR’ loses precision
/cache/home/recruit0/downloads/uzf-0.1-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-source/src/include/micropather.cpp:703: error: cast from ‘micropather::PathNode*’ to ‘MP_UPTR’ loses precision
/cache/home/recruit0/downloads/uzf-0.1-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
-
Tried and failed building it on Fedora Linux.
Ahh. You must be using 64-bit linux am I right? There was a small bug that I just noticed from your compile output. I just fixed it and uploaded a new source package. You can get it from here (https://sourceforge.net/projects/uzf/files/). Please test it out again to see if it works.
Thanks a lot for reporting the error. I wouldn't have realised it if you didn't report your problem.
-
i think ill make a screensaver then a AI demo then ill start making my game, cuz im WAY in over my head, ive barely finished making the console apps. But whatever, the only thing i really need is the will to do it
I remember I had the same problem 5 years ago when I tried to make my first game in c++. I could make pretty complex games using game maker so I set my sights VERY high. I had features planned like skeletal animation, slow motion physics, advanced weapon systems etc. After 1 month of development I gave up. My code was getting really hard to modify and my game wasn't very playable.
As I started on working on more projects I started setting my aim lower and lower. Eventually as my aims decreased, and my skills increased I was able to start making more complete projects.
My advice is to set your aim low for now. I know that when you are thinking of ideas it is easy to start getting wild and excited. Focus on doing the easiest parts (eg a character moving on screen) first. This will give you more encouragement and a better judgement of how far you can go.
There are many people out there with little experience who want to make the greatest MMORPG of all time. However they never end up producing anything. With experience you get a better understanding of what you are capable of. In fact I now realize that I still wouldn't be able to make that first game I started even after all the experience I gained after it.
I think i may wanna contribute to your project, if you need any more help just ask
We keep our latest source code and data in a git repository:http://sourceforge.net/projects/uzf/develop. At the moment our team is small but sufficient. My friend and I are doing coding and the artwork together.
However our game is designed to be easily modified (weapons, enemies, maps), so it will be easy to make your own mods and stuff for it.
-
Okay thanx for the advice, i too can make very complex games with game maker, but with C++, its just so big, well better start my screensavers now
And did u get the graphics package?
Oh and....
does using box2d for the collisions make the game slower by adding all the box 2d stuff? is it worth it?
P.S.
The .exe runs fine with Wine on ubuntu x64
-
Yeah I did get the graphics package. It's got some nice sprites and textures. For the moment though, we might use some in-house graphics to keep consistency. If we do use some parts of it, I'll let you know. Thanks for uploading that.
I chose Box2D because it meant I didn't have to write my own collision system. Also it gives you rigid body physics allowing the game to feel more realisitc.
Box2D is designed for games so while there is some overhead, on modern computers it is barely noticable. The pathfinding is not very effecient at the moment at that is probably the biggest culprit at the moment. Even then the game only uses up ~15% CPU here.
The .exe runs fine with Wine on ubuntu x64
Ok that's good to know. It runs fine here on 32bit wine as well.
-
Good to know, you should start working on the credits screen, put my name in if u use anything
And fi the pathfinding... i think i can help you with that, and the whole AI thing for that matter, specifically ill send you a few files that i may or may not have the rights for(I may or may not have typed that)
And can you explain how box2d works, or how you use it? Does it make and index(or vector or list) of physics objects and every step it checks for collisions? How do you register the physics objects? Do they inherit from box2d::physics objects? Thanks for the help
Lastly
What kind of specs does your slowest testing machine have? Cuz its very important to remember that some people still run very old&slow cmputers
I made my best and last game maker game on a 2004 machine, and Im sure that its the most efficient game maker game ever.....
I also made it so it looked pretty on newer machines by:
1.using animations instead of particles for explosions(via a setting)
2. using a special sprite(image with all the variables needed for moving images) to tile(image without vars for moving, a static image), thus saving resources
Im not sure how to make this work with sfml, maybe you could somehow strip sfml::sprite so only x and y are inherited
call it sfml::miniSprite
This may be going too far, unless you are gonna have thousands of ponds of blood onscreen that stay there reminding you of where and how you fought
And if the FPS goes too low just delete half the blood
to see first hand, go here:
http://www.yoyogames.com/games/70936-zombie-wars-2
click on download game, not Play Now(you need a plugin for this)
This game also runs fine in ubuntu 64
-
Make zombies weaker(less damage to wall) when health is low
-
I see your using micropather for a*, how is that? Was it easy to get working correctly?
-
By the way, Boost contains already optimized pathfinding algorithms like A* or Dijkstra's. Take a look at the Boost.Graph library.
-
Take a look at the Boost.Graph library.
Thanks didn't know about that. Looks interesting.
I see your using micropather for a*, how is that? Was it easy to get working correctly?
Micropather is a generic path finder so you can use it for 2D, 3D and with edges or vertexes or areas. However despite it's genericness, it was quite easy to use it for my 2d, vertex based pathfinding. I think you only need to override 2 simple functions and it does the rest for you.
Make zombies weaker(less damage to wall) when health is low
However that means that a player can hold up a window forever if the zombies next to it are weak. This will be a problem if there are 3 people playing since they will never die ;).
-
Ahh. You must be using 64-bit linux am I right? There was a small bug that I just noticed from your compile output. I just fixed it and uploaded a new source package. You can get it from here (https://sourceforge.net/projects/uzf/files/). Please test it out again to see if it works.
Thanks a lot for reporting the error. I wouldn't have realised it if you didn't report your problem.
Yes I'm using 64 bit. You seem to have not completely fixed it. Another error (same):
[ 62%] Building CXX object src/CMakeFiles/uzf.dir/Scenes/Test/LevelGraph.cpp.o
/cache/home/recruit0/downloads/uzf-0.1-1-source/src/Scenes/Test/LevelGraph.cpp: In member function ‘sf::Vector2f LevelGraph::getGridPositionFromState(void*)’:
/cache/home/recruit0/downloads/uzf-0.1-1-source/src/Scenes/Test/LevelGraph.cpp:66: error: cast from ‘void*’ to ‘int’ loses precision
/cache/home/recruit0/downloads/uzf-0.1-1-source/src/Scenes/Test/LevelGraph.cpp: In member function ‘virtual float LevelGraph::LeastCostEstimate(void*, void*)’:
/cache/home/recruit0/downloads/uzf-0.1-1-source/src/Scenes/Test/LevelGraph.cpp:134: error: cast from ‘void*’ to ‘int’ loses precision
/cache/home/recruit0/downloads/uzf-0.1-1-source/src/Scenes/Test/LevelGraph.cpp:138: error: cast from ‘void*’ to ‘int’ loses precision
/cache/home/recruit0/downloads/uzf-0.1-1-source/src/Scenes/Test/LevelGraph.cpp: In member function ‘virtual void LevelGraph::PrintStateInfo(void*)’:
/cache/home/recruit0/downloads/uzf-0.1-1-source/src/Scenes/Test/LevelGraph.cpp:200: error: cast from ‘void*’ to ‘int’ loses precision
make[2]: *** [src/CMakeFiles/uzf.dir/Scenes/Test/LevelGraph.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/uzf.dir/all] Error 2
make: *** [all] Error 2
-
You could make a small controlled explosion after holding up a windows for too long :P
-
Yes I'm using 64 bit. You seem to have not completely fixed it.
Ok I added some more fixes to the code. Please check now if it works. http://sourceforge.net/projects/uzf/files/uzf/0.1/uzf-0.1.2-source.tar.gz/download.
BTW you can get the latest unreleased source from git:
git clone git://uzf.git.sourceforge.net/gitroot/uzf/uzf
You could make a small controlled explosion after holding up a windows for too long
Hehe :D. Seems a bit random though.
If you feel that the game is too hard at the moment, that is because the level isn't balanced very well. A well designed level will let you progressively get stronger (in terms of weapons and escape routes) as the zombies get harder.
-
[ 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
-
Sorry. I finally got hold of a 64-bit machine today and made some more changes. I was able to succesfully compile on ubuntu 9.10 64-bit. Please test again to see if it works now.
http://sourceforge.net/projects/uzf/files/uzf/0.1/uzf-0.1.3-source.tar.gz/download
I really hope I didn't screw up again. :)
Thank you for your patience.
-
I looked a little at sf::Network and some other low-level networking libraries recently. I think I might choose enet (http://enet.bespin.org/) since it doesnt require threads and makes it easy to send reliable packets.
I've never done netowork programming before and so it seems really interesting and challenging. It's almost like a new way of thinking. However every time I think about it I get scared because of all the issues that can occur (high lag, cheating, synchronisation problems). Perhaps I should try to get a basic system working and worry about those later.
Have you made any networked apps before? Is it really as hard as I think it is?
Survived 7 rounds with touchpad on my laptop ran out of bullets
Wow must be hard on a touchpad. You can buy more ammo from where you bought your gun. I'm guessing you ran out of mp5 ammo ;)
I have written small chat client/server applications, it's not that hard, but i like more low level networking libraries like berkeley and winsock as they don't come in way, but sf::Network is nice as i can easily make the packets easily and it still does not come in way.
I actually ran out of mp5 ammo and then didn't have money to buy more and kept running out of ammo from other weapons i died just before i could buy more. :P
-
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.
-
Sweet. Glad its working now :)
Thanks for the list of ideas. Theres some good ideas there that we didn't think of.
* Multiplayer is one of the main aims for the game.
* We are currently going working on the graphics. They will soon replace my cruddy programmer art ;)
* New weapon types are a bit tricky but may come slowly.
* Not having fast zombies is an interesting idea. Never thought about it that way.
* Bonus points sound like fun
* Sound is being worked on right now. Should be in the next version.
-
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.
-
Got to lvl 15 with a laptop touchpad.
Wow. I think thats a new high score :D
You should have someone or a team go through and balance it more. Currently it's about 10% balanced.
I agree, the current map, weapon and zombies aren't well balanced. Hopefully the next version will be better in this regard.
Since you can only fit so many zombies on the screen, you could use a leaking spawning system
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 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?
Sure. It would be great to have another coder on the team. When you are ready just tell us. Also cpGUI looks interesting. When we start on the GUI it could be handy.
Also I read your blog about Mac OS. I have access to a Mac at my uni so can test there if needed.
That'll be great. I've seen some people downloading UZF from a mac but I'm not sure whether it is actually working for them. Being able to provide a binary package for them would be nice.
-
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).
-
The spawning system is a bit complicated. Basically the level designer chooses how many zombies of which type appear each round. After the last round that the level designer has given spawn data for, the zombies get healthier and faster by 10% per round. In the default map the spawn data for the first 10 rounds is given. Which is why each subsequent round, the zombies get tougher.
The leaking system works like this: there is a max limit of 50 zombies alive at any point (which is never reached in the current map anyway). A zombie is spawned every 2/roundNumber (which is too fast for later maps. perhaps 1 + 1/roundNumber would be better). Adjusting these 2 formulas will result in a better spawning system.
If you're curious, the code for the spawning can be found here (http://uzf.git.sourceforge.net/git/gitweb.cgi?p=uzf/uzf;a=blob_plain;f=src/Objects/ZombieSpawnController.cpp;hb=HEAD)
-
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.
-
Thanks for your insight. I didn't think about having large number of zombies before. It could be interesting, gameplay wise. However there may be issues with CPU usage (due to pathfinding) and network bandwith. However those may be overcome by clever(and perhaps tricky) optimizations.
But the game is still being balanced so we could try adding in large numbers and see how it plays.
Also with larger maps you can have multiple buildings. So, the player will have an incentive to move around more (besides avoiding zombies).
Yeah there is a lot of map ideas that should be tried out. I will try to put up a mapping guide in a later release. If you want to try it now just open the data/maps/test_map.svg file in inkscape (http://www.inkscape.org). (Hint: you can use the object properties dialog to change different map/object parameters)
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 also think having boundary walls doesnt feel right. My idea was that if the player goes too far out then he starts becoming affected by radiation and starts slowing down, so eventually the zombies will get him ;)
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.
The zombies only start levelling after spawn data has finished (round 10 in the default map). I did this because in zombie games it sometimes gets to a stage when equilibrium is reached, ie the players can hold out indefinately. So I added that to make it more challenging for advanced players, and to also make sure the game doesn't end up being boring in the later stages. Also, yes upgrades are being thought of for later versions.
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.
Well I think it should be up to the level designer to choose that. Because some maps may require certain positions for spawn points. Anyway if you want you can position the spawn points all around the edges of the map, achieving the same effect.
I should probably write up a document or something because there are a lot more details that I could go into besides the above.
Sure. We'd love to hear your ideas. You are welcome to use the project wiki (https://sourceforge.net/apps/mediawiki/uzf/index.php?title=Main_Page) if you wish.
-
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 :D
-
or have fog around the map
and add turrets as an upgrade, maybe a home base surrounded with turrets and you have to go out and "home base-ify" other bases until you've conquered every base in the province.... then make them do it again in the next province, and the next province, and the next.
Maybe you could have a different zombie in each province?
How about an unlimited province system?
Perhaps have cars or helicopters as a way of traveling provinces, and to make it realistic, you rescue an engineer who has a machine that makes fuel out og oxygen, it is a light and portable machine.... but takes a long time to fill up a car's gas tank. Also he lives in your current bases' basement and you must protect the door of the basement as well as yourself
[/i]
-
Sure. We'd love to hear your ideas. You are welcome to use the project wiki (https://sourceforge.net/apps/mediawiki/uzf/index.php?title=Main_Page) if you wish.
I don't have permission to edit any of the pages.
-
Sorry for my late reply. I've been a bit busy the last few days with assignments and stuff.
Firstly, wow! You guys came up with some really nice ideas.
Instead of a health bar, show a health donut (or circle) under the player's character.
Thats a very good idea because when you're getting damaged, it is hard to look at the corner of the screen, because you will be looking at your player and trying to dodge.
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.
I'm not fully sure about this one though. Having it around the player means it constantly moves around. Also not as much info can be shown around the player. 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. That's why I think it will be better to keep the ammo in a constant position on the screen.
Showing clips might be a good idea because it requires less mathmatical skills. (what is 105 / 35? quick! ;))
Move the reload bar near the mouse cursor. Perhaps change it also to a donut/circle.
I was thinking the same thing.
Only the level number and number of points is left. Move these to the top center of the screen.
We could try that.
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.
This was mainly because we were going for a realisitc weapons theme. Also having more variety of weapons gives players more choice (should I use a sub machine gun with faster fire rate or more accuracy?). Anyhow the weapons system is flexible so either system could be used.
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).
Yeah, bullet penetration is needed especially when the number of zombies increases. Headshots will be a bit tricky but I will try anyway. Scoping is also a good idea. Also red-dot sight could be done for other weapons as well.
Using real gun models (e.g. AK47, M4, etc.) may not be practical.
I guess it is harder to balance when you try to have realistic weapons as well. But again this is not too big of an issue.
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).
Yup grenades. Also, fire sounds quite interesting. It could spread when zombies are too close together :D
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.
Yup. I'm thinking of adding land mines in the next release.
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 )
Dual wielding should be done in such a way that it is intuitive. Maybe you can only carry 2 weapons around, and if you press a key, then the character tries to duel wield (if weapon weights allow). 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.
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.
Parachutes are a nice idea. They will give the incentive to move around in the map rather than camping in one spot.
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).
Yes more special levels will be good. Also how about spider zombies. They should move around fast and erratically.
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).
A friend of mine suggested the same thing.
Also would be good if the player could sprint too.
Yeah this would need to be done in a balanced way.
And when zombie kills a team mate, they turn into zombie.
Maybe a game mode? We thought of some other ones as well:
- Competitive Mode: Player who kills the most zombies in a round gets a point. Person with the most points at the end wins.
- Sabotage Mode: The players try to indirectly kill each other. Use traps, lock doors, trick zombies etc. Who's gonna spend their money to open that door first? ;)
- Pascifist Mode: Try to survive as long as possible without weapons. Using traps is allowed.
Also need a replay system so people can show off their kills
Yeah. Also it's useful for confirming high-scores.
---------------
Wow thats a lot of ideas. It'll definately be hard to implement all of those. That's why I'm trying to do things incrementally. But it's nice to see that there are a lot of possibilities.
I don't have permission to edit any of the pages.
Yeah it turns out normal users can't edit the sourceforge hosted wiki pages. So I've created a new one on Wikia. It seems much better. Faster, easier to use, customisable, only disadvantage are the ads. This should be editiable by anyone. URL: http://uzf.wikia.com
-
and add turrets as an upgrade, maybe a home base surrounded with turrets and you have to go out and "home base-ify" other bases until you've conquered every base in the province.... then make them do it again in the next province, and the next province, and the next.
Maybe you could have a different zombie in each province?
That's quite interesting. Kind of like a single player campaign mode. Also turrets can be useful if you put them strategic positions. But it should cost to reload them otherwise players may abuse them.
Perhaps have cars or helicopters as a way of traveling provinces, and to make it realistic, you rescue an engineer who has a machine that makes fuel out og oxygen, it is a light and portable machine.... but takes a long time to fill up a car's gas tank. Also he lives in your current bases' basement and you must protect the door of the basement as well as yourself
That's another interesting concept. You can rescue survivors, keep them safe and in return they help you.
Like I said before, I can't promise anything at the moment because there are many ideas to think about. First priority is definately to get the basics working especially multiplayer.
On another note, my friend who is doing the artwork said that others can join in. If you are happy to make some art, we'll try to put it in the game. But we'll need to talk over what sprites/images we will need and stuff.
-
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.
-
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).
We could try that and see what it looks like.
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.
True but unlike shooter games, the enemies can only melee. So getting a direction for the hit might not be as useful. We could try nonetheless.
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.
I agree. It will be better for the weapons to have different qualities rather than just changes in damage, ROF etc.
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).
Unless it's a rambo bow ;)
You can't dual wield sniper rifles anyway ( that's just silly Wink ).
What I meant is that when single wielding, right click will be used for aiming. So when the player shoots without right click, he will move faster but the shots will be less accurate since they will be from the hip. When they are aiming, they will move slower but will be more accurate. So when duel wielding, the player will only be able to hip shoot (which is realistic)
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).
Infection could be an interesting mechanic. Finding cures is also a nice idea.
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.
Thankfully sfml views can zoom in/out so we can change the view easily.
-
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).
-
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.
I'm not sure what you mean. Right now the screen does go red when you are attacked. Are you talking about something different?
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).
Hmm. But what benefit will standing, proning or kneeling have in a top down game where the enemies can only melee?
I suggest having an aim mode, because realistically if you run around with a gun, your shots will be inaccurate. On the other hand if you aim down the sights to get a good shot, you will move much slower. So there are 2 options which need to be used for different situations. But I do see your concern with using different buttons to switch modes rather than having a single mode. Maybe there can be a middle ground somewhere.
-
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).
-
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'm thinking that there could be a broadcast locating system. When the player makes a loud sound or is spotted by a zombie, his position is broadcast to all the zombies. The zombies then head for that position. There could be areas of the map that are shadowed, and the zombies can't see the player if he is hiding there (also works if the player hides behind obstacles).
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).
Nice work on the wiki. Also good luck with cpGUI.
-
I'm thinking that there could be a broadcast locating system...
Yeah that's wut i was thinking. Whenever weapons make a sound, it chains through and gets all the zombies to respond depending on if they'd hear it or not.
With spotting you, only zombies that can see that zombie should follow it.
Nice work on the wiki. Also good luck with cpGUI.
Thanks. It's not that complicated (not as complicated as UZF anyway). Most of my effort is going into making myself finish what I started. :lol:
-
Hello, priomsrb, i was randomly looking through the forum and found your project(Btw, a very nice game!), as i understand, you use Box2D and Cmake for collision, i tried to launch it some time ago, but it was sophisticated enough...
I'm very happy that i've finally found someone, who knows how to use Box2D, so could you explain to me how to work with it or give me a link to a good tutorial and to the source code for your game if it is open-source?
Thanks in Advance =)
-
Hi GreenFlame. Sorry for the late reply. Somehow I didn't get a notification email for your message.
Yes Box2D is used for collisions and physics but CMake is used for generating makefiles and compiling.
For 2d physics/collision you can Box2d or chipmunk. For both I used the official manuals to find out how they work. There are plenty of tutorials available on google as well. It's not very easy to explain how they work in a forum post (I forgot a lot of it as well), but it is not too difficult.
The source code for my game is available here (http://sourceforge.net/projects/uzf/files/uzf/0.1/uzf-0.1.3-source.tar.gz/download). You can find some examples of Box2d code in src/Engine/PhysicalScene.cpp and src/Objects/Bullet.cpp::setupPhysics().
-
Thanks for the reply! I hope the source code wil help me to learn Box2D =)
Thanks again and Good Luck! =D
-
Here's a few more ideas, I'll put them on ur wiki later....
This ones for when you guys are a lil closer to version 2.0
On your website make a BIG download free button at the top of the page, make it pick a random mirror with a script and immediately start downloading, then on the " oh great you downloaded it" page add links for help, FAQ, and other stuff you think they should see
For single player mode only make the weapon, zombie, vehicle, survivor attributes in a txt file, so if you are bored you can make the flamethrower have infinite ammo and fire 360 degrees around you
Is there gonna be split screen?
I like the green zombie who can infect you thing, please add this, it'll make your game unique
Also... I'm pretty sure I promised you I would benchmark your game... Well I didn't sorry, but now I will... I'll make a few virtual machines with what I think will be your games system requirements and make them weaker until your game cannot run properly
Broadcast locating FTW, but make it so only half the zombies hear you
Lastly, have you thought about things like zombie cows? Or zombie crows? Maybe even not zombie stampedes of animals to signal the coming of the zombie horde? Won't that be great, you suddenly find your building surrounded by stampeding cows before the zombies come
-
For single player mode only make the weapon, zombie, vehicle, survivor attributes in a txt file
They are... although a XML file more specifically.
Is there gonna be split screen?
I vote for this as well. Although, this shouldn't be a high priority (there are many things that need to be developed first, see wiki).
Also... I'm pretty sure I promised you I would benchmark your game..
At the moment there's not much to benchmark. Once the game implements leaky spawn system (correctly) then there will be something to benchmark (hundreds or even thousands of active units on the map).
Lastly, have you thought about things like zombie cows? Or zombie crows
Yes, I've thought of other types of zombies (see the wiki). As for crows, that falls under zombies classified as "Kamikaze". I'm still undecided on the name, but it describes their aerial suicidal attacks. I believe there is room for more types of zombies though.
-
For single player mode only make the weapon, zombie, vehicle, survivor attributes in a txt file, so if you are bored you can make the flamethrower have infinite ammo and fire 360 degrees around you
Actually the weapon and zombie data are all modifiable. They are defined in data/xml/zombies.xml and data/xml/weapons.xml. From there you can modify all the properties of the zombies and weapons. Also we did try to make a flamethrower once when we were bored ;)
Is there gonna be split screen?
Hmm thats interesting. Because the aiming is done with the mouse it means that only one player can use it. However maybe the other player can use a joystick or aim with keyboard (either numpad or keys to rotate). It would be much easier than doing LAN thats for sure.
Also... I'm pretty sure I promised you I would benchmark your game... Well I didn't sorry, but now I will... I'll make a few virtual machines with what I think will be your games system requirements and make them weaker until your game cannot run properly
So far I've noticed that most modern machines run the game well. However one PC with intel integrated graphics was not very smooth.
Lastly, have you thought about things like zombie cows? Or zombie crows? Maybe even not zombie stampedes of animals to signal the coming of the zombie horde? Won't that be great, you suddenly find your building surrounded by stampeding cows before the zombies come
Haha zombie cows :D. I think Recruit0 put up something related to zombie crows that attack in swarms on the wiki. Having non-zombie characters is quite interesting actually, I never thought about that.
-
Have you heard of a game called battle tanks?
It has split screen, LAN, and split screen with LAN, which is exactly what your game should have, it is open source so you can go inside and have a look
Also I posted a few ideas on your wiki and forum, and I read the story, which is awesome, but it needs some refining.... I'll help out!
:idea:
Make an outline of the story first, then write in the details
-
No I've never heard of battle tanks before. It looks quite fun.
I guess I could have a look at the code but since it doesn't use SFML, not much of it will be applicable.
Thanks for contributing to the wiki as well.
I'd like to make an update as well. These days are very busy for me becuase of assignments and exams. My spare time gets spent on other things as well. That's why I am not able to contribute to uzf as much. Even after exams, I have work so I'll still be busy. So I'm unsure whether or not I'll be able to continue working on uzf. Maybe if I am free some time, then I can add some small features and just leave uzf as a small game. Also I may try to clean up the code and document it so that others may add to it. While there are some great ideas out there, I also have a lot of other things I would like to spend my time on so I do not think I will be work on uzf a lot.
-
I get it, make documentation and point people to sfml and the other stuff you used, I've seen really old games get revived and after being made awesome, they are abandonded again. perhaps someday someone will pick up your game. Be sure to make it as pretty and bug free before you leave it though, you want to attract developers not repulse them... well buy bye have a nice Australian(?) life
recomend sfml to your loved ones and fellow developers, it is a good library
-
Thanks for the advice. Yeah I do need to clean up and document things so that other can use it.
well buy bye have a nice Australian(?) life
It's New Zealand actually ;)
recomend sfml to your loved ones and fellow developers, it is a good library
Yeah definately. SFML is my favourite multimedia library.
-
Hi there ! I played with your game, and i have to say : nice job ! (But I can't finish the 8th level >.<)
Well, I read your sources, and I like the way you made your engine, so, I was wondering if I could draw inspiration from your code ?
PS : Sorry for the English, it's not my language ^^
-
Sure go ahead. It's all open source so you can copy/extend it anyway you want.
Just a warning though: there might be some small bugs and inconsistencies in the engine that I haven't fixed yet. But overall it works quite nicely for me.
-
Ok, thanks a lot. If I see a bug or something I'll report it to you.
-
Do you mind passing along some links for learning about factories? I had a look through your code and I'm a little intimidated.
(Kind of a beginner here...)
-
I'm a bit shaky with my design pattern knowledge as well. But here is basically what I know:
A factory basically creates and returns objects.
Say I have a class called Enemy. And say that I have some other classes called Zombie, Robot and Ninja that are inherit Enemy. I can then make a EnemyFactory class that let's me easily create any type of enemy along with it's color and HP. For example:
Enemy *someEnemy = EnemyFactory::create("Robot", "red", 100);
This will create a red Robot with 100 health.
I needed something like this in UZF so that I could create objects from strings scanned from xml files.
----------
I couldn't find any good links about learning about factories myself. Probably best to google it and read what's there.
-
Take a look at Design Patterns and Refactoring (http://sourcemaking.com/).
-
That's a nice website.
Thanks for the link Nexus.
-
Thanks. :)