| Age | Commit message (Collapse) | Author |
|
Explain the while loop and condition here better than the code explains
it.
|
|
Since `:python` didn't work out for me because of my system version
mismatch (1307eac), use Ruby to generate random numbers instead.
And w00t! this doesn't block the interface, rendering, and player
movement!
|
|
Ostensibly this should work and generate us a random number using Python
without having to call `system`. My hope is that this call doesn't block
rendering and execution of our game.
The trouble is that I can't get it to work because I have Python 2.7.1
installed as my system Python (which Vim is linked against), and Python
2.7.9 installed via Homebrew. Vim is looking in the Homebrew path when
it should be looking in the system path to Python and causing this
error:
Error detected while processing function space_vlaze#random#Random:
line 7:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/lib/python2.7/random.py", line 47, in <module>
from os import urandom as _urandom
ImportError: cannot import name urandom
More information:
- https://github.com/klen/python-mode/issues/87
We could get around this by not having these 2 versions of Python
installed on our system (the random implementation changed between 2.7.2
and 2.7.3) or by setting `$PYTHONHOME` in our vimrc.
Could, but I'm sick of this shite. Would have liked to be able to use
Python for this because in my opinion Python tends to be pretty fast as
interpreted languages go, but frak it I'll just use Ruby.
|
|
Add a bunch of enemies to the board. The count will depend on how long
you've been playing the game.
This currently kind of works in that it adds enemies to the board at
random coordinates and adds more as time goes on (too many actually,
I'll need to reduce the count or slow down the spawn rate).
The trouble is that it looks like it's blocking on the `system` call to
`python`. This is a problem because it freezes the board and prevents
any player movement while the Python random command is working. Let's
try using Vim's built in `:python` to do this to see if that makes any
difference.
game.vim:
Add a `ticks` script variable that tracks clock ticks and increments
each time our game loop executes. This will allow us to keep track of
time in a consistent way and make it easier for us to pause time when
we pause the game. Also, I envision it being easier to deal with
smaller numbers starting from 0 instead of a whole Unix timestamp. Got
the idea for ticks from Tetris.vim
(http://www.vim.org/scripts/script.php?script_id=172)
enemy.vim:
* Set player character to a spade (like in playing cards) because when
it's small it could kind of look like a popcorn kernel
* Set a min and max amount of enemies that can be on the board at any
given time because we don't want a sparse board and we also don't
want to overwhelm the player when they've been playing for a long
time and the spawn count increases to an insane amount.
* Create a function that will drop an enemy at random coordinates on
the board not on the player's coordinates.
TODO: we should extend this function to ensure enemies can't spawn
within a certain radius of the player so that we don't get random
instances of being a dick.
TODO: also ensure that we don't place an enemy on top of another
enemy or on top of a missile.
* Every 5 seconds update the enemies on the board and regenerate them
such that the enemy count is withing the min and max enemy counts.
|
|
Add a random number generator based on this Stack Exchange post from
Carpetsmoker:
http://vi.stackexchange.com/questions/807/how-to-generate-random-numbers/812#812
Since Vimscript doesn't have a random number generator, shell out to
Python and get a random int between 0 and the max value passed in.
|
|
Fire all 4 missiles and make sure they continue moving until all 4 of
them hit the edge instead of stopping when a single one hit the edge of
the board.
|
|
Fire all 4 missiles at once. Currently doesn't work and stops when one
of the missiles hits the edge of the board.
|
|
Remove missiles when they get to the end of the board. Otherwise they
just stay there right before the end.
|
|
Create a missile moving to the right of the player. Pressing <space>
fires the missile. Later we'll want one coming out of each direction,
but this is just to test it out.
TODO:
* Clear missile when it gets to the edge of the board
* Make it so the missile doesn't block other actions on the board
(including player and enemy movement)
|
|
We will always want to `redraw!` when we re-render the board, so call
`redraw!` from inside this function.
Noticed this when I was writing the missile firing code and realised
that I needed to re-render the board at each step in the missile
animation.
|
|
Because `nr2char` gives us an actual space character instead of
`<space>` as I had thought given the examples I had seen of it.
|
|
* Store player coordinates in `player.vim` instead of `game.vim` because
they belong to a player instead of the game/board so it makes more
sense to store them there.
* Remove old player functions from `game.vim`
* Update movement functions to ensure that they update the player
coordinates in addition to updating the board array
|
|
Kind of add player movement.
TODO: Update player coordinates when moving
* Add a main game loop to `space_vlaze#game#Init`
* Fill in player directional movement functions
* game.vim: Add functions to access and set `s:` variables so these can
be accessed from player.vim
* Add new mappings based on
https://github.com/mattn/invader-vim/blob/f04e7f5e8ac42ae87db6050e64449055206c4054/plugin/invader.vim#L44-L60
because it turns out that the mappings we previously defined don't
work when out main loop is running.
|
|
These aren't constants so maybe they shouldn't be in all caps but wanted
an easy way to know the current coordinates of a player. This should
make player movement easier.
|
|
* Remove `<nowait>` since it isn't available in my version of Vim (7.3
2010 Aug 15, compiled Jun 20 2012 13:16:02) and breaks the mappings if
it's included.
* Create function stubs for all mappings
* Add missing `<cr>`s to end of mappings to make them work
* Initialise mappings when starting a game
|
|
|
|
Setup layout and structure of the code.
* Add a command and map to start the game
* When the game is started, prompt for game start, help, or leaderboard
* Create help file template (TODO)
* On game start, initialise the board with spaces and a player character
* Setup buffer locals on game start
* Create various functions that we'll need coming up either as stubs or
filled in with what they'll probably be.
|