Animation in my nation

So another week has past, another artifact accomplished and perfected. A new thing has been learned this week. animations.

if you haven’t been paying attention in school I guess I’ll go over the basics.
You create a class that allows itself to have a string of pictures.
These depicts an animation and you line them up perfectly and in order.
You take all of these images and load them into the program as just ONE image.
You then created small frames of where you want to look at this specific time and for how long of a duration on this ONE image.
finish it off by putting in more and more methods of genius into the class
like pausing.

So I probably understood what I was doing with animations about two days ago.
It’s like one of those days you fit every puzzle in your brain and understand every step you just took when seconds before you were a nerve wreaking moron just typing away until stuff showed up.

So each object of animation I create need to have a few details included before I could actually use them.
The program loads a sprite for lets say an enemy, when inside the enemy class I create an Animation Object and send the sprite I just loaded, a float duration for each frame and two booleans(if paused and if looped) with it as a parameter.

When this is done I call to a method inside the animation called AddFrame that point a rectangle you create that’s fitting for you enemy and you just point it where you want a frame to be. It’s that simple hehehe…

I wont lie, it took a senior, one of the smartest guys in class and a week to figure all this crap out. I’ve been playing around with it since and finally gotten everything in order now.
I apparently didn’t understand the concept of setOrigin that SFML has and had way to much to think about. There have been a few changes in the group that wasn’t planned and we’ve made some cuts. It’s not been great but this week have really been an eye opener. If anything I see now that this is something that I really want to do.
I have been having is creating my high score class which I WONT be talking about anytime soon.
As a bonus I created some kind of score feedback(pictures will come soon, on the wrong comp) which will be our picture for this weeks post.
I tried to keep this one short so thanks for reading and cheers.

 

Treshhold overcomed

This week has been a series of half-assed opinions and motivations boosts for our group. We’ve been working on getting our orientation between our states better handled, getting sound into our game, customizing our character and getting a score to show up on the screen.
Our producer have been tackled with the presentation assignment and working out the documentation for our group while I took a leave of absent from being a lead designer(when it came to documentation) and focused more on programming.

We have been busy though, like always I’ve been tasked with questioning every artist work to make sure it’s final cut ready before it event shows up on the screen. It’s been done this way because I find it easier denying everything until perfected so I can have my artists working on future projects faster.

Like I said before, we’ve had it rough this week. Two meetings have been had, one was for with our guest teacher bashing our game to oblivion and making us question the whole thing while our main teacher doing the same and asking for proof why we should keep our mechanics the way we implemented them. A lot of philosophical question arose and most answered after we had our meet and greet with the rest of the groups testing each other games. Simply put; An arcade game before never really explained why its designed this way. We cannot care how many people will not like our game, we are interested in making a game that caters to our specific fan group we initially started with. Easy to pick up, hard to play and even harder to master. We made a distinct change where in the future we will have a free move option for simplified tactics but I doubt this will be implemented.

We had some troubles working with the design of the truck. It wasn’t believable according to everybody and finally us that it was a truck. We had to make a change, quickly. There was some trucks Seamus already had put into works that we had a look at and made a decision to switch back to a truck made as a placeholder. It’s been a working success other than that and I think as a glorified QA we’ve made progress in the field of effectiveness.

To the programming part! I’ve been assigned with the task of fixing the states and getting a score shown on the screen.

My main concern with states was a hit and a miss as a first look at it but now I see that it was simply a shotgun shot with two pellets hitting the rabbit and 18 right on the tree. I wanted to do something similar to what my partner at my last project did, getting the whole engine class into each state so I can use the objects created in there, everywhere. I started out putting the engine in State.h and the StateManager.h/cpp to make sure it was everywhere then using a ‘this’ function inside the initialize method in the engine class and attached it to each class. It worked..somewhat but I lost my input objects. This was after I took away all the input and gameobjectmanager objects from each state because I thought the engine would refer back to all the objects easier. Nothing worked, I looked everywhere for the problem chasing every callstack clue but I couldn’t find it!

I finally consulted my old partner and found out that I’ve been tackling this the hard way, there is no need to have an engine in state.h and the statemanager, these are only there to give a static virtual method into every state and the statemanager just refers correctly for every state to understand its methods better. So now I’ve deleted all evidence of engine objects everywhere except the states, still doesn’t work!

I consulted a teacher assistant and was told I am a total idiot, I was told that the problem was that the engine->m_input was initialized after every manager took it in so when they tried to use the object it was a nullptr(not pointing to anything in the heap memory). I simply took that line of code and changed it from:

m_statemanager = new StateManager();
m_window = new sf::RenderWindow(sf::VideoMode(Config::getInt(“window_w”, 0), Config::getInt(“window_h”, 0)), “SFML window”);
m_spritemanager = new SpriteManager();
m_gom = new GameObjectManager(m_spritemanager, m_window, m_input);
m_buttonmanager = new ButtonManager(m_spritemanager, m_input);
m_input = new InputManager(m_window);

to:

m_statemanager = new StateManager();
m_window = new sf::RenderWindow(sf::VideoMode(Config::getInt(“window_w”, 0),               Config::getInt(“window_h”, 0)), “SFML window”);
m_spritemanager = new SpriteManager();
m_input = new InputManager(m_window);
m_gom = new GameObjectManager(m_spritemanager, m_window, m_input);
m_buttonmanager = new ButtonManager(m_spritemanager, m_input);
The benefits with having an engine object there have made us more flexible with using the draw method and update method better in states which will make it easier for us to implement new dynamics into the game. I demonstrated this by putting a start screen up, took me 2 hours but hey faster than it would have creating a class for it!

Now to the score. I consulted our meeting with our mentor Elias about this. I was trying to figure out how to go by creating a Score class. We talked about what kind of methods it needed to have and how we should fill these methods. The methods became:

Public:
konstruct
destruct
Getscore
PutInScore
BuyStuff
private:
int score

and filling the methods became:

stringstream ss;
sf::String sfScore= “Score”;
int iScore = 10;
sf::Text sfText;

ss<<iScore;
sfText.setString(sfScore + ss.str());

When we started writing the code for GameObjectManager we found room to comment where the score should call for it’s “PutInScore” method so implementing all of this was a breeze but I ran into a snag. I couldn’t draw it. I found out quickly that I didn’t have a draw method so I implemented it, took the stringstream and setstring and put it there…string doesn’t work. I guess the problem was somewhere else. Checking everywhere, moving the sf::text* and sf::font* objects to the construct, back to draw, back to construct, to public: in the header file, back to private made me understand something. Pointers weren’t the design I needed to make, I had to change my philosophy in having pointers in everything and took them away. Now the draw method works and everything was set to private and into it’s “rightful” place. And low and behold:

That’s about what I’ve been doing at the moment. My final work will be helping my colleague with the customizing of our avatar and try to get my “BuyStuff” method in score before the alpha but if any teacher is reading this – CANNOT PROMISE CUSTOMIZE IN ALPHA SORRY BRUH –

Cheers

Ladbon

Arianas Travels

Since the 19th me and five others have been working parallel to another Game Programming II course is a course named Introduction to Game Development.
From now on I will be blogging about how my position as lead designer have taken it’s toll and what have been going to my mind during the choices we’ve taken.

The development went through picking a finished game design document, had a brainstorm about what the group was able to do and specifically me had to make sure the scope set will be able to be finished before the deadlines.

Assessing the skills of each member had be made sure before the group could get the highest grade it’s able to get.  I guess the hardest part to think about was how to cut stuff out of the scope. Our programming skills wasn’t great but our artists will be able to create tons of different art so the group could have massive amount of art with very little code to show for it. I therefore had to change the main ways we play the game. The initial scope became a static hp bar that enemies wants to destroy it while you move around the hp bar shooting them down.

The group started with a blitz, I started making a power point presentation about this game using the formal design document we got from our teacher. The days that followed our producer Oscar started writing a document encompassing everything we’ve talked about and what I’ve written. Oscar starts writing down everything, schedule, scope, rules and even started with the MDA before the first week has finished.

So to recap the scope was made before we even started, the positions had already been taken, the schedule, game design and a power point presentation with a flowchart of how the program will be designed has been 90% finished. It has become clear that documentation wont be our problem but problems aren’t few.

The library the group will be using is SFML, a easy manageable set of commands that will make the programmers lives easier.

The difficulties the programmers in the group are faced with is how to create a foundation of code that can be build upon if the group ever reach the scope before the deadline(oh how naive I was). We decided starting with creating the states, engine and being able to navigate between them with key presses. I had the duty to create an input manager class suitable for our game while our lead programmer started writing the game in the SDL library so we know what we are getting ourselves into.

The difficulties we had with states was our inexperience with the code cause neither of us had the duty of writing it the last project. The programmer in duty of this is Laban. While I was implementing the code for the InputManager I noticed the problems almost immediately. SFML already has a way of getting real time input but not KeyDownOnce though it’s library could easily understand Mouse input in a way we want it. The reason I wanted an InputManager was because its worth the training and it helps all programmers understand a way of implementing an input class in a way that suits the game, not the inability of the library. I didn’t really invent something new here though, the last project had already made methods able to register input for probably any 2d game out there so we were in luck(!).
The issues I noticed was the inefficient way the states were written so I had to change the HandleEvent() and Update() method while I implemented a UpdateDeltatime()  method for the Engine. I even changed the way you run a window in the Run() method in the Engine with a bool instead of having Window.IsOpen(){} and but that method into HandleEvent in the InputManager. Problem was that the Inputs wasn’t going anywhere, in no way could we get any input to pass through the InputManager->HandleEvent(). After getting help from our brilliant classmate(Thomas Småland) we understood that having both m_running bool AND Window.IsOpen() into the loop in InputManager->HandleEvent() we changed it to:

sf::Event event;
while(window->pollEvent(event))
{
if(event.type == sf::Event::Closed)
{
running = false;
}

This effectively solved the whole issue and we finally could get the Input working and we were on track on creating the Sprite Class, SpriteManager class and the difficulties on creating a DrawManager(OH HOW NAIVE).

Again, being a lead designer I’ve become the guy that makes the tough calls. Constant calls of upgrading the game both from teachers and group members have made me think about what our future will be if we actually fill the scope. Before I finish this post let me show you a teaser of what I will write about next week:

*The programming roles we have and what difficulties and ease we’ve had with the development
*The more tough calls
*The directions of art the group are taking compared to the first design document

Now for a picture!

OK I have to give recognition to the people that helped us make this possible

*Laban Programmer(our group)*Tomas Småland(not our group)
*Viktor Lead Programmer(our group)

Thanks for reading, cheers and Much love.