Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Orange Wizard]

I usually just make copies of the files I'm working on, so I end up with a bunch of subdirectories in my project folder each named after the code version contained therein.
In other words, annoying, grossly inefficient, and prone to errors when I accidentally overwrite an old file. I tried using github once but I regressed almost immediately.

[yobbo]

git is pretty easy to get started with for version tracking.

first

Code: [Select]

git init
git add <files i want tracked>
then repeat

Code: [Select]

<do some development>
git commit -a -m "i did some stuff!"
until you think it deserves a version number (let's say 0.1), then

Code: [Select]

git tag 0.1

That's basically it!

After that if released versions need minor updates, you can create a branch off the tagged commit, like

Code: [Select]

git checkout 0.1
git checkout -b 0.1.x
<do some stuff>
git commit -a -m "fixed some bugs with 0.1"
git tag 0.1.1

Now

Code: [Select]

git checkout master
will get you back to the main development branch, and you can

Code: [Select]

git checkout 0.1.x
at any time to work on the 0.1 branch, and of course

Code: [Select]

git checkout 0.1
git checkout 0.1.1
will give you those exact versions so you can do a release build or whatever.

[Skyrunner]

Git is also easier to make tons of backups, because unlike the manual approach, the made files are both hidden and smaller, as they're all diff patches.

Finally, if you're not worried about making your code public, you can use github for fancy graphs and multiple-redundant backups.

[Zireael]

There are git graphical clients, which means you don't have to worry about git commit whatever. My favorite is SourceTree.

As for the web repo, I used Github.com but recently decided to keep a copy at bitbucket, too. (Bitbucket has a better issue tracker while Github allows online editing and easier tag making and bullet/ticked TO DOs in issues/pull requests).

[Orange Wizard]

So, I set up a Github repository. I wish I'd done so earlier. This is cool.

[jhxmt]

Huh.  I've set up Sourcetree and have created a repository...just locally, I think.  But my working copy directory seems to be the same as the repository directory, which I'm assuming is bad practice, and I'm not actually entirely certain where the diffs are actually being stored (so no idea if deleting that directory will, in fact, utterly delete the repository).

Ah well.  Learning experience. 

[Biag]

Huh.  I've set up Sourcetree and have created a repository...just locally, I think.  But my working copy directory seems to be the same as the repository directory, which I'm assuming is bad practice, and I'm not actually entirely certain where the diffs are actually being stored (so no idea if deleting that directory will, in fact, utterly delete the repository).

Ah well.  Learning experience. 

Nope, that's the idea. When you tell Git to create a repository named "MyGame", it creates a directory MyGame with a subdirectory named ".git". The .git folder is where git stores config files, logs, diffs, and so forth. Deleting MyGame/.git/ will delete the repository.

It's called a "repository" because generally, you would be running git on a remote server somewhere whose only function is to track the code. You "pull" code from the server, make changes, commit them, and then "push" your commits back to the server. This is so that multiple people can work on the same thing, as well as keeping the code safe in case your computer catches fire. But there's no reason you can't just keep a local repo around for whatever you're working on.

[EnigmaticHat]

So, my game has this big stack of "if main.inputMode == ___:" and "if event.key == ____:" statements that runs the controls.  Now I'm trying to add mouse support and realizing that I need to rip the entire thing apart to do so.  Not fun.

Also, my game started out with the idea that you would be controlling multiple characters with RL controls, the only new one being tab to switch the selected character.  Now that the game is moving over to controls that are a bit more Fire Emblem/Wesnoth, it makes sense to be able to highlight a tile without having a unit selected.  The problem with that is that there are something like a hundred lines of code written with the assumption that you would always have a unit selected, so now I have to either change those, or accept that the player will always have a character selected.  So yeah, big wall of work ahead of me that I don't even want to start.

On the other hand part of the aforementioned change involved a move from "a character gets to take up to five RL style actions per turn, which can be anything" to "they get so many moves which can also be spent on inventory manipulation, while major actions like attacking will end that character's turn".  This fixed a rather glaring issue which was that if a character started a turn next to an enemy they could attack them 5 times.  I expected this to be a huge transition.  Instead it took literally one 20 character line of code, and the lion's share of the changes were completed.  It didn't even have glitches, it just straight worked, for both enemies and PCs.  Best feeling ever.  The game was even fairly balanced, somehow, and played better than before.

[jhxmt]

I managed to refactor my code to undo an extremely stupid (yet highly fundamental) newbie-coder bug in my "messing around with stuff" file.  Everything in its extremely limited scope now works as expected.  I feel so happy. 

(Toying with a tile-based map, I managed to get my player character's start position conjoined with the location of its sprite in the sprite sheet.  No, I don't know how I managed that one either.  Doh.)

[jhxmt]

Okay, as an utter neophyte in terms of game design/code structure, I'm intrigued: how do people tend to structure the flow of their game code?

For example, if I'm building a real-time pausable game (DF-fortress-mode stylee), various things I might want to happen are:
1) Some sort of title screen upon loading the game, with options for new/load/quit/etc.
2a) The ability to create a new game.
2b) The ability to load a previous game.
3) After 2a or 2b, the ability to play said game.
4) In game, the ability to accept player input and react to that.
5) The game to progress dependent on a particular time setting e.g. paused, slow, normal, fast.
6) Potentially, the ability for a 'popup' window to be displayed, and for that window to be interacted with (move it around, click 'OK', etc).

I'm struggling with a number of these.  1 is relatively straightforward, 2a and 2b could presumably simply be different ways of creating/initiating a 'Game' class, 4 is simple enough to check in the main loop of the 'Game' class...

...5 puzzles me a little bit.  6 puzzles me a lot.  If I'm running a main loop that checks player input and processes the game, then if I've got a popup window appearing then I want to game to cease proceeding, but still be checking for player input.  How does that tend to work structurally?  Instancing a separate 'popup' class with its own processing loop?  Switching 'Game' itself into a state that says "you're dealing with a popup, wait until you're told it's gone before proceeding"?

The world seems lacking in materials for game development that's higher than "Hello World" but lower than "Here's the entire codebase of a twelve-year-old heavily-developed roguelike, get to work".   

[Levi]

I usually use a state machine to control which loop the game is going through.  So I'd have a 'main menu' state, a 'active_game' state, a 'help_menu' state, etc.

For 5, its likely just a matter of deciding how many game "ticks" you want per second, and then adjusting the number of ticks per second for the speed.  Its a good idea to keep game ticks and real time separate independent concepts in your code. 

For UI, well I'm terrible at that, so I've got no advice.

[Skyrunner]

Typical program would have Input(), Update(), Render().

In Input you query the event queue until all inputs are processed. Then in Update you do actual game logic depending on inputs. Render is where you draw stuff to the display.

Each State has the above three methods. There is a state stack that holds states, and does Input and Update for only the topmost stack, effectively pausing the game if a popup state is there.

Popups are just another game state. I push a Popup object to the state stack.when an input is received,  I pass the inputs into some data object and pop the Popup state to return processing to the previous state.

[EnigmaticHat]

So I've got the starts of the level generation algorithm for my game.

Spoiler (click to show/hide)

Its been cheated so the entire map is explored by default, mainly because the current LoS algorithm makes each move take .5-5 seconds so exploring it by foot would be a massive pain.  I several ideas on how to fix that, even without porting it into a faster language than python.

But yeah, pretty proud of this.  I need to make the rooms less predictably square and make the hallways connect to the rooms in a less predictable manner, plus a bunch of minor tweaks and interesting stuff to be inside the rooms.  I'm also going to add cave style rooms with their own graphics, and more graphics for different room appearances.

[Retropunch]

So I've got the starts of the level generation algorithm for my game.

Spoiler (click to show/hide)

Its been cheated so the entire map is explored by default, mainly because the current LoS algorithm makes each move take .5-5 seconds so exploring it by foot would be a massive pain.  I several ideas on how to fix that, even without porting it into a faster language than python.

But yeah, pretty proud of this.  I need to make the rooms less predictably square and make the hallways connect to the rooms in a less predictable manner, plus a bunch of minor tweaks and interesting stuff to be inside the rooms.  I'm also going to add cave style rooms with their own graphics, and more graphics for different room appearances.

Certainly something to be proud of! You seem to have pretty much everything down for a good RL!

Turn time IS important though. I'd really get that sorted before anything else if you can!

[EnigmaticHat]

-snip-

Certainly something to be proud of! You seem to have pretty much everything down for a good RL!

Turn time IS important though. I'd really get that sorted before anything else if you can!

Andddddd done.  I thought it would be a big ordeal but it was a pretty quick fix, minus the AI changes.

There were three inefficiencies, all of which I'd been ignoring for a while.  First of all vision range was infinite, now its 9 tiles in a fake "circle" to make it look more natural, requiring far less "sight rays" to be sent out and limited how long each one can be.  Ironically movement range is still an ugly square.  The second is based in the fact that you control multiple creatures (so my game is arguably a TBS instead of a roguelike, but it has the mentality so I'll still post here).  It used to be that each time anyone moved, it would have to reset everyone's LoS and check again.  Now each tile stores which creature can see it, so if you move one creature it wipes and recalculates only that creature's LoS.  The third is that enemies used to have their own LoS calculations.  Early on to be the same calculations as friendly creatures, which was awful, but a while back I changed it so they send out only a single sight ray as if they trying to shoot you.  This was fastish but made the game slow down with large numbers of creatures and also had a lot of weird situations where you could see them but they couldn't see you.  I've now said fuck that and switched to a Crawl style system of two-way LoS.  If a friendly creature can see them, they can see that friendly creature, period.  So basically no calculations required on that front.

The game now runs at an easily playable speed.  Level generation takes ~10 seconds but I've added a debug mode that only generates one room for quick testing.  Enemy pathfinding is likely still an inefficiency, but its mild enough I can put it off until an eventual AI update.  There's also the problem of there being no content past the extreme early game, and a few important systems like spellcasting and party customization not having been implemented yet, but one step at a time