The Student Room Group

computer science OCR coursework

is there anyone who's willing to help me write my game im struggling A LOT and my teacher has not been helpful at all and i had to self teach myself coding. i'm really frustrated. my game is a hangman game and i'm coding it up on pygame as i am familiar with this language any links or tips on how to include features such as:

instructions page
category page
score board

or how to implement background images of pygame would be really helpful
Have you used the programarcadegames.com website? It's really helpful for tutorials
when's the deadline?
A level or GCSE?
Reply 4
Original post by knjhbgvyf
when's the deadline?


After easter (17th April) but i was hoping to get it down before then
Reply 5
A Level
Original post by knjhbgvyf
A level or GCSE?
Original post by springdcy
is there anyone who's willing to help me write my game im struggling A LOT and my teacher has not been helpful at all and i had to self teach myself coding. i'm really frustrated. my game is a hangman game and i'm coding it up on pygame as i am familiar with this language any links or tips on how to include features such as:

instructions page
category page
score board

or how to implement background images of pygame would be really helpful


Have you seen any of these tutorials about PyGame?
https://www.youtube.com/watch?v=K5F-aGDIYaM&list=PL6gx4Cwl9DGAjkwJocj7vlc_mFU-4wXJq
https://inventwithpython.com/pygame/
Following Tutorials like those can often be the best way to get yourself familiar with a new framework like PyGame - including drawing things on the screen, calculating movement/animations, handling input, game state, etc.


When it comes to implementing different 'screens', there's a bigger question about how you'd organise your app as a whole - that ideally leads you to looking at ways of breaking up your program's logic into logically separate pieces.
- i.e. different bits of your program which shouldn't need to depend on each other and can exist on their own. Different pages/screens are an ideal candidate for this, different views/pages/display screens should never need to depend on each other since they usually do totally different things.


One way to split an app into different screens is to think of each of those screens as being different kinds of 'objects'. The 'Object-Oriented' way of doing this would be to write a separate class for each screen, and being able to switch between each one, keeping in mind that each screen will draw in a different way, and each screen might also handle different user input (e.g. clicking the mouse on the screen) - something like this for example:
https://repl.it/repls/FractalDrearyLogic
(different classes holding logic for different screens, and using the main loop to run logic on whatever the current screen happens to be..)


Lastly, it's a good idea to keep one 'state' dictionary in your main program which tracks all the data and the current state/status of your game while its running, but is able to be passed around. Doing that means switching between different screens doesn't lose the current status of your game. The data you store in memory while your game is running probably wants to live in memory the whole time; different screens may do different things with the same data. For example, your hangman game might add scores, but your scoreboard would be responsible for displaying those scores.
(edited 5 years ago)

Quick Reply

Latest

Trending

Trending