Because I know some of you are curious about what I am working on in this class I'll post pictures of what I've completed as I move along with the class. Please read the notes section before thinking about leaving a comment.
Notes:
In my class we only use the really noob language known as Turing. It in no way even matches any industry standards, but it has some of the same problem solving skills and thinking processes as other languages require. Therefore our teacher like using it over other stuff. This isn't a bad idea since most people can't seem to figure half of the stuff out using Turing. Makes me wonder how well they would do with some of the more 'complex' languages.
Anyways it is not as amazing looking as flash and java stuff and it is a lot more Anglicized then other languages. Some of you who code will notice the near English syntax of the language and will probably laugh at how simple it is.
Now with all of that out of the way here it is.
Okay so here is what the almost finished coded version looks like as an output screen.
Yes I am aware that looks completely terrible, but it is 'function' code over 'pretty' code. I usually run 2 different sets of code for projects of this magnitude. One has function code, while the other has graphics. In this case I actually needed a third file just to keep everything organized.
The graphics file outputs the following. And this one was not edited to a smaller size. Photobucket's monthly bandwidth restrictions have me worried since these full image files are a lot larger than my art...
Now I can't help that the image quality is kinda bad, but aside from the odd off place pixel that is what it looks like (who knew a computer could butcher an image with the printscreen command.)
Anyways you will see what looks like a games table with 6 die facing up on it. Those die are the beginning for creating the die sprites. They are just 6 of several images. Also you will notice a command prompt for the user to bet. That will reappear and disappear when need be during the actual run time. The poker chip at the bottom next to the 2 arrow buttons is the amount bet. I still need to throw in an amount bet beside it. The chip at the top is going to be made smaller and turned into a "current total" so the user knows how much they have left to bet.
Finally we have the sprites file. It is a sheet of images that are played one after another to create the illusion of animation. Looks like the following.
I put numbers above each picture (using paint), so you can see what order they are in. Those 16 sprites are needed to do a single dice roll that ends on 1. Micro pictures of what that looks like are as follows.
Those are just a few of the images, but they are all aligned at the same point as you can see the shadow from the table is consistent in all of them. It looks a lot better than the pictures show, but this gives you a bit of an idea. Also, the die animation goes through the above 16 sprites 4 times completely (64images in total).
Okay. Time to finish up this journal entree now that I am 100% done this task for school.
As I was programming the game I found various problems. The sprite screen above was one of them. One sprite screen didn't show at the beginning of a program, but once I finished all 6 there was a massive lag in the load and it looked terrible to load the program. So I needed to come up with a solution for this problem. This was my solution:
As you can see I've got a die facing up and 3 transition images with the words loading in the middle. This makes the program look like it is loading when it is drawing up the pictures in a neat and organized fashion. This not only looks like a professionally done loading screen, but it is actually loading something. It was a rather cleaver solution in my opinion and it has worked very well.
Now so far you've only seen the black and white version of the program. The rest of the pictures in here show the finished program in operation. I believe you will find them to be...better than that ugly black and white thing.
I created this title screen so I could have a way for players to see instructions inside of the program. It also makes the program seem a little more professional and it acts as a good buffer between the not so colourful loading screen and the very colourful game screen.
Once you enter the game you get the following screen. This screen asks you to place a bet. The arrow buttons actually change the bet when they are clicked. They also lower the total found at the top of the screen. The game starts users off with 10 chips, but you'll only see 9 if you look at the total. This is because the minimum bet is 1, so to avoid problems (and to avoid needing another cover and prompt) I forced users to always start off with 1 chip. The max bet is also 5. Due to the nature of the program the only way I could make the bets appear as big numbers was to have them all predefined. This meant that I had to tell the program to put X1, X2, X3, etc when the user raises or lowers their bet.
Once you've placed your bet the program will play the first dice rolling animation. Surprisingly I was the only person in my class to do an animation that contained multiple frames, so in essence I was the only one to do true animation. This kinda astonished the class. Was definitely the crown jewel of my program.
As you can see the graphical quality of the program is the same as the program where I designed most of the graphics. It really wasn't hard to integrate them, but because it took me almost a month to do all of this I can't remember exactly what I did when I was integrating it all. Plus it is kinda hard to find the code when it is buried in almost 4000 lines of code rofl Oh, the program is 4000 lines of code because it produces all of the graphics internally. If the graphics were externally created and imported the files size of the program (overall) would be nearly 5 times what it currently is if not more. The program is only 122 kilobytes big, which is shrimpy compared to many of my classmates whom used external images.
The winning screen looks like this and the losing screen is beside it. Not overly complicated. Just some simple math.
Double or nothing was a neat feature where I forced the user to place down their previous winnings as a bet. If they won they got double if they lost they got nothing. It is basically the same as a normal game, but it has a bit of a twist that can allow you to win tokens faster. I also set it so that users can only play it once per regular round won.
I think I've showed off most of the program by now, but here are 2 final screens. This is the screen that shows up when you quit. Had I more time to work on this project a highscore screen would have come before it.
This screen is my somewhat amusing gameover screen. I thought it was funny to put a skull in place of an O in the screen. It made me laugh while I was typing in the code for the skull.
So that is all I have to show you with regards to my final project for programming. If you would like to leave any comments you may, but if you are just going to rip on the program don't bother. I challenge anyone who wants to rip on the program to make a better game in under a month. Unless you are a computer science student or you haven't got a job and therefore have extremely large amounts of free time on your hands you probably can't do it. And just so you all know I typed the coding for all of this, so using a game maker software doesn't count. Gamemakers do almost all of the work for you before hand and therefore all of the methodical aspects of computer science are completely absent from the process.
Thanks for taking the time to read!
