Closed hanyuone closed 8 years ago
We really don't need two exe's. Does the single-file exe download all the requirements, @testitem?
Also, guys, DON'T MERGE THIS YET. I still have things to do.
@joshgit What was the GameFrame class for in Frames? I got rid of the whole thing on my side, and the game works just fine without it.
Which one do you want to keep? Anyways after this PR is merged we would have to update the exe. The sfexe doesn't have tcl bundled, so sfexe is pretty much useless...
The GameFrame
class was used to make a sample of how the frames were supposed to work. As the class is not initiated in any module, we can get rid of it. @DerpfacePython , we can avoid the threading issue in a better way by making the program object-oriented. (Maybe @joshgit could help with that? Almost all of his contrbutions were either updates to game.py or adding helper classes.)
So... for object-orientation... which program do you mean, @testitem?
Also, we should probably keep the normal exe file until we (mostly you though) figure out how to include the tcl files in sfexe.
I mean the game.py program, to me it looks like a big mess of functions.
Yeah, I agree with that. So how can we do this?
I'm gonna show you.
Anyways, once the OOP version comes out it's going to be 1.0.0. I got this template:
# Welcome to the New, Reformatted 1.0.0a1 Ways To Not Make Money!
try:
from Tkinter import *
except:
from tkinter import *
from random import *
from tkinter.messagebox import showerror
import math
import save_and_load
import frames
import game_model
import webbrowser
import sys
class GeneralFunctionMixin(object):
'''Collection of functions both used by MPSFM and UFM.
Gold upgrade handling and the lotto function will also be
placed here.'''
pass
class MPSFunctionsMixin(object):
'''Collection of functions handling building buying/
MPS handling/money addition'''
pass
class UpgradeFunctionsMixin(object):
'''Collection of functions handling upgrade buying/
handling results of buying them'''
pass
class CentralProcess(Frame):
'''The class in which all game functions are processed.
This includes frame layouts, button layouts,
signin methods, and reporting.'''
def __init__(self, master):
'''Initializes the game.'''
Frame.__init__(self, master)
self.grid()
self.signin()
def signin():
pass
def main():
root = Tk()
game = CentralProcess(root)
game.mainloop()
Feel free to commit to master. I could do (evil) stuff like git rebase master
and git push --force
to master. That should do to overwrite any commits.
Uh... @DerpfacePython ? What are you working on these days? I haven't heard from you much.
1: I'm working on a school online canteen thing with a bunch of my classmates (one of whom is Cyber-Shadow) called Falcon's Nest. It's available on Github, search "FalconsNest". 2: I'm also currently on holidays right now, so I won't have access to the interwebs from time to time.
So, should we merge this? We should probably find a way to strip down game.py
as much as possible - like, put all the buildings and upgrades into one file, put the signin stuff into another, that sort of thing.
N.B. What's the point of frames.py
?
Yeah... the problem is communicating back and forth constantly between programs (all the global var
calls)
I do not know what frames.py is for. Ask @joshgit (where is he?)
Frames.py has the Tk GUI frames the application uses.
yeah.. so what's the point?
Of having GUI classes not put in the same file as our model classes? Have you read about the MVC pattern?
I mean why do we need GUI classes?
To sort everything out? Adding classes just makes it more complex.
No, adding classes keeps the GUI stuff separate, so it's not mixed in with the model logic. What's your proposed alternative? Use functions in the model module to create the GUI? Please, read about the MVC pattern!
That's exactly why you want separate GUI classes. Now you just have to change what's in the existing GUI classes to switch to a new GUI library. If the GUI stuff wasn't separated into it's own class, you'd have to comb through the model module or other places and hope you'd updated all the GUI stuff correctly.
so what this basically does is input, processing and output - I don't see how you implemented it.
Okay. I see. So the only thing is we have to change is the functions?
Hopefully you only have to change what's in the GUI classes. That's the idea at least.
So, when are we merging this PR?
Also, I was thinking, maybe we could continue using Tkinter because we've done so much of our code off of it - we just have to make our own styling so it doesn't look ugly. Is there any possible way to change the texture for the buttons and stuff so that they're not the ugly default?
groan don't change frames.py, change game.py!
Also, I was thinking, maybe we could continue using Tkinter
Tk does NOT support animation!
Yeah, you've got a good point there, @testitem. Should we just change it now?
What should we switch to? Pygame is the best choice. (I said before it was horrible I saw 3.5 users using it.)
HOORAY!
I made a single file executable with tcl IN IT!
WOOT! Can you update the exe branch then?
I did,
update: do not use the EXE, tcl is not 100% installed on it, malicious software. I am reinstalling and recompiling game.py
Ah, cool.
Because that portion of the screen is changed for messages, we can safely get rid of the pictures.