C++ Workshop - Project 2

Jeromy Walsh · 2008-05-10T06:12:16

Project 2 – Overview Welcome all to the second project of the C++ Workshop. Continuing with the theme of the first project, we will move along in our journey towards making an RPG similar in style to Dungeons & Dragons. In the first project you created characters, gave them ability scores, and had them fight 1 on 1 in an arena environment. However, RPG’s are much more than combat. They’re also about exploration and discovery, and there’s not much to discover in an arena. So in this project we will be breaking out of the arena. Project 2 – Introduction In graphical video games, as in life, what you can see is only limited by your range of vision and your field of view. Although you may not realize it, your eyes take in vast amounts of information in a microsecond, allowing your brain to identify objects, determine the presence of danger, and to become aware of the weather, atmosphere, and mood – for as far as the eye can see. In pen & paper RPG’s, as in text RPG’s, your awareness is much more restricted. If I (or the Dungeon Master) were to try and describe to you everything the eye could see in one sitting, we’d be reading paragraph after paragraph for days, and you’d never get an opportunity to actually DO something. To make the transition from visual to text environments easier, the world is often broken up into smaller, more manageable chunks called rooms. “Imagine you’re standing on a small hill in an open, circular field of dark green grass. The field stretches in all directions and extends almost as far as you can see. At the edge of the field is a forest, which surrounds you on all sides. You notice that to the north the forest has a small opening, and to the south you hear the sound of flowing water. The wind is cool, the air is dry, and the sky is blue and bright above you.” The above is an example of a description which might be read in a “room.” You’ll notice that in the example, its not really a room at all. In fact, it’s not even inside, but outside in an open field. The reason its referred to as a “room” has more to do with the subdivision of the world and the existence of exits, than with the fact that it emulates an actual physical room. When I say the room has “exits,” I mean that there are paths to follow, directions to head, ways in which you can get from this “room” to the next “room.” In the description above, there are two logical exists, north, and south. If the user were to exit either north or south, they would leave the current room and enter one of the adjoining rooms. So if the example “room” above was an entire field, how big is a room normally? Well, a room is as small as possible, in order to contain all relevant information. You notice in the room above that there was very little content. An open field, trees, and a bit of weather. There were no buildings, obstacles, people, objects, or even distinguishable landscape, other than the hill you were on. So it was quite feasible to absorb all of that information in a single paragraph. Now, imagine trying to describe the entire city of New York. It would be impossible to do in a single paragraph and be able to effectively communicate to the user the weather, the people, dangers, and all the shops and stores that would be possible to explore. It goes without saying that you’d more likely divide the city up into city blocks, with each block being described in a single “room.” Or better yet, imagine you’re inside of a medieval castle. The castle itself is smaller than a New York city block, and definitely smaller than a field as large as the eye can see, but yet, you’d still likely subdivide the castle into dozens of rooms representing the actual rooms and hallways of the castle, because that’s all the eye can see. As well, the zoomed in level of detail necessary to see the books on the shelves, the paintings on the walls, and the furniture in the room requires a much smaller subdivision. Which leads me to the next topic. As you’re exploring a medieval castle or dungeon, you’ll often see things lying around. Things such as furniture, armor, weapons, treasure chests, and even piles or coffers of money. Sometimes these things are merely part of the description – such as the furniture. Other times, however, you need to be able to pick up and interact with the object – such as the weapons, armor, or coffers. These require physical objects which you can take, examine, and put in your inventory. Once in your inventory, you want to be able to open it, equip it, or drop it. This implies that you have an inventory, perhaps a backpack, which, much like the room you’re standing in, is a container for other objects. And finally, different types of rooms allow you to do different things. For example, a room in your house might perhaps just have a bed which allows you to “sleep.” While a room in a bank might allow you to “check” your balance, “deposit” some money, or even “withdraw” some money. Another example might be a shop, which allows you to “List” the inventory, “Purchase”, an item, or even “Sell” something from your inventory. Project 2 – Conceptualization This program is a continuation of the program created in project 1. It will again consist of various menus and submenus, however the menus and submenus will now be different depending upon which room you’re in. The primary functionality will be the ability to move in an out and explore different rooms. Each room will have its own description, exits, and contents – which includes objects and other characters. While in a room you will be able to interact with objects, pick up equipment and put it in your inventory, and fight against the other characters which are in the rooms, much as you did in the arena. If you defeat a character, you may then loot his body in order to take any equipment or coins he may have had on him. Some characters will be non-hostile, meaning that they do not attack you when you enter the same room with them, however some of them WILL BE hostile, and will engage you as soon as you enter, so be prepared. As with before, you may create a character, view your stats, and gain experience and level as before. You no longer automatically gain coins for defeating a character (but you can loot their corpses), and you no longer purchase armor and weapons via the main menu. Now, your character begins with a basic, level 1 set of gear and you must enter weapon, armor, and potion shops in order to purchase new equipment. If you should die while fighting in combat, your body is left on the ground where you fell, and you return to the starting room where you began with a new body. All coins are taken by the character that defeated you (and can later be regained by defeating them), but your equipment is left on your body. To prevent losing all of your coins when defeated in combat, it would be wise to store some of it in a bank while exploring. You can reclaim the items by returning to your body and entering your corpse. Project 2 – General Analysis Use Cases 1. Entering The Game When the user first executes the program they will be shown a main menu similar to that displayed below. When the user makes a choice the screen will be cleared and the user will be shown a new menu or screen depending upon which choice was made. It is important to note that “Enter World” will only be shown if a character has been created. If not, “Create Character” is the only option available. ============================== Main Menu ============================== Menu Options: a. Create Character b. Enter World Q. Quit ============================== Choice: 2. Creating a Character When the user selects the option to create a character they will be shown a menu similar to that shown below. If the user selects “Name Character” they will receive a prompt allowing them to enter a name for the character. If the user selects roll for stats, then he will enter a loop where he can continue to “roll for stats” until he finds a suitable distribution. Returning to the previous menu clears the screen and then once again shows the main menu. 2a. If the user has already created a character by previously entering this submenu then entering the “Create Character” menu additional times should first prompt the user that they have already created a character, and that continuing will result in the removal of the old character to make room for the new. If the user opts to continue to “Create a Character” then the menu below is shown. If they decide NOT to create a new character, they will simply be returned to the main menu and their previously created character will remain. ============================== Create Character ============================== Menu Options: a. Name Character b. Roll for Stats R. Return to previous menu ============================== Choice: 3. Entering the World After the user selects “Enter World” they should be taken to a starting room. This can be any room you like, however it should always be consistent, and should be safe from opposing characters or monsters. Typical choices are a Church/Cathedral, a Town Hall, or an upstairs bedroom in an Inn. When the character is transferred to the starting room is should be treated as entering any room. See Below. 4. Entering a Room When a player enters a room they should be shown a screen similar to that listed below. It should show the title of the room, the long description, the exits, and any objects or characters in the room. After all of those have been shown, a menu will appear which lists the available choices. The menu should be dynamically, with directions for exits, “Examine objects” if there are any objects in the room, “Attack” if there are any other characters in the room, and any shopping or banking options as will be discussed later. Additionally, the “Character” option should be available in all rooms. ============================== The Grassy Hill ============================== You’re standing on a small hill in an open, circular field of dark green grass. The field stretches in all directions and extends almost as far as you can see. At the edge of the field is a forest, which surrounds you on all sides. You notice that to the north the forest has a small opening, and to the south you hear the sound of flowing water. The wind is cool, the air is dry, and the sky is blue and bright above you. Obvious Exits: North, South A small tombstone A broadsword ============================== Menu Options: n. North s. South x. Examine Objects c. Character q. Quit ============================== Choice: 5. Using Exits Using an exit simply transports the user from one room to the appropriate connected room. The screen is cleared and they are shown a new screen appropriate for entering the new room. 6. The Character Screen Whenever the user selects the “Character” screen are they choosing to view the information about their character. The screen should be cleared and they should be shown the View Stats menu from project 1. Additionally, the screen should contain 3 new options – V. View Inventory, E. Equip Items, and R. Return. Selecting either of the first 2 will show them a submenu, select R will return them to the view of the room. 6a. Viewing inventory simply gives the user a numbered list of all items their character is currently holding in their bag. From the Inventory screen the user may select any of the items by number which then prompts the user if they’d like to drop the item. Selecting yes drops the item, selecting no returns the user to the Inventory Menu. Additionally, the user may select ‘r’ for return to character screen. 6b. When the user opts to Equip Items, they should be shown what’s currently equipped (armor & weapons) and they should be shown a numbered list of all items in their inventory which can be equipped. Selecting one of those numbers swaps the item currently equipped with the item they selected. The last 2 numbers should be reserved for “remove weapon” and “remove armor,” just in case they want to remove it without first equipping something else. 7. Examining Objects When the user views a room they are shown a list of items in the room and are also given a menu option to “Examine Objects.” If the user selects that option they are taken to a sub-menu which again lists the items in the room, this time numbered. Selecting a number prints the description of the corresponding object, and also gives the user the option to view contents if the item is a container. Additionally, while viewing the object’s description the user may opt to “take” objects which are equip-able, such as weapons and armor, or small enough to carry such as potions or coins. If the object is a container and the user selects to view its contents, they are shown a sub-menu identical to that shown to “examine objects” with all items within the container numbered, etc…This system of objects within objects, and a menu with numbers to examine and then take objects is recursive, and works until all objects within objects have been examined. 8. Attacking Mobs If the room the user is currently in has other characters (non-hostile) they are shown a menu option called “Attack.” Selecting that item will list the characters in the room so the user may decide which character/monster they would like to attack. Once that has been done, combat begins similar to the way in which it was done in project 1, with one small change. 8a. After each round of combat (after both characters have attacked/defended), the user will be shown their hit points and a menu. The menu will contain three options – Attack, Use Item, and Run! Selecting Attack will cause combat to progress for another round. Selecting “Use Item” will show the user a list of items in his inventory which are “Consumable,” such as potions. Selecting one of those items will cause the user to drink the potion, and then continue with the current round of combat. Drinking a potion counts as the user’s turn for that round, so they will not get an opportunity to attack, but they WILL be attacked. Selecting “Run” will usher the character out of the room, in a random direction. (hope they don’t run into a room with a hostile mob). 8b. Attacking a mob and then running flags that mob as hostile. The next time you enter the room, the enemy will continue their attack, however you automatically gain the initiative and get the first swing. 9. Hostile Mobs Whenever you enter a room with 1 or more hostile characters, you are shown the description, the obvious exits, and the objects in the room just as before, however combat immediately begins just as though the player had chosen a character to attack, however without clearing the screen, If there are more than one hostile characters, use initiative or a random chance to determine which attacks first. The first time you enter a new room which contains hostiles they automatically gain the initiative. Every time after that, however, the player gains the initiative. 10. Dying If the player is killed in combat they “die.” Their body is left in the room as an object and their spirit is moved back to the starting room. While a “ghost” the player may only move between rooms and examine objects. They cannot view their stats, open objects, or engage other characters, either hostile or non-hostile. Additionally they cannot shop or bank. Upon returning to the room where they were killed they are given an additional menu option to “Enter Body.” Doing this brings them back to life, with 10% of their full health. If they were killed by a character which was originally “non-hostile” then the character does not attack. If the character was flagged as “hostile” then they will immediately attack once again. As the player has obviously been in this room before, they get the initiative automatically. (Take this as an opportunity to flee.) 10a. When an enemy kills you, they take all of your coins. You may regain those coins upon defeating them, and then examining and opening the corpse. 11. Banks Banks are special rooms which follow all of the rules above, with the addition of a few new menu choices. In a bank you gain the ability to “Check Balance”, “Deposit”, and “Withdraw.” Selecting “Check balance” prints the amount of money you have in the bank, and then reprints the menu “choice” prompt, without clearing the screen. Selecting either Deposit or Withdraw takes you to a suitable sub-menu, where you are shown the amount you can deposit or withdraw, and then a prompt asking you for how much you’d like to deposit or withdraw, respectively. From any of these menus you may “return” to the bank by using the “Return” menu option. 12. Shops Shops are special rooms which follow all of the rules above, with the addition of a few new menu choices. In a shop you may “List” the items for sale, or you may “Sell” something of your own. Selecting “List” displays a numbered list of items for sale, with the amount and attributes of the items identical to the system used in Project 1. Selecting “Sell” will show you all the items in your inventory, along with the prices being offered by the shop. By default, sell prices are 1 / 4 the purchase price. Project 2 – Conclusion By the time this project is over you should be able to create a character, move around in the world, and either collect objects or engage other characters in combat. This is no small project and I very much look forward to seeing what the members of this workshop can come up with. I’ve made every effort to make the analysis thorough enough that you should be able to come up with a pretty accurate design. However, its always difficult to describe a task to someone when you already have the design and implementation in mind. If there’s anything I was overly vague on, or left too much to doubt, please feel free to ask in this thread. Additionally, please feel free to post any design or implementation questions you have. You may notice that in some places, such as the costs of items, what items there are, and what potions exist that I have not specified anything. This was intentional. Use your imagination. As well, this project description should be viewed as a guideline for testing your skills. It should be treated as a minimum specification. If there’s other things you’d like to add, ideas you have of making the project more enjoyable or interesting, please feel free to post those ideas here on the forum and implement unique features as you see fit. Cheers and good luck!

CPP Workshop Workshops

Started by JWalsh September 27, 2006 04:56 PM

94 comments, last by Warlord_Shaun 16 years, 9 months ago

westond

122

October 06, 2006 12:51 AM

Quote:
Original post by Zahlman
That's not a reason, and to be honest you're making less and less sense. Please, I'm trying to make this easier for you. Why resist that?

Please dont take me the wrong way. Im not resisting you in anyway, infact im incredibly gracious for your help. You have to be patient with me as this is my first real programing language and ive only been at this since a few weeks before project 1 was assigned. I know what I want to do, but unfortunately I dont know how to convey it.

If you look at how I did the menu system in my first project, you might get a sense at how im approaching this. clickie

The idea is for my menu system to dynamically build itself based on the users location in the world. Each location is its own object stored in a multi array. There will be menu object pointers belonging to each object that will be used to create a custom menu based on where the user is. This idea will also be ported over to the item/container system.

That being said, im still working on concepts before I can start coding for project 2. The largest concept being vectors and reading/writing from/to a file.

After your posts I went back and cleaned up the code and came close to what I want...

#include <fstream>#include <string>#include <vector>#include "object.h"#include <iostream>using namespace std;int main(){    vector <Object*> Objv;	ifstream fin("test.csv"); // open the file	std::string objtext;	int objid;     	  	  	  while (fin>>ws && getline(fin,objtext,',') && fin>>objid)	  {	    Object *newobj=new Object(objtext,objid);	    Objv.push_back(newobj);	 	 	  } // end end of line while	  fin.close();	std::string word;	int id;	int size=Objv.size();	for (int i=0; i<size; i++)	{	word=Objv->Getchar();	id=Objv->Getid();	cout << "Its word: " << word << " and its id: " << id << endl;	}	for(int i=0; i<size; i++)	{	 delete Objv;	}    char ch;	cin >> ch; //just a stop break before exiting console		return 0;}

This works and compiles fine... but I want a pointer to the Objv vector. I tried this below, but the word=Objv->Getchar() and Getid() break and want a "." instead.

vector <Object*> *Objv;Objv=new vector <Object*>;

Also, cin and cout will not work unless i #include <iostream>... but I thought iostream was included in fstream. What did I miss there? Even dropped the using namespace and tried std::cin..etc

RinusMaximus

122

October 06, 2006 02:27 AM

Quote:
Original post by jwalsh
Quote:
I was thinking about using a more readible format, either XML or some pseudo class declarations, and build some kind of parser to instantiate objects for this. Or maybe instantiate my objects with DOM nodes which contain their starting values.

I am very much in favor of XML as a language to use for your data files. Its organized, easy to read, and is used in many standard and commercial engines for things such as Web Applications all the way to World of Warcraft Interface files.

How you parse/load the XML is up to you, but I can assure you, design such as this for the rooms, objects, and perhaps even NPC's will make a huge difference in your ability to create interesting rooms and objects. The easier it is to create the world, the more likely you are to do so. As well, the less times it takes a "world designer" to create your world, the more time they'd have to think up unique features.

Cheers!

Which are the most common used XML parsers? I'm guessing there must be a lot of open source XML parsers around, so I don't have to invent the wheel again.

Although writing an XML parser can be fun...

Deyja

920

October 06, 2006 05:12 AM

TinyXML is a fairly common choice.

http://jemgine.omnisu.com

Zahlman

1,682

October 06, 2006 05:52 PM

Quote:
Original post by westond
I know what I want to do, but unfortunately I dont know how to convey it.

That much is normal. [smile]

Quote:
This works and compiles fine... but I want a pointer to the Objv vector.

See, the resistance that I perceive is in terms of "wanting" something that I can tell you (from my years of experience) is more complex and doesn't accomplish anything extra. :

Quote:
I tried this below, but the word=Objv[i]->Getchar() and Getid() break and want a "." instead.

*** Source Snippet Removed ***

Currently, you index into the vector, yielding an Object*; then you can use -> to dereference the Object* to get an Object, and select its Getchar() member function.

If you have a pointer to the vector, then 'Objv[i]' is no longer indexing into the vector, but instead operating upon the pointer - i.e. assuming you have an array of some kind (in particular, an array of vectors). That selects a vector, so you can't use -gt;Getchar() at that point - first off because that tries to do a dereference (and you don't have a pointer), and secondly because the *vector* doesn't have a Getchar(). Although the compiler is generally very smart about the code that it writes when it gets a correct program, it's usually very dumb about how it reports errors - it basically reads one "token" at a time and reports the error as soon as it knows there is one, using only the information it has so far (even if the very next token could give it a much better understanding of what you're really trying to do). That's why it tells you it wants a '.': the only thing it sees for the time being is a -> applied to a non-pointer.

What you would need to do is dereference the pointer first (to get the vector) and *then* index in. That looks like (*Objv)[i]->Getchar().

... You see? More complicated, and it won't work any better: the whole point of using the vector in the first place is to let *it* manage the dynamic allocation.

Quote:
Also, cin and cout will not work unless i #include <iostream>... but I thought iostream was included in fstream. What did I miss there? Even dropped the using namespace and tried std::cin..etc

It is not (necessarily - it could on someone else's implementation, because the person putting that implementation together found it made his/her life easier to do so, but you should not rely on that), because cin and cout aren't file streams - they're console streams. :)

popcorn

151

October 10, 2006 08:53 PM

Having finished the first project I am tempted to have a go at the second project however this seems to be a much more tricky project than I imagined.

I have to say reading through some of the replies concerning how to handle inventory items was quite interesting but I am not sure I can comprehend some of the more difficult concepts suggested like visitor patterns and using opaque pointers. Are these concepts covered in the book being used(I don't have the book in question). The way I thought about the inventory was to do something like adding:

vector<Weapon> wInventory;
vector<Armor> aInventory;
vector<Items> iInventory;

in the character class. I'm not sure if I should try attempting some of the ideas suggested or just use the above. It does seem crude in comparison to the various ideas suggested but much more comprehendable to me.

Anyway how are other people finding the project?
Being honest I'm finding it difficult just to start.

How about them apples?

westond

122

October 11, 2006 02:33 AM

DOUBLE POST FTW!!!!

Sorry about that ev1.

westond

122

October 11, 2006 02:38 AM

jwalsh has proly said it best, dont let what you dont know keep you from attempting these projects. Just do it the best way you know how... even if it isnt very elegant or proper coding. We are all learning here, and noone expects us to be on par with a coder that has a degree in CS and several years of experiance. We are bound to do it wrong despite our best efforts. The point of the projects is to make us think about a goal within the context of what we know. The more we use what we know, then the easier it is to pick up on those new and more difficult aspects of C++. Dont let anything hold you back... just go for it. And if anyone here says otherwise, they ought not be here.

Quote:
Original post by popcorn
Having finished the first project I am tempted to have a go at the second project however this seems to be a much more tricky project than I imagined.

I have to say reading through some of the replies concerning how to handle inventory items was quite interesting but I am not sure I can comprehend some of the more difficult concepts suggested like visitor patterns and using opaque pointers. Are these concepts covered in the book being used(I don't have the book in question). The way I thought about the inventory was to do something like adding:

vector<Weapon> wInventory;
vector<Armor> aInventory;
vector<Items> iInventory;

in the character class. I'm not sure if I should try attempting some of the ideas suggested or just use the above. It does seem crude in comparison to the various ideas suggested but much more comprehendable to me.

Anyway how are other people finding the project?
Being honest I'm finding it difficult just to start.

As far as starting the project. I would suggest putting pen to paper first. I designed the world on paper as far as each cell the player could interact with. This then showed me what direction the character could move when in anyone cell. This also lead me to create multiple levels/zones to the world in which the character could move. It also inspired me to come up with a structrue of how character, item, and the world would interact. By the time I was finished drawing out my world I had a pretty good idea of to attack the code. Ill scan my drawings here so you can see what I did.

Here is the link to a pdf. My paper was much larger than the scanner bed, but you get enough to get the idea clickie

popcorn

151

October 12, 2006 06:35 PM

Quote:
Original post by westond

jwalsh has proly said it best, dont let what you dont know keep you from attempting these projects. Just do it the best way you know how... even if it isnt very elegant or proper coding. We are all learning here, and noone expects us to be on par with a coder that has a degree in CS and several years of experiance. We are bound to do it wrong despite our best efforts. The point of the projects is to make us think about a goal within the context of what we know. The more we use what we know, then the easier it is to pick up on those new and more difficult aspects of C++. Dont let anything hold you back... just go for it. And if anyone here says otherwise, they ought not be here.

I realise that westond, I will try to continue regardless even if my code does look messy but I also want to try out some of the techniques suggested by some people - it is a project designed to help you learn more after all. I feel quite interested by the idea of handle classes and I would like to try to implement this for the items class.

I'm not quite sure I understand this yet though so I may resort to something simpler but I would like to ask if you create an item class and derive a weapon and armor class from it - how would you create the handle class for this - does the interface for the handle class have to provide all the member functions that the item class as well as the derived classes have?

How about them apples?

westond

122

October 13, 2006 01:02 AM

Quote:
Original post by popcorn
I'm not quite sure I understand this yet though so I may resort to something simpler but I would like to ask if you create an item class and derive a weapon and armor class from it - how would you create the handle class for this - does the interface for the handle class have to provide all the member functions that the item class as well as the derived classes have?

Only if you derive the handle class from the the weapon or armor class. Then yes it will include all the methods of the Item and Weapon/Armor classes. You can hide methods in the Weapon/Armor classes by declaring those methods private. Your Handle class would not see or be able to use those methods then. Same goes for the Item class, but those methods would not only be hidden from the Handle class but from the Weapon/Armor classes aswell.

I think that a handle class would be unecesary. Once you derive a weapon and armor class from an item class then you can treat those objects created as generic items that can be held in a container of <Items> to be found or carried as in a backpack. Then to invoke "use or handle" simply add the wanted item to a container of <Weapon> or <Armor> in a character class object. The Weapon and Armor Classes will have all of the methods defined in the base class <Item> available to them. Add the method of use to the Weapon and Armor Classes directly. That is, if the only time the weapon and armor mods will be available is during combat... that way all you have to do is call those methods in your combat resolving code when you need the stats to apply.

You can take this further... say you wanted to loot weapons and armor off of an enemy player. You can create a method that upon death the weapon and armor objects would be moved to an inspectable <Item> container in the enemy character object. Upon looting move that object to the player's <Item> container.

Things like potions that are usable would work the same way. They would have all the methods defined in the base Item class, but their methods of use would be defined directly in the Potions class. Just like Weapons and Armor, they could be stored in a container of <Item> to be used. To distinguish wether or not something is useable...a potion is usable out of the backpack, where Weapons and Armor have to be equiped, just place a bool isuseable=(true/false) in your base item class.

westond

122

October 13, 2006 01:14 AM

Im thinking of trying to compress my classes a bit by hashing some of my ID variables.

I have a set of variables that give an individual game cell a location in the game world...

int zone_id
int zone_y
int zone_x

each zone id can be broken down into a description of the area of the world its in as well as being the declaration of the array the cells are held in.

zone_id=1001 World zone 1 sub zone 1
zone_id=1101 World zone 1 town zone 1 subzone 1
etc...

the position is array1001<zone_y,zone_x>

what I would like to do is create a cell id that combines all this info
ex.
zone_id=1001
zone_y=2
zone_x=1

long cell_id=100121

but i need a way of breaking that up when I need zone_id, zone_y, and zone_x.

I've looked, but cant find anything that will just read the first 4 digits of cell_id and assign it to zone_id and the 5th digit to zone_y and so on. Im sure there is an easy way of doing this that doesnt involve character arrays and casting. Or am I mistaken?

C++ Workshop - Project 2

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

C++ Workshop - Project 2

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines