Spacey Shooter
A downloadable game for Windows
This is a conceptual game/portfolio I'm using.
I started learning about coding about a month ago and just started on game design/coding on 2/11/16. So I'm still very much new at this, but I'm pleased how far I've gotten in this short amount of time.
I've started to use this site as a blog to show potential employers how I've overcome issues I've stumbled upon. I may lack quantity in my portfolio. but I'm hoping you read something about me that you like.
The game is being built with Game Master Studio.
The Assets are temporary.
The game is free
2/18/16
I designed a temporary level and found that the game would severely lag and get (1 - 3 fps) because of all the objects and particle effects. Which made me think that this version of the project had become dead in the water. What am I to do? Later I discovered that tiles can also be destroyed, so I did a quick test and it works. This would cut down the lag in game severely, but the trick now is to see if I can get the particle effects to work with the tiles.
Update: #2
I had to scrap the idea of the game, it just wasn't going to work. Not on this engine at least. I might try to salvage features I liked into the Side Shooter. Like the burst mechanic and repair mechanic are both something I can bring over into the Side Shooter.
2/17/16
So after talking to a friend and discussing potential features and such, an idea came to mind. That is something I believe could make this game into more than a portfolio. So I'm back at the drawing board and rewriting chunks of the code again. The game is now a spaceship that is damaged and you need to constantly adjust it's altitude, it also has a Burst Mode that destroys anything in it's path and a Collection System that helps repair your ship that alleviates it's problems and upgrades it with new abilities to take on the bosses/enemies that await for you.
What I've implemented so far:
- New Navigation Code
- Different States/ Burst Mode for the player
- Particle System from destroying the environment
- a temporary/working burst meter
I had a pretty bad brain fart earlier that seriously set me back. Made a rookie mistake accidentally coded for a button press to simulated button press. I had to strip the code to even discover the source of this issue which put me back to square one.
Update: #2
The particles didn't look quite right so I painted some shading on it and it looks a lot better, the tone still looks a bit off though.
uploading the new version right now, with everything listed above.
2/15/16
Items from the list I have finished:
- Remaking Assets (Player Ship, GUI, Enemies...)
Rewriting Navigation CodeAdding A.I.Developing Three Types of Enemies- Developing a Level Boss
So I did a complete rewrite of the code and implemented new things I learned.
(so far it has better controls and Enemy A.I. with different types.)
The Assets are temporary, I'm waiting to get the code just right before I make them from scratch.
It took me awhile to add acceleration and friction to the controls. The trouble I had was that the function called for image_xscale, it used the placement of the asset to get a value of (1 for right or -1 for left) you get these numbers because it's on a grid system so anything positive will go right and negative will go left. I didn't use the function of having the ship change direction of where they were facing, thus causing my friction function not applicable. I had to instead use it tied to left or right keys and assigned them a 1 or -1 value. The result isn't as good compared to the program doing itself, but I'm hoping that it'll be good enough for people not to notice.
Same problem happened to switching images of up and down, since the player doesn't experience gravity. I couldn't add it automatically and had to tie it to keys again.
It's now 4:25am and I'm having a brain fart in subtracting lives from the PlayerStats. Funny enough I did it before in my previous build. I think I'm just exhausted/frustrated.
Update: #2
Waking up from this early morning with a fresh pair of eyes, I realized that in the previous build I hadn't solved the Player Stats dilemma and had actually left it unfinished, also the previous build ran a different code to display health. Anyways I got that done and now the Movement/Navigation code is acting up and the Player's movement has a ice skating feel. I need to dissect my code and try to find what's causing the problem. I so thought I was done with this.
Update: #3
Got it! figured out what was causing the ice skating feel, brain hurts. I can now develop the level.
- Finish designing the level
- Develop the Boss and A.I.
- Add a scoring system
- Remaking the Assets
- (consider adding in placeholder sounds)
Update: #4
Uploaded version .2 on itch.io
What this version has:
- Reworked Code
- Improved Movement/Navigation Code*
- Different Enemy Types
- Boss
- A.I.
- Score/Highscore System
- Xbox Controller Support
*I added in acceleration and friction to the movement, instead of instantly going from 0 to 5 pixels it now gradually builds up to 5 pixels. The game has friction so that you don't stop on a dime, but also gradually slow down to 0.
The game is a lot harder, I think it's a mixture of the new movement system and different enemy types. I want to implement either power ups or invincibility respawn state to help alleviate this.
I still have a lot more work to do, but I feel the BASE of the game is done. Now it's just tweaking and adding in more levels.
P.S. I cheated with the boss; not only is it a Gradius Boss, but also I'm not great when it comes to animation. However I do understand After Effects so I had AE do it for me.
Assets are once again temporary.
2/13/16
I have a list of things I'm currently working on:
- Remaking Assets (Player Ship, GUI, Enemies...)
- Rewriting Navigation Code
- Adding A.I.
- Developing Three Types of Enemies
- Developing a Level Boss
2/12/16
I've recently updated the code for the player ship, previously it had some pretty horrible collision detection.
So this was what was happening, the game would move the player four pixels ahead and if it collides into something it would move it back and run the destruction event. (What this did?) It made the game harder. I got a couple feedback about how hard the game was and playing it over and over again I noticed how close I would have to be near a wall would change and the destruction event would start at different variables.
The new code detects if that player can move 4 pixels and if not, can it move 1 pixel and so on til it collides. (What those this do?) It makes flying in the game A LOT more accurate.
Update: #2
I discovered a new problem with the code that I just implemented to the Player Ship. There's only collision from the front, must investigate further. I solved one problem only to create another...