Messages

1

Programming / Re: Theory about popularity of languages

« on: September 17, 2014, 08:06:04 PM »

In Visual Studio you need to press only one key: F5. So it's 50% easier than in linux!

You seem to miss the crucial point: Only if it works! (Which it won't because Visual Studio won't know where python is located.)

Maybe I should point out that this was on Windows 8.1. Is that maybe the difference? I've tried double clicking, and it didn't work (but I know python is installed because I can open IDLE and type things like 2+3 and get the right answer). I'm kind of interested in trying this again now that I've started. This just further proves my point.

2

Programming / Re: Theory about popularity of languages

« on: September 17, 2014, 07:01:27 PM »

I agree with koiwai. It boggles my mind that people can program in Windows. The text editors (Sublime in particular) have always just known where everything is located with no extra setup (python, ruby, C, etc), so I can just Ctr+b to do a build in Linux. When I was making GradHack, I wanted to do a test build on Windows and couldn't figure out how to run a program with python at all. I "downloaded" python (hurray for package management like apt for Debian which actually puts things in the right places) and "installed" it.

Typing "python gradhack.py" did nothing. I downloaded Sublime for Windows in the hopes that this amazing text editor would find python and allow me to build from within it. Didn't work either. To this day, I still haven't figure out how to run a python program in Windows. And lets not even bring up git. "sudo apt-get install git" Done. You can use git from anywhere in your system. I just wanted to git clone my project to Windows and ended up going to github to click to download it.

I know that people that professionally use Windows as development environments probably will scoff at this, but as an amateur, Linux is so easy and Windows makes you fight with it at every step.

3

Early Dev / Re: GradHack

« on: August 29, 2014, 03:17:18 PM »

Thanks Eudoxus. I studied something called arithmetic geometry. The preliminary work for such study is in algebraic number theory, which Hilbert essentially founded.

4

Early Dev / Re: GradHack

« on: August 25, 2014, 03:52:54 PM »

I'm not too concerned about giving "an unrealistic view of academia to impressionable youngsters" in the same way that I'm not concerned that impressionable youngsters got the wrong impression of professional ice skating from Blades of Glory or of the beauty pageant world from Drop Dead Gorgeous. There are times that people are trying to create an accurate depiction of things and there's times when they aren't. I think youngster can tell that a roguelike game which involves computer viruses wandering a building with random generated floors that you attack to gain time is not trying to accurately depict grad school.

That being said, I did post here looking for comments, and I was given them. I can certainly see that having something as serious as plagiarism be so casual in a game could be offensive. I'm also not strongly tied to the concept, but I'm having some trouble trying to rephrase the premise with minimal disruption of the rest of the game. Any ideas on why you would have to ascend a building in a short period of time to get your thesis?

5

Early Dev / Re: GradHack

« on: August 23, 2014, 02:05:36 AM »

I don't buy it. It is really hard to prove plagiarism. People get their results scooped all the time (it happened to me while I was writing my thesis, and my advisor had seen a fully written up form of the result by me ... the result appeared on the arXiv by someone else). The thought never even crossed anyone's mind that it was plagiarized. It happens way too often. If that note appeared (which it wouldn't), the person could claim they got the result independently.

Not that the premise was meant to be serious. It is a MacGuffin to have an excuse to have a grad school theme. I grant your point that even in such situations, the outcome of the defense would not be changed. The committee probably wouldn't even realize it had appeared.

6

Early Dev / Re: GradHack

« on: August 22, 2014, 12:10:37 PM »

Well, first I'd say, which roguelikes have a realistic premise? But second, you actually give good arguments why it is more reasonable than you claim. If no one has read it, and your rival steals a physical copy, then they could go upload some results to the arXiv as their own. No one will know the results are yours, because no one has read it.

7

Early Dev / GradHack

« on: August 21, 2014, 02:14:12 PM »

Hello,

I've been making a short and simple roguelike set in grad school on the night before your thesis defense. Your rival steals your thesis and tries to plagiarize it, so you must ascend the building to his office on the top floor, get your thesis, and safely leave the building.

The whole concept is a race against time. The three classes are what you are specializing in: math, literature, or music. Each class gives you a set of special skills.

I've never really programmed anything substantial before (a couple hundred lines maximum), so this was mostly an experiment in managing a large project + learning how to handle the elements in a game. As they say, "fail fast" because that's how you learn.

I'd say it is in alpha-ish stage now. I don't see this as something people will sink a huge amount of time into, but I hope it is fun figuring out some strategy. I think with appropriate strategy, all classes are winnable most of the time.

I streamed myself playing it on twitch yesterday while I found some lurking bugs and balance issues. Here is a really short clip that I think doesn't spoil much if you want to see it: http://www.twitch.tv/hilbert90/c/4956286

Watch the whole stream at your own risk. I manage to win with the different character classes and explain why I think the strategy will work as I do it, so I give lots of spoilers about what everything does.

The download is here: https://github.com/wardm4/gradhack

Sorry about the pygame dependency. If I could do it over, I would probably have just used ncurses or something, but I really wanted to learn how pygame worked, since I've seen some cool games made with it.

8

Programming / Re: Refreshing only on Keypress

« on: August 10, 2014, 07:55:41 PM »

I don't know how the behind the scenes of pygcurse works, but I imagine it is just a port of ncurses to work with pygame. So in effect, I think I am using a form of curses.

9

Programming / Re: Refreshing only on Keypress

« on: August 10, 2014, 02:43:01 PM »

Thanks for the replies. I've been using python for years for all sorts of things, but I've never tackled anything as large scale as a small game. I'm pretty sure I have the programming skills to pull one off. I guess there are a few reasons I was trying to do it this "easier" way. The main one is to keep everything as simple as possible to maximize my chances of succeeding.

1. I was having massive difficulty with the constant looping, despite it being setup to work that way naturally. For example, if I press "right" then my @ would sometimes move 2 or even 3 squares over. This was due to the constant looping. If you didn't release the key before the next loop it would count it as 2 (or 3) keypresses.

Alright. That is easy enough to fix with time delays and things, but I started getting nervous that everything I tried to implement would become a lot more complicated than it needed to be by unnecessarily looping.

2. The whole logic of keeping things separate is confusing me. It will still be quite a project to implement with updating only on keypress, and that logic is something I fully understand. Trying to add in stuff I didn't understand felt like a procrastination issue. I knew I'd have to take time to learn a bunch of stuff just to get the logical flow right, and that was time I wouldn't be working on the game.

Anyway, excuses, I know. I'm mostly replying, because I'm curious if there are any toy examples I could look at to see how the "pro" way of doing it works. Rather than reinventing the wheel, I might feel differently if I could just look at the logic in code already written (I'm comfortable enough with C, C++, python, ruby, java, and similar that I should at least be able to follow the logic).

I know there are lots of finished games I could look at, but that would require sorting through tons of irrelevant details. Or are there any good game programming books or online resources that describe the general flow? Sorry. I probably should have researched this better before beginning.

10

Programming / Refreshing only on Keypress

« on: July 28, 2014, 01:50:05 AM »

Hey,

I've been starting on writing a roguelike for the first time using pygame and pygcurse. These are basically designed to continuously refresh the screen at some fps so that you can easily animate things. I asked about getting a refresh only upon keypress here: http://stackoverflow.com/questions/24771462/pygame-loop-only-upon-keypress I've successfully implemented a template and can't really see how this will be a problem for what I want.

It seems it is somewhat frowned upon to do things this way, even for turn-based things. What are people's thoughts? Have people done the refresh upon keypress method of displaying things and wished they hadn't later for some reason? I intend my game to be completely in the classical ASCII style with no tiles or anything.

Thanks.