Programming C, C++, Java, PHP, Ruby, Turing, VB
Computer Science Canada 
Programming C, C++, Java, PHP, Ruby, Turing, VB  

Username:   Password: 
 RegisterRegister   
 [FP] Turing - Legend of Glory: Duty Calls
Index -> CompSci.ca, Contests -> [FP] Contest 2006/2008
View previous topic Printable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic

Rating
(No ending time set)
Amazing
10%
 10%  [ 1 ]
Good
30%
 30%  [ 3 ]
Average
30%
 30%  [ 3 ]
Needs Improvement
10%
 10%  [ 1 ]
Horrible
20%
 20%  [ 2 ]
Total Votes : 10

Author Message
Jerrik




PostPosted: Sat Jun 16, 2007 9:31 pm   Post subject: [FP] Turing - Legend of Glory: Duty Calls

Our grade 12 ISU was open ended, but had to be done with a team. I was paired up with two of my good friends, but two horrible programmers (no offense guys). They assisted as much as they could, but I did most of this on my own at home.

The group idea was to make an Ariel View Network Shooter. My idea was to prove that Turing's NET commands were not as limiting as I've heard everyone claim, and that something complex could be run efficiently on the NET.

The first weekend I programmed a fully working chat server that could support upto 10 people (I never tried with more, but it should theoretically work)

I don't feel like going through everything, but what you see is 80+ hours of work. Its unfinished, and would require at least another 150+ hours to finish; at least.

The NET works perfectly, and most of my designs for it never made it in what you can download here (As I was running out of time, and as a grade 12 student, I just don't have the time to spend programming as much as I would like. Which is 16 hours a day). If you can imagine, I had thought that I had enough time to make a fully functional net game in less than a month. Something equivalent to a ZoopTek game. Lets just say, near the end I half 'arsed' everything I designed at the beginning.

The shooting system was done last minute (well, quite literally a few hours before school started). There is no collision, there is no killing each other, there isn't really much of anything. You know what works? The NET!! Thats what I wanted to do for this project and I did that, so I'm content. The map is the hosts map. It doesn't matter what maps you have, the host has his maps so you use his. And you don't even get any say to which map he chooses. When the match starts, he sends the map to the clients (other players) (Its automatic).

It was a lot of work to make it not lag for any of the clients. I have tried it with myself and three other clients, and it worked perfectly (by perfectly, I mean no lag).

IMPORTANT - To connect, you need ONE person to be the host, and the rest must connect as clients. When the host enters (straightforward once you start up the program) the clients connect on the proper ports on the Host's IP. The host can view his/her own IP in the program once the server is up, and the current port that a client will connect to. You pretty much need to be in contact with people (MSN, AIM, Phone, etc...) when they are connecting to give them your IP and PORT number. IMPORTANT: Every single client has a different port, and it is important that they each connect to a different port; in order. I wrote this part of the program at the start, and although I know away around it (even the IP bit) this is how its dealt currently. Sorry for the inconvenience. Oh, and you all need unique names. It would be simple to fix, but it causes a problem if you have the same name..In this version anyways.

After everyone is connected, you can select your map (with the mouse) and start (people can talk in the chat box by typing and then hitting enter). To start, the host has to type 'exit' without quotes, and everyone will connect be sent the map, and the match will start. Then you play (although, you can't do much). This program was a personal project to establish that Turing's net commands are far from Barbaric (even though technically it was a group project).

Commands - Map Editor
Move the map - Arrow Keys
Change the thickness of a wall - [Wall selected] + [Shift] + [Up] or [Down] Arrow Keys
Toggle between objects - [Enter]
Undo - [Ctrl] + [Z]
Redo - [Ctrl] + [Y]
Save Map (Exit Map Editor) - [Shift] + [Enter]

Commands - Start Menu
Move selection - [Up] or [Down] Arrow Keys
Choose selection - [Enter]

Commands - Option Menu
Mouse. Just click on things.

Commands - Host Menus [Start]
Move to next box - [T@b] or [Enter] (NOTE: Slight delay)
Move to any box - Click in desire box area
Select/Unselect Host/Server - Click inside box area
Enter - Hit [Enter] when selected or click on box
Clear box - [Delete]



Conclusion?

Turing's net commands are simple, but easy to use. They are not perfect, and require a lot of tinkering to work the way you want them to. Its not all built for you, and a lot of the stuff you'll want to do you either have to make yourself or forget about it. Put up, or shut up in a sense. Turing doesn't have "Pic.Send" command or anything fancy like that. You send strings, you send characters; work with it that way.

Turing's NET commands are not the fastest, but they aren't the slowest either. This program is sending a lot of information, and it does so efficiently. I never got around to implementing the 'Collision Grid' or 'Distance Mapping', which would make everything more efficient, as well as require less information to be sent AND calculated.

At first it was difficult to make the net efficient (The lag was almost two minutes in some cases, with only two players and no projectiles) but after awhile, the net becomes pretty simple. You just have to learn the nature of the NET commands and it will be a lot easier to do things efficiently (even without complex mathematics, just innovation).

This isn't the greatest program ever made (far from it), but it illustrates something important. Just because you see something as limited, doesn't mean it is. Every single person who knew anything about TURING that I talked to said what has been done here is impossible; Turing is just too slow. However, if I can program it, anyone else can. So get crackin and make a NET program for Turing so I can see your success where I have failed! (ie, a good game or program).





Music?
If you want music, simply upload it to the folder with the (menu) at the begging of the name (with the brackets). Must be .mp3 as well. I never got around to finishing the jukebox so only the menu music works when you choose music. In game doesn't work. As I said, there were a lot of things I couldn't do or finish due to lack of time.



[FP]Legend of Glory Duty Calls.zip
 Description:
Enjoy.

Download
 Filename:  [FP]Legend of Glory Duty Calls.zip
 Filesize:  1.68 MB
 Downloaded:  358 Time(s)

Sponsor
Sponsor
Sponsor
sponsor
klopyrev




PostPosted: Sun Jun 17, 2007 1:19 pm   Post subject: Re: [FP] Turing - Legend of Glory: Duty Calls

I was wondering... What exactly is a Collision Grid and what is Distance Mapping?
Jerrik




PostPosted: Sun Jun 17, 2007 2:35 pm   Post subject: Re: [FP] Turing - Legend of Glory: Duty Calls

klopyrev @ Sun Jun 17, 2007 1:19 pm wrote:
I was wondering... What exactly is a Collision Grid and what is Distance Mapping?


They are complicated to explain so I avoided it, but a basic overview;

Collision Grid: Every object goes into a 2D array (Each object can go into different elements, depends on where the object is, and its size, etc). Using the relative map position and where you are you can figure out which parts of the 2D array you are in using simple math, and then you just compare your distance to those objects normally. Its a little more complex, but thats the basics.

Distance Mapping: Almost the same thing actually, except it goes into more depth on the mathematical side to balance out size of the grid and getting collision more accurate without taxing either the CPU or the RAM very much (Making sure all the weight isn't on one or the other). Again, Its long and I don't want to get into it right now.
CodeMonkey2000




PostPosted: Wed Jun 27, 2007 3:33 pm   Post subject: RE:[FP] Turing - Legend of Glory: Duty Calls

The collision doesn't work. I don't like the controls, it's too sensitive. As for the net module, it's very solid, and fast (for turing). Great job programming it. I plan to make my game online too, it would be really slow with turing (the particle engine alone would be really slow). That's why I plan to use VBasic for my net module.
Windsurfer




PostPosted: Fri Aug 03, 2007 5:31 pm   Post subject: Re: RE:[FP] Turing - Legend of Glory: Duty Calls

CodeMonkey2000 @ Wed Jun 27, 2007 3:33 pm wrote:
The collision doesn't work. I don't like the controls, it's too sensitive. As for the net module, it's very solid, and fast (for turing). Great job programming it. I plan to make my game online too, it would be really slow with turing (the particle engine alone would be really slow). That's why I plan to use VBasic for my net module.

Wow, I haven't posted here in a long time...
I would just like to say that making programs interact with turing is VERY difficult. A lot of the programs features break when you make a turing program stand-alone.
Aziz




PostPosted: Fri Aug 03, 2007 9:59 pm   Post subject: RE:[FP] Turing - Legend of Glory: Duty Calls

Oops.

code:
*** FATAL INTERNAL ERROR in Turing Standalone Prolog ***
Date: Aug 3 2007 10:58 PM

File Name: F:\Turing\[FP]Legend of Glory Duty Calls\LOG_DC_V1\Alpha_Version.exe
Version: 4.0.4d  [11]
File Size: 877997
File Date: Jun 17 2007 1:31 AM
Operating System: Bad OS Value (0)
JVM: Ready Built-in JRE (1.4.2 or later)
"assert" Statements: disabled

The environment has experienced an unexpected internal error.

This error is caused by a bug in the environment and is not your fault!
Details about the crash have been saved in the file "F:\Turing\[FP]Legend of Glory Duty Calls\LOG_DC_V1\panic.log".

If possible, please e-mail this file to readybugs@hsa.on.ca

Here are some details about the error:
   Error = MIOFile Module Failure #101

Dir="F:\Turing\[FP]Legend of Glory Duty Calls\LOG_DC_V1", ""
Path type=10
 (15014)
   File = src\miofile.c
   Line = 410

All unsaved open files will be saved with a .sav or .sv# extension.
------------------------------------------------------
*** FATAL INTERNAL ERROR in Turing Standalone Prolog ***
Date: Aug 3 2007 10:59 PM

File Name: F:\Turing\[FP]Legend of Glory Duty Calls\LOG_DC_V1\Alpha_Version.exe
Version: 4.0.4d  [11]
File Size: 877997
File Date: Jun 17 2007 1:31 AM
Operating System: Bad OS Value (0)
JVM: Ready Built-in JRE (1.4.2 or later)
"assert" Statements: disabled

The environment has experienced an unexpected internal error.

This error is caused by a bug in the environment and is not your fault!
Details about the crash have been saved in the file "F:\Turing\[FP]Legend of Glory Duty Calls\LOG_DC_V1\panic.log".

If possible, please e-mail this file to readybugs@hsa.on.ca

Here are some details about the error:
   Error = MIOFile Module Failure #101

Dir="F:\Turing\[FP]Legend of Glory Duty Calls\LOG_DC_V1", ""
Path type=10
 (15014)
   File = src\miofile.c
   Line = 410

All unsaved open files will be saved with a .sav or .sv# extension.
------------------------------------------------------
cpu_hacker4.0




PostPosted: Fri Oct 19, 2007 8:14 pm   Post subject: Re: [FP] Turing - Legend of Glory: Duty Calls

I got the same error.
Display posts from previous:   
   Index -> CompSci.ca, Contests -> [FP] Contest 2006/2008
View previous topic Tell A FriendPrintable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic

Page 1 of 1  [ 7 Posts ]
Jump to:   


Style:  
Search: