Guys I am not a good C programmer. I ahve experience with object oriented paradigms such as Java and C# but I never programmed in C or Pascal. I have done some tutorials in C and I seem to grasp some of the ideas of the language but as I learned it is a very messy language. Now my problem is that I am trying to develope for my assignment a Multiplayer Snake which has to run on Unix OSs and I can't use sockets also I don't need some graphics I can use just text graphics to do everything. I am currently trying to design the systems but I am having some problems on how to create one process which when run from me and another user is going to access common memory location (which is the map) and then modify it. I have read and searched alot in google but nothing really helpful. so if someone can give an insight with this I will be happy. I ahve no code yet since I am designing but once I am clear I will start coding. Thanks again for any help.
tutorials in C and I seem to grasp some of the ideas of the language but as I learned it is a very messy language.
C is a very well-defined and highly structured language, probably one of the most structured languages you'll find. there's nothing messy about it. Perhaps your tutorial writers are sloppy programmers.
Now my problem is that I am trying to develop [a lot of stuff] so if someone can give an insight with this I will be happy.
bite-sized pieces, grasshopper. do not try and build Rome in one day.
first write your program so that you can just have a single player move your snake around the map.
then once you get that working, have a second player added in a single thread where you take turns, so you can get an idea of how scoring will work and determining a winner.
then use multithreading and put the common components (map, etc) in a shared unix directory.
I ahve no code yet since I am designing but once I am clear I will start coding. Thanks again for any help.
and i have no more help yet since you are not coding, but once you are coding i will start helping. for now, here's a starting point.
// include files here
#include <stdio.h>
#include <stdlib.h>
// define statements and macros here
// global variables here
// function prototypes here
int main (void)
{
// local variables here
// begin main code ...
// ...end main code
return 0;
}
// additional functions defined below.
Thanks for the help. As a grasshoper I want to say that I am currently trying to make the snake as single player though I made the map but I am not sure if I have to allocate it somewhere since i only create it in runtime and use a variable for it that will be constantly updating. I don't need scorring or anything else just a moveing snake and another moving snake since the aim of the assignment is the multiplayer part. I also have to mention if I didn't mention that the game is running on a surver so i am connecting myself using Putty and a friend of mine is using putty once we are on the machine we need to run the same process and play with the keyboard of each other not multiplayer on one keyboard. And I think that requres some additional knoledge of unix architecture and system calls that I don't know from where to aquite. Thanks
As a grasshoper
Man... grasshopper is a development strategy, not a personal epithet. It means "one jump at a time".
I don't need scorring or anything else just a moveing snake and another moving snake since the aim of the assignment is the multiplayer part.
Forget the snake. Start simple. Create a server, which holds a state variable. Create clients which may query it and alter it. Make sure that altering by one client is correctly reflected on all of them. Try to break it (i mean, try really hard). When you are convinced beyond a reasonable doubt that the server withstands all possible abuses, proceed further (TBD at this moment).
This is a grasshopper.
And I think that requres some additional knoledge of unix architecture and system calls
True.
that I don't know from where to aquite. Thanks
Here's a good place. Just ask you questions.
"grasshopper" also means the student
I have to admit I didn't watch Kung Fu (I am not a kung fu adept either, I am rather into a shotokan). That said, i didn't find anything in this article which would support the claim.
@nezachem : nobody cares which martial arts you claim to study. "grasshopper" is a frequent term applied to a new learner in any subject. thats it. if you dont understand english language colloquialisms, move along and don't waste time requiring someone to explain trivial shit.
as for this piece of "advice"
Start simple. Create a server, which holds a [blah blah blah ... snip]
do you really think that someone who cant even begin coding on a simple game program partly because they don't understand the common architecture of their unix system, is going to build a server? he cant use sockets anyhow.
@iliali : look, 90% of this becomes relatively simple, if you back up and quit trying to look at this a whole problem. look at it as a series of little problems.
you need to do the following one step at a time.
(1) build an array to hold a map
(2) build structure(s) to define elements of what that map contains.
(3) define an interface to "move" a "piece" around on that map,
(4) keep track of where the piece is in your structure
(5) ensure that your "piece" cant move illegally based on locations of other objects.
move through this incrementally. build a little bit, test it. Build a little bit more, test it. integrate these two things, test it. and so on.
(6) then you add in a second player, and modify your game to alternate players to move their piece(s), and sort out the rules for interactions between players and how they score event, and how to determine a winner.
(7) thenthen you remove the second player and build two applications that each will interact from different locations and will modify the common elements (map array, piece and environment structures) which are held in a shared directory. this is the part that seems to you to be the hardest part right now, but once youve worked on 1-6, this part will become almost a non-issue.
so, this problem youre stressing on, of how to share a common unix loacation, doesn't even need to be addressed until the 7th step. it's actually pretty simple and you shouldnt even be worried about it since you've got a LOT of work to do before it even becomes relevant.
But I'll try to explain it for you. Since each player (eventually) will be operating their own client program that modifies the map and other state variables from a common location, you need to set up a common directory. i dont know what your system looks like, but there are a few commands that set permissions to a shared directory.
"chown" changes ownership of a file or directory, and "chmod" changes the mode of the file or directory. do a "man chown" or "man chmod" to get an idea what this means. i can tell you that "chmod 777 <mydirectory>" will give *everybody* on your entire system access to the <mydirectory> location, but that probably is not what you want. you probably want to set up a "group" for people who will interact to protect it somewhat from nosy strangers.
in any event, if you're having this much difficulty wiht your computing environment, you need to seek help from someone at your institution who can show you directly. there must be some computing system resource for you somewhere at your school.
I'm quite sure that floundering about with unix directory commands is not the point of your project, and you're only wasting your time stressing on it, when the majority of the C-programming work that you could be doing right now has nothing to do with sharing directories in the environment you're working in.
.
I made the map ... in runtime and use a variable for it that will be constantly updating.
I don't need scorring or anything else just a moveing snake and another moving snake since the aim of the assignment is the multiplayer part.
I also have to mention if I didn't mention that the game is running on a surver so i am connecting myself using Putty and a friend of mine is using putty once we are on the machine we need to run the same process and play with the keyboard of each other not multiplayer on one keyboard.
And I think that requres some additional knoledge of unix architecture and system calls that I don't know from where to aquite. Thanks
okay, this is actually even simpler than i originally thought. you can skip step #6, above, since as you say there's really no additional work for interacting or scoring or anything.
you use PuTTY to access your unix account. it's just a remote terminal. you could be onsite and use a terminal at a workstation. the point is that you'll be running a console application in a terminal, and whether its via PuTTY or directly, its all the same.
One thing i wasnt clear about is that you keep (store) the map array and related state information as a FILE (like a binary .bin or .dat file) in a common location. not in the memory of the program. all the program will do is display this information appropriately in the terminal of the players.
the console application for each player will access this binary file with reads and writes.
either player can access it at any time for a read. you could have a player's application read it once per second and refresh the terminal accordingly.
but only one person can access the file at a time to perform a write (update). therefore you will have to LOCK the file when writing, then UNLOCK it when you're done. so, you'll want to make the writes as quick as possible that you dont hang it up for the other player.
manually set up the common directory using the unix command 'chmod' ahead of time so you both can access and modify the files.
the rest of this is just standard C.
.
Thanks very much as I was thinking about it I reached the same conclusions and your tips are very good. Thanks agian! I will start coding on Monday and if I have any other questions I will let you know. Your advices help alot. I have read abit for the locking and unclocking and I think these are the best to use in my situation. I am sure that if I reach step 5 onwords I should be able to figure it out. Thanks again and I will come back if something turns out to be difficult. Thanks
okay, good luck.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.