Features eh...? For starters:
1. Ability to carve out tunnels and rooms inside mountains and hills.
2. Ability to alter the ground by digging trenches or making dirt paths.
3. Ability to murder trees and process them into usuable material.
4. Ability to make various items from rock and wood.
5. Ability to make walls outdoors with wood and stone.
6. Ability to attack traitorous dwarves.
7. Ability to destroy walls and fill in empty trenches.
8. Ability to collect plants and channel water to promote plant growth.
9. Ability to plant seeds outdoors and grow cavecrops in caves.
10. Ability to sleep in beds to slowly recover health.
11. Ability to eat to speed recovery when resting.
12. Ability to apply herbs to speed recovery when resting.
13. Ability to apply herbs to accidentally poison your best friend.
14. Ability to brew alcohol from various plants and crops.
15. Ability to play as a dwarf!
16. Ability to create simple tools and advanced tools.
17. Finally require tools to work with material, start with some tools.
18. Ability to give tools and materials to other players without having to drop them.
19. Ability to find metal ores while mining.
20. Ability to refine metal ores with smelters and fuel.
21. Ability to find coal to use as fuel instead of wood.
22. Ability to create tools and items from metal at a forge.
23. Ability to find gems while mining.
24. Ability to work gems into various shapes.
25. Ability to encrust items with gems.
26. Ability to examine an item to see its quality and what gems its encrusted with.
27. Ability to decorate items.
28. Ability to make melee weapons and armour from metal.
29. Ability to fight various monsters.
30. Ability to form different factions, groups or guilds.
31. Ability to fight or trade with other factions.
32. Ability to upgrade dirt paths into roads.
33. Ability to make signposts.
34. Ability to gain skill in various trades.
35. Ability to make better items and tools with higher skill.
36. Ability to deal more damage with higher skill.
37. Ability to play as a human.
38...
39...
40...
We would of course have to go into each of these in more detail as we add them. Plus theres room at the bottom to add more features!
One more thing, this would be far easier if we used tile based 2D graphics rather than 3D. So far ive yet to see a 3D game in which you can dig tunnels, excluding Wurm because that uses a tile system.
[ March 08, 2008: Message edited by: Dark ]
So anyone who wanted to join in the previous thread that had nothing to do with programming, post here and vote for which language to use! Then we shall practice until we're no longer dabbling, maybe even until we're no longer novice! After that we can try create some sort of base program than we can start adding features to, hopefully with relative ease.
[ March 08, 2008: Message edited by: Dark ]
EDIT: Spelling
[ March 08, 2008: Message edited by: Fenrir ]
Many newbie programmers seem to think if they make their program open source random people from the internet will start giving them a hand. They won't.
That's why DF is fully playable and all the other ambitious games haven't even left the planning stage.
[ March 08, 2008: Message edited by: subject name here ]
I support 2d tile-based graphics, and would like to propose the following system for goals:
D: Demand
S: Sub-demand
T: Technical solution
D1: Starting the game:
It must be possible to run a certain file to start playing the game.
T1: Compile an exectuable file.
D2: Making a character:
It must be possible to create a character.
S1: The character should be different from other characters.
S2: It must be possible to play as a dwarf.
S3: Other races, such as humans, might be implemented.
T2: The game must contain and save an extensive array of variables that is a character. They include race, looks and abilities.
D3: Internet connection:
The game must be able to communicate to a central server, which relays and coordinates data going between all machines playing the game. In essence, everybody is playing the same “level”, albeit in different locations both physically and datawise. They must also be able to interact with each other.
T3: The game must be designed around a certain system that allows for efficient multiplayer. It must also contain code that sends and receives all necessary information and applies it accordingly.
D4: Player action:
The player must be able to move and interact with his environment.
S1: The player must be able to dig tunnels.
S2: The player must be able to build various buildings.
S3: The player must be able to destroy various buildings.
S4: The player must be able to cut down/harvest and plant seeds and plants, above- and underground.
T4: This requires code that changes the variables, which I shall call character_x, character_y and character_z. It also requires code that changes what a certain tile contains.
D5: Player crafting:
The player must be able to make, examine, improve, repair and use various items.
S1: The player must be able to turn wood into various items, such as beds.
S2: The player must be able to turn rock into various items, such as doors.
S3: The player must be able to smelt and forge various metal items.
S4: The player must be able to improve a basic item with other items.
S5: The player must be able to view the items and it’s improvements.
S6: The items must be usable and used in various tasks such as mining.
S7: The player MUST be able to brew booze and drink it.
S8: The player must be able to plant, harvest and process various plants.
T5: This basically is just more arrays and HAS_<ITEM> boolean checks.
D6: Player skills:
The player must have various skills, such as mining, carpentry and lye making. It must be possible to improve them through using them, and they should affect success chance and quality.
T6: Just a large array, really.
D7: Fighting:
The player must be able to attack and be attacked, either by NPCs or other players. Various things to do should be in, such as various fighting styles. Skill and equipment should affect combat.
S1: Wrestling needs to be in.
S2: A detailed wound system should be in.
T7: This one’s a toughie. Lots of booleans, arrays, variables and plain RNG action is needed.
D8: Player-to-Player interaction:
The players should be able to interact with each other in more ways than just fighting.
S1: The players should be able to barter various items.
S2: The players should be able to form actual alliances, guilds and towns.
S3: The players should be able to wage wars between alliances.
S4: The players should be able to build roads and signposts.
D9: Various nonsense:
The word shouldn’t be boring; it should be varied. Ships would be fun to have, too. Carp, elephants, unicorns and GCSers. Magma. Crazy engineering projects. Varied plants, booze, alchemical stuff, minerals, rock types, trees, gems, coal and lignite, and lot’s of stuff like that.
T9: Devote lots of time into making a small array of data for each and every item, for one thing. have various kinds of weather and support for multi-tile creatures. Various kinds of mechanisms.
Feel free to subdivide the demands set forth here further, it'd be better.
Also, if we'll use tiles, what resolution should we use? 16x16 DF tiles? 32x32 tiles for more details? Some other size?
PS: It's waned, not wained, I believe.
Even better, more akin to NetHack/SlashEM for now, make the area that the game is drawn in variable size as well. People with small resolutions will be able to use large tilesets at the cost of how far they can see without 'l'ooking (or equivalent.)
I dislike having such small tiles, but small, well-designed images are quite pleasant to look at if you can appreciate them. Mine aren't that great.
2D example: You are restricted to a flat world that has various hills and cliffs that can be dug into. You cannot see or move on top of hills or cliffs because sight and movement is restricted to any tunnels dug into the hills and cliffs.
3D example: You can move all over the surface, including over hills and up cliffs and you cannot see anything underground. If you stand on a tunnel entrance tile then you lose sight of everything on top of the hills or cliffs but can now see and move underground.
The second example would need some kind of layering, with a surface layer and an underground layer. Plus even more layers if we want to allow players to dig tunnels downwards or upwards too.
In programming I have no idea how to do that! Anyway have we chosen a language yet? I want to get some kind of practice in before we start, otherwise we'll just create a Game instead of a +Game+, or worse, a !!Game!!.
Edit: Actually perhaps 64x64 would be better, my screen is awfully big and I dont want things to be too small, but not too big either.
Im also wondering if Toady could give us a few tips, though that's a lot to ask for. :p
[ March 08, 2008: Message edited by: Dark ]
Anyway, if we're going to have 32x32, I can probably whip up a few graphics. Just as placeholders, though. Eventually I might be able to make it so the sprites would reflect your equipment as well, but that'd be after the game is actually somewhat made.
quote:
He recommends C#, which is much easier on the fresh programmer, but can only run under Windows and may possibly run a bit slower than C++. It will prevent holes in the programming from appearing or at least ruining your comp.
[ March 08, 2008: Message edited by: Dark ]
[ March 08, 2008: Message edited by: Dark ]
quote:Awesome. Have you any wisdom to share?
Originally posted by Boksi:
<STRONG>I took a course in game design. In fact, today was the day I finished said course.</STRONG>
I'd rather have a junky looking character that moved around and interacted with his environment than a really cool looking one that stayed in the exact same pose for eternity.
However, graphics on the scale of Illarion would require full-scale graphical artists, not just knights of the pixel. I don't know if we have anyone of that type around here.
Illarion has changing terrain (thus allowing the placing of crop fields and the construction of buildings/statues), and at least a rudimentary elevation system (might just be a trick of the eye thanks to some well-made isometric graphics), but I don't think you can actually dig into the ground. I haven't played Wurm Online, so I don't know what it looked like or acted like when you dug into a hill or a mountain.
And when you speak of isometric, dost thou speaketh of this?
(http://www.freewebs.com/bokaormur/DFISOMETRICEXAMPLE.PNG)
The tunnel is terrible, but the rest is decent.
And remember, elevation is just another variable, although it makes some things like projectiles more difficult.
But if we're going for a top-down view instead, + shapes would indeed be better.
[ March 09, 2008: Message edited by: Dark ]
I can give a hand if people start a project like this tho. I don't mind coordinating projects or giving programming hints, since I've done it before.
Then once we're novice programmers rather than simply dabbling, we can try and organise outselves better. Then maybe we'll experiment with the code a bit to see if we can create any remotely game-like program. Then after a while we might become even become programmers rather than simple novices.
Then we coordinate our efforts and put what we learned to the test, or we fail and give up, if we havent given up earlier on.
If we dont all agree on C# we can try using C++ or something, but whatever we do we should do it soon. Talk doesnt give experience or get any work done. Once we get started it should get easier, or harder then easier. Or just harder, but easier to progress! Or perhaps not, who knows...
quote:Sure it can! It can even make you superdwarvenly strong!
Originally posted by Dark:
<STRONG>Talk doesnt give experience</STRONG>
quote:
Originally posted by Dark:
<STRONG>Talk doesnt [snip] get any work done.</STRONG>
Actually it does this, too. From what I've learned so far, it's best to just start out talking. Start with the most complex, as in "I want to make a great game that does w, x, y, and z." Talk a bit and find out how to break everything down into the simplest parts possible. I've basically just defined top-down design.
Because the most important thing we need right now is more ideas, as we don't have nearly enough things to bog down the proggers with.
edit: also, C++ has the potential for multiple platforms without a complete language change and rewrite, if it ever gets that popular.
[ March 10, 2008: Message edited by: qwertyuiopas ]
quote:
Originally posted by Kagus:
<STRONG>Because the most important thing we need right now is more ideas, as we don't have nearly enough things to bog down the proggers with.</STRONG>
As someone who hasnt even written a single line of code yet, or even managed to completely decide on a language to use, or even know how to compile the code once its done, or what other software I may need: I really hope you werent serious. For now I would be happy with something I can actually move a preset character around on, nay, overjoyed. I havent even started anything and I'm already bogged down! The sheer mass of the lack of knoweldge I have is threatening to bend space and time!
Alas, all our hopes and dreams are shattered, at least mine are.
Also as far as language, I would not recommend C#. Definately feel that C++ is the way to go - it's not that scary. Here is a free fully featured IDE: http://www.bloodshed.net/devcpp.html
Turns out the site also has programming tutorials and resources including OpenGL tutorials and game source among other things.
[ March 19, 2008: Message edited by: Aeloi ]
So I present this guide. It explains the dark and terrible secrets of TCP/UDP in C/C++. If anyone can survive the arcane and chthonic land of internet sockets and return victoriously with a @-moving-around-the-screen demo that works over the internet, then you will be able to continue on the path.
That said, this game you suggest is not a single application.
It is 2 or even 3.
1: the model.
-hold the state of the world
-persists state to file system as needed
-determines outcomes of command queue
2: the server.
-provides an outside interface to the model
-asks the model for information
-sends it to the user
-recieves commands from the user
-inputs them to the models queue
3: the client.
-Connects to server.
-transmits commands.
-displays information that it is sent.
Under most systems 1&2 are (and should be) integrated. The server contains an instance of the model. The client can be implemented in any language, in fact many different clients can connect to the same server, one might be ascii based, another with sprites and tiles, and yet another renders everything in 3d.
my suggestion here is c++ for the server, as it has the highest performance you can get out of an object oriented language. The clients can be anything really, c++, C#, java, VB, python, anything that can open a socket over the internet.