Man(ager) over board! Post #4

Sunday afternoon, and I haven’t blogged since thursday I think. That’s rather bad.

I’ve spent the weekend working on our statemanager, or rather our so called LoadingState, which is pretty much just a splash screen to show a picture before heading into a menu and then the game. Making that happen, the whole showing a picture->switch to the menu is simple, although we don’t actuallly have a menu right now. So it just heads into the game which is fine.

The more I’ve been trying to understand how we’re supposed to get a statemanager to work after we have the actual game, the more frustrated I’ve gotten over not doing it as the very first thing. This has led to us thinking over what we actually need for our game, and now we’ve decided that the statemanager (no matter how neat that stuff is) isn’t a priority. Not for this. We have the game, we need to implement a win/defeat condition which should be rather simple (it already counts the bricks so just adding a “win” to it when the counter reaches 0 should do the trick), and to make sure we have the points we need to finish the assignment we will get going on the audio too. Fabian got the animation to work today so there’s that too.

So to summarize the weekend: We’ve got the animation working, we figured that the statemanager should’ve probably been made first and doing it now will take too much time so we’re skipping it for other things we can do before deadline to make sure the game is presentable and make us pass. It kinda sucks spending a weekend on something and deciding that we’ll skip it (at least for now) but yeah, it’s still experience and for the future we have a slightly better idea of what to prioritize. Oh yeah, and tomorrow I’ll probably make a life-counter so you don’t instantly lose the entire game if the ball hits bottom once, that’ll go hand in hand with the defeat condition we’ll work on next.

Off-topic: Time for FOOOOOD.

Bricks, bricks and more BRIIIICKS! Post #3, I believe

So, due to our frustration from yesterday we both forgot to write in our precious blog. The mission of the day was to get our new and shiny bricks to load from a textfile, but it just wouldn’t work. I think we sat there for around 3 hours and we couldn’t understand at all what it was thanks to visual studio not showing any errors either. Thing just wouldn’t build.

But today! Today we came up with the great idea of using vectors instead of arrays for the bricks and magically it worked. The collision works, kind of, so we’ve made progress there too. We have some issues with the collision when there are lots of bricks close to each other on a row. The ball wants to jump in between and start doing flips, which isn’t exactly what we envisioned.

New day tomorrow and the plan is to split the work more instead of working together, so Fabian will stick with the bricks and I’ll move on to the statemanager.  We’ll see how that works out!

Post #2 Collision, Directions, Audio

Today has been our first day of working together in the classroom. We’ve dealt mostly with directions and the collision of the ball in relation to the paddle (aka playerobject). We’ve had some.. misfortune with how the ball acts when it collides with different objects in the game. For the most time it acts the way we want, but sometimes it just suddenly changes direction completely and heads to a new way. We like to call it an official feature but yeah, we’ll try to fix that tomorrow or so.

Due to unforeseen events we have now begun slightly with audio as well, but that is mostly just setting up the source and header files, we haven’t added any actual sound yet as we’re not done with the things that will make a sound later on.

Will try to make progress with making bricks disappear when hit later tonight, or else at our meeting tomorrow.

Plan/Schedule – My first post for the assignment

We’ve had some issues with our blogs and networks over the christmas “break”, and as such only one of us has been writing blog posts. But alas, now we’re both up and running and we can both share our coding days.

As we are rather inexperienced we’ve had issues setting up specific days for every part we need to work on. So rather than doing so, we thought we’d just set up how many hours we would work per day, as well as set up a checklist for what we need to work on.

We set them up in different parts for what we need to get done first, although it’s rather tricky as some parts work very much in relation to each other, so we will most likely jump a bit back and forth a bit. It might not be the most effective planning of all time, but it’s our first and we’ll need to experiment quite a bit. Live and learn, etc.

Part one:

  • Main
  • Engine
  • GameObject (PlayerObject)
  • Vector2
  • DrawManager
  • Sprite
  • SpriteManager

Part two:

  • Level
  • InputeManager
  • BallObject
  • BlockObject
  • Collider

Part three:

  • State
  • StateManager
  • MenuState
  • OptionsState
  • GameState
  • AnimationManager
  • SoundManager
  • MusicManager

When needed: Log

As of this post we’ve already began, as you can read about in Fabian’s blog. The game we’re making is Outbreak, and right now we have a controllable playerobject and a moving ball that collides somewhat neatly with the player, objects drawn in the game and walls. Much progress yet to be made.

Game development & programming