Time spent: Only around 30-40 minutes. Caught up on the last of Jessica Jones tonight. Good stuff, if you're looking for more netflix to indulge in. Gets very intense.
Didn't get too much done in that time. Got JSON parser in, set up the basic deck, shuffling, working on popping unique cards off of that deck and using the JSON nodes to populate the info. Pretty simple so far, rule changes went without a hitch. Working on value changes now. Slightly trickier, but not by much. Tomorrow is date night with Morgan so I won't get anything done then, I'll have to come back to this on Thursday.
Tuesday, January 5, 2016
Monday, January 4, 2016
#RealWinners
So I know barely anyone still reads this, which probably makes it perfect for the experiment I want to try. I don't think it's any secret that I'm not exactly great at finishing what I've started, but I've put money down on this next thing I'm working on so I need anything I can get my hands on to keep myself accountable. I think having a journal of my work will possibly help motivate me, or at least can be a source of seeing how far I've come when I'm feeling down.
So this is the journal of my work going forward. At least for this one project, code named #RealWinners.
A base description of the project is "Calvin Ball as a Videogame"
I'm pretty excited about it's possibilities, and the system I have in place should be flexible enough to allow me to do this. I need a playable demo ASAP, and that's my short term goal. The code can be complete shit as long as I get it playable and hopefully fun.
Not many details now, the last part I was working on was the Slap Card system. I need it to load cards, images and descriptions from JSON so I can get a basic deck set up, then I just need to add cards to players hands after they score. That should be about the last thing I need to do before playable. That and re-spawn players at their starting points when the ball drops, but that's not 100% nessecary.
I also need to set up a perforce for my collaborators. Last time I tried to do this it ended badly because there's already a perforce server in our subnet. I should talk to ricky about what he had to do to set this up.
No shame on this project, Gibbs rule #28: if you need help, ask.
So this is the journal of my work going forward. At least for this one project, code named #RealWinners.
A base description of the project is "Calvin Ball as a Videogame"
I'm pretty excited about it's possibilities, and the system I have in place should be flexible enough to allow me to do this. I need a playable demo ASAP, and that's my short term goal. The code can be complete shit as long as I get it playable and hopefully fun.
Not many details now, the last part I was working on was the Slap Card system. I need it to load cards, images and descriptions from JSON so I can get a basic deck set up, then I just need to add cards to players hands after they score. That should be about the last thing I need to do before playable. That and re-spawn players at their starting points when the ball drops, but that's not 100% nessecary.
I also need to set up a perforce for my collaborators. Last time I tried to do this it ended badly because there's already a perforce server in our subnet. I should talk to ricky about what he had to do to set this up.
No shame on this project, Gibbs rule #28: if you need help, ask.
Saturday, February 1, 2014
Lazy Saturday
Re-factored the camera, did some more proto-type art, got a run/jump/death cycle, etc. Looks better than the blocks I was using. At this point I want to:
A) Get a complete level-flow working from main menu to level completion
B) Finalize a good, fun, prototype level
C) Add enemies that can shoot back?
D) Get it on mobile for testing / playtest with some friends.
But currently have dinner plans, so I can't say much more than that.
It was kinda just lazy work, not bad.
A) Get a complete level-flow working from main menu to level completion
B) Finalize a good, fun, prototype level
C) Add enemies that can shoot back?
D) Get it on mobile for testing / playtest with some friends.
But currently have dinner plans, so I can't say much more than that.
It was kinda just lazy work, not bad.
Wednesday, January 29, 2014
Super Quick Update
Got the player restart and score stuff in. No stretch goals, not enough time!
More to follow tomorrow.
Peace, everyone.
More to follow tomorrow.
Peace, everyone.
Tuesday, January 28, 2014
D-D-D-Design work!
Tonight was very light on the tech side. I re-adjusted the PlayerBehavior system to have a "negative Effect" that starts only when the specified behavior is not in use (mostly so I could do some "beginning-to-fall" effects in gravity only after a jump has been released) which should prove to enable some more interesting behaviors down the road!
I banged out a few small art assets, and spent the majority of the night trying to find a way to make jumping and shooting feel good. I tried doing an additive approach, where jump-speed wasn't gained instantly and extended over time, and gravity took effect over time as well. I didn't like how that felt, so I tried an "instant-velocity" jump with a speed lerp at the peak of the jump and it's feeling a bit better. I might continue to tweak it to get the jump just so, since it will be an integral part of the game. Perhaps a parabolic jump equation? I've used such equations in games before, they're aesthetically pleasing but never end up being just how I want them to be. I should take a look at Super Meat Boy again, I really like the jump in that game, as a platformer it is without parallel. I also played around with varying heights of the jump. Once I identify a scale it will be easier to figure out such matters, though. Probably that should be a priority of mine.
I think I'm closing in on a feel, threw together a basic run and it got better towards the end of the evening. Think tomorrow I'll try doing some more art? Not sure yet. Once I get started on a task you can't stop me, but determining what the flow of those tasks are is the area I have the most difficulty with, especially since I only get 1-3 hour windows with which to work on the game. Hopefully becoming a more focused and plan-oriented programmer for these side projects can also help me maintain focus at work where external factors all play a role in messing with my flow (meetings, lunch, etc.)
Plan for next 2-hour programming block (hopefully tomorrow night though perhaps not)
-Visualize Score System (score visible, flavor text for destroying targets)
-Player Reset System(currently just destroys self, no-good)
-Design Stretch goals:
1) Finalize Scale
2) Complete minute-long prototype level
3) Implement "dropping" enemy
-Art Stretch goals:
1) Do player run cycle
2) Do gun aim/shoot cycle
3) Implement in-unity Animation editor
Night all. Back day tomorrow, still super sore from chest day and Jiu-jistsu. Bleh.
I banged out a few small art assets, and spent the majority of the night trying to find a way to make jumping and shooting feel good. I tried doing an additive approach, where jump-speed wasn't gained instantly and extended over time, and gravity took effect over time as well. I didn't like how that felt, so I tried an "instant-velocity" jump with a speed lerp at the peak of the jump and it's feeling a bit better. I might continue to tweak it to get the jump just so, since it will be an integral part of the game. Perhaps a parabolic jump equation? I've used such equations in games before, they're aesthetically pleasing but never end up being just how I want them to be. I should take a look at Super Meat Boy again, I really like the jump in that game, as a platformer it is without parallel. I also played around with varying heights of the jump. Once I identify a scale it will be easier to figure out such matters, though. Probably that should be a priority of mine.
I think I'm closing in on a feel, threw together a basic run and it got better towards the end of the evening. Think tomorrow I'll try doing some more art? Not sure yet. Once I get started on a task you can't stop me, but determining what the flow of those tasks are is the area I have the most difficulty with, especially since I only get 1-3 hour windows with which to work on the game. Hopefully becoming a more focused and plan-oriented programmer for these side projects can also help me maintain focus at work where external factors all play a role in messing with my flow (meetings, lunch, etc.)
Plan for next 2-hour programming block (hopefully tomorrow night though perhaps not)
-Visualize Score System (score visible, flavor text for destroying targets)
-Player Reset System(currently just destroys self, no-good)
-Design Stretch goals:
1) Finalize Scale
2) Complete minute-long prototype level
3) Implement "dropping" enemy
-Art Stretch goals:
1) Do player run cycle
2) Do gun aim/shoot cycle
3) Implement in-unity Animation editor
Night all. Back day tomorrow, still super sore from chest day and Jiu-jistsu. Bleh.
Sunday, January 26, 2014
Lazy Sunday Work
Didn't get nearly as much done today as I wanted to. I implemented a basic player tracking/scoring system build into anything that can take damage. Theoretically the level at this point could gain scores from killing the player? That could be a fun statistic to track.
Somehow Unity decided several of my files would get wiped so I spent a majority of my time re-writing code that mysteriously vanished. Lesson learned, installed perforce server on my machine, and I'll be using that from now on. I meant to do that for a while, anyway.
The scoring system works by having each player own a ScoreTracker, which reports back to a ScoreMaster at then end of a run/level. The ScoreMaster is a singleton, or what passes for one in Unity since I made it a MonoBehaviour, which I might go back and blow that away, but we'll see. I don't have any pressing need to make it a pure singleton at the moment.
ScoreMaster serializes records in/out upon load and save functions, standard affair. Every item in the game that can take damage is required to have a scoreable component on it, but scoreable components can be put on non-damageable objects as well. The basic scoreable component only adds value when the object is destroyed, though with an enum switch and a derived class it can be made to add score upon contact with certain classes, etc.
Nothing too exciting, didn't get a chance to work on any of the actual gameplay like I wanted too, or even get to the score visualizations. :(
Well, the girlfriend is gone this week so perhaps I can get a few really productive nights in after work! I'm still excited for this game, just sucked to have to re-write code for unknown reasons.
If I got to bed in the next 15 minutes I can get a whole 8 hours of sleep...! Fingers crossed.
Somehow Unity decided several of my files would get wiped so I spent a majority of my time re-writing code that mysteriously vanished. Lesson learned, installed perforce server on my machine, and I'll be using that from now on. I meant to do that for a while, anyway.
The scoring system works by having each player own a ScoreTracker, which reports back to a ScoreMaster at then end of a run/level. The ScoreMaster is a singleton, or what passes for one in Unity since I made it a MonoBehaviour, which I might go back and blow that away, but we'll see. I don't have any pressing need to make it a pure singleton at the moment.
ScoreMaster serializes records in/out upon load and save functions, standard affair. Every item in the game that can take damage is required to have a scoreable component on it, but scoreable components can be put on non-damageable objects as well. The basic scoreable component only adds value when the object is destroyed, though with an enum switch and a derived class it can be made to add score upon contact with certain classes, etc.
Nothing too exciting, didn't get a chance to work on any of the actual gameplay like I wanted too, or even get to the score visualizations. :(
Well, the girlfriend is gone this week so perhaps I can get a few really productive nights in after work! I'm still excited for this game, just sucked to have to re-write code for unknown reasons.
If I got to bed in the next 15 minutes I can get a whole 8 hours of sleep...! Fingers crossed.
Thursday, January 23, 2014
Two-hour update
Got about two solid hours in today on the game.
No art, unfortunately, but I got a healthy chunk of the core systems in. I have the systems in place that I want for the core of the game play experience, now it's just creating interesting test levels with them and testing the initial deployment for mobile devices (part of the end-target for the project)
All in all in those two hours I completed:
- [Fixed] Core single-button-multi-use systems and events for both press and release, with room for multiple different interpretations based on the sequence of the press. Might want to re-do this to allow for certain time-segment sequences to trigger different trees of behavior, could be interesting but I don't think I will want or need that functionality for the duration of this project. Cool idea to keep in mind should I eve try another single-button game.
- Core weapon systems. Press to begin the process of "aiming" after a jump and the gun will swing out from the "holster" and continue swinging to point straight up, release to fire at any angle in between.
- Core projectile class. Very simple, standard projectile shenanigans.
- Core damage-interaction systems. Unity3D works off of the idea of scripts or components being attatched to a single object. Imagine this to be somewhat similar to the Decorator pattern if you're not familiar with the idea of components, but with some differences that I will not get into now because I do not deem it worth the time of discussion and I really want to get to bed right now.
Essentially there is a component that can take damage, and a component that can give damage. They can exist on the same object (such as an enemy that can be hurt by the player's weapons but can damage the player if the player were unfortunate or masochistic enough to touch them) There's more to them than that, rules for when the damage taker and/or the take-ee are to report themselves as "finished" and ready to be destroyed, resistances for different damage types, limits to how much damage a take-ee can deal out, if that strength weakens over time or can only touch so many unique takers before it is deemed unusable, etc.
-Prototype level: Gets across the point, has plenty of targets, platforms, etc. to run players to and to tweak values to guns, player speeds, gravity, etc. Currently not super fun, which is not heartening, but I knew my values out of the box wouldn't feel so great, so plenty of time to tweak and continue with the idea.
Plus I tend to be highly critical of myself and my accomplishments, will release a more public prototype test this weekend to some friends to get better feedback.
TO-DO FOR NEXT WORK PERIOD (Likely Sunday)
-Expand prototype level (more targets, more platforms)
-Tweak player values (gravity, run speed)
-Tweak gun values (speed of "aiming" and projectile types, their speed, damage, falloff, adding in burst fire or shotguns, etc.)
-Preliminary art (not having everything being boxes)
No art, unfortunately, but I got a healthy chunk of the core systems in. I have the systems in place that I want for the core of the game play experience, now it's just creating interesting test levels with them and testing the initial deployment for mobile devices (part of the end-target for the project)
All in all in those two hours I completed:
- [Fixed] Core single-button-multi-use systems and events for both press and release, with room for multiple different interpretations based on the sequence of the press. Might want to re-do this to allow for certain time-segment sequences to trigger different trees of behavior, could be interesting but I don't think I will want or need that functionality for the duration of this project. Cool idea to keep in mind should I eve try another single-button game.
- Core weapon systems. Press to begin the process of "aiming" after a jump and the gun will swing out from the "holster" and continue swinging to point straight up, release to fire at any angle in between.
- Core projectile class. Very simple, standard projectile shenanigans.
- Core damage-interaction systems. Unity3D works off of the idea of scripts or components being attatched to a single object. Imagine this to be somewhat similar to the Decorator pattern if you're not familiar with the idea of components, but with some differences that I will not get into now because I do not deem it worth the time of discussion and I really want to get to bed right now.
Essentially there is a component that can take damage, and a component that can give damage. They can exist on the same object (such as an enemy that can be hurt by the player's weapons but can damage the player if the player were unfortunate or masochistic enough to touch them) There's more to them than that, rules for when the damage taker and/or the take-ee are to report themselves as "finished" and ready to be destroyed, resistances for different damage types, limits to how much damage a take-ee can deal out, if that strength weakens over time or can only touch so many unique takers before it is deemed unusable, etc.
-Prototype level: Gets across the point, has plenty of targets, platforms, etc. to run players to and to tweak values to guns, player speeds, gravity, etc. Currently not super fun, which is not heartening, but I knew my values out of the box wouldn't feel so great, so plenty of time to tweak and continue with the idea.
Plus I tend to be highly critical of myself and my accomplishments, will release a more public prototype test this weekend to some friends to get better feedback.
TO-DO FOR NEXT WORK PERIOD (Likely Sunday)
-Expand prototype level (more targets, more platforms)
-Tweak player values (gravity, run speed)
-Tweak gun values (speed of "aiming" and projectile types, their speed, damage, falloff, adding in burst fire or shotguns, etc.)
-Preliminary art (not having everything being boxes)
Subscribe to:
Posts (Atom)