Arcade Battle Arena Challenge!

Make a game like the classics Bubble Bobble and Super Mario Bros 3 Battle Mode. Those games involve one or two players battling against waves of enemies on an arena.

Game Requirements

• The game must have:
  • Start screen
  • Key to return to the start screen
  • Score system
  • Minimum of 2 enemies with different behavior (AI)
  • Graphics at least for the UI, player and enemies
  • Sound effects at least for when the player is hurt and when an enemy is killed
• The actual gameplay must happen on a single screen (no camera translation)

Art Requirements

• The game can be 2D or 3D
• The art must use a maximum 16 colors palette
• The art must be your own

Tips

• An interesting game design approach of the two games is that they require the player to neutralize the enemy first, before killing it:
  • In the Super Mario Bros 3 Battle Mode, to kill an enemy, the player must first hit underneath the platform where the enemy is walking on
  • In Bubble Bobble, to kill an enemy, the player must first shot a bubble on the enemy
• You can quickly make sound effects on Chiptone
• You can decrease your color count by replacing two similar colors with a median between the two colors. This works nicely for similar dark colors or similar light colors
• Enemy behavior can involve:
  • Response to the environment. What is the kind of tile that the enemy is currently at? What are the kind of tiles that are in front or behind the enemy?
  • Response to the player. Where is the player? Is it too far away? Is it close? In front or behind? How the enemy will respond to that?
  • Motion pattern. Does the enemy walk on the platform and stop for some time? Does it fly? Games like Super Mario World are good examples with a great variety of enemy patterns.
• The tutorials on Youtube by Shaun Spalding teach some enemy programming. They are for Game Maker, but the logic can be translated to other game engine or framework:
  • " rel="external">
  • " rel="external">
  • " rel="external">

Duration

4 weeks - October 6, 2017 to November 3, 2017

Submission

Post on this thread only your entries:

• Link to the executable (specifying the platform)
• Screenshots: if the screenshots are too big, post just a few, if they are small, you can post more, just don't take the entire space
• A small post-mortem, in the same post of the entry, is encouraged, where you can share what went right, what went wrong, or just share a nifty trick
• Source-code link is encouraged

So can we use this topic for any dumb question we may have related to the project?  

If that's the case, then I have one: I would like to keep my #include "SDL.h" inside the source file rather than in the headers, is that the correct way? If so, I know how to forward declare struct SDL_Window; and struct SDL_Renderer; inside the header so that I can use pointers to those structs into it, but how do I forward declare a Uint32? 

I tried  "using Uint32 = uint32_t"  but for that to work I have to #include <cstdint> in the header... there is a smart way to use SDL Uint32 typedef without including SLD.h or <cstdint> in all my headers? Or should I just include SLD.h it in all my headers and it is not a big deal?

Made some progress, got my timer up and running, is fairly similar to the last one I've made but because of that practice, writing it from scratch went considerably faster (...hope I have no mistakes in it)  Unfortunately is templated so I have to keep the definitions in the same header... x_x

GameTimer.h:

#pragma once
#include <chrono>
using namespace std::chrono;

template<size_t T>
class GameTimer
{
	using TickDuration = duration < uint32_t, std::ratio<1, T>>;
	using TimePoint = time_point<steady_clock>;
	using FloatSeconds = duration<float>;

private://variables
	TimePoint AppStart;
	TimePoint Current;
	TimePoint NextUpdate;
	TickDuration UpdateRate;
	float DeltaT;

public://Methods
	GameTimer();
	GameTimer(const GameTimer&) = delete;
	GameTimer& operator=(const GameTimer&) = delete;
	GameTimer(GameTimer&&) = delete;
	GameTimer& operator=(GameTimer&&) = delete;

	void Tick();
	void Advance();
	float Interpolation();

	TimePoint CurrentTime()const { return Current; }
	TimePoint NextUpdateTime()const { return NextUpdate; }
	float DeltaTime()const { return DeltaT; };

};

template<size_t T>
GameTimer<T>::GameTimer() : 
	UpdateRate{ 1 }
{
	AppStart = Current = NextUpdate = steady_clock::now();
	DeltaT = duration_cast<FloatSeconds>(UpdateRate).count();
}

template<size_t T>
void GameTimer<T>::Tick()
{
	Current = steady_clock::now();
}

template<size_t T>
void GameTimer<T>::Advance()
{
	NextUpdate = Current + UpdateRate;
}

template<size_t T>
float  GameTimer<T>::Interpolation()
{
	auto Interpolation = duration_cast<FloatSeconds>(Current - (NextUpdate - UpdateRate)) / UpdateRate;
	return Interpolation*DeltaT;
}

Timer Usage:

void App::GameLoop()
{
	while (Running)
	{
		Timer->Tick();

		//Input
		SDL_Event Event;
		if (SDL_PollEvent(&Event))
		{
			switch (Event.type)
			{
				case SDL_QUIT:
				{
					Running = false;
				}
			}
		}

		//Update
		while(Timer->CurrentTime() > Timer->NextUpdateTime())
		{
			//Game->Update(Timer->DeltaTime());
			Timer->Advance();
		}

		//Draw
		//Game->Draw(Timer->Interpolation());
	}
}

12 hours ago, MarcusAseth said:

So can we use this topic for any dumb question we may have related to the project?  

If that's the case, then I have one: I would like to keep my #include "SDL.h" inside the source file rather than in the headers, is that the correct way? If so, I know how to forward declare struct SDL_Window; and struct SDL_Renderer; inside the header so that I can use pointers to those structs into it, but how do I forward declare a Uint32? 

I tried  "using Uint32 = uint32_t"  but for that to work I have to #include <cstdint> in the header... there is a smart way to use SDL Uint32 typedef without including SLD.h or <cstdint> in all my headers? Or should I just include SLD.h it in all my headers and it is not a big deal?

You should include sdl.h in the headers that need to see those functions.  One reason you might only include a header in a source file is to trigger rebuilding the source file only when that header is changed, but something like sdl your almost certainly not fiddling around with it's internal works, so there isn't much need to remove it from your headers.

I'm going to participate in this challenge as well, It's a good opportunity to flex the strengths of my framework and see how it holds up when assigned a random task.  thus far you can find my development progress here: https://github.com/slicer4ever/TriColor-Wars  I well be using a framework/engine i've built over the last couple years called Lightwave: https://github.com/slicer4ever/Lightwave

The goal is to support 1/2 player modes(possible over internet play well be included), i have an idea for 2 player mode of seperating keyboard/mouse controls to allow for local play.   I'm hoping to be mostly done within the next 48-72 hours, so let's see what happens.

I well likely try to push an update each night, and will include binarys after today's work as there should be something substancial to play by then.

15 hours ago, MarcusAseth said:

If that's the case, then I have one: I would like to keep my #include "SDL.h" inside the source file rather than in the headers, is that the correct way?

It's not wrong. Place the #include where you need it. If you add an SDL type inside your header, you probably will need to add the #include in your header, too. But, if you are not using any SDL type in the header, then you don't need to add the #include in the header.

15 hours ago, MarcusAseth said:

I tried  "using Uint32 = uint32_t"  but for that to work I have to #include <cstdint> in the header... there is a smart way to use SDL Uint32 typedef without including SLD.h or <cstdint> in all my headers? Or should I just include SLD.h it in all my headers and it is not a big deal?

It's not a big deal. As for the use of `uint32_t`, I think if you include the <cstdint> in some central header (a header that is used everywhere in your project), you can use the `uint32_t` anywhere where that your header is included.

Your main loop is more "pro" than mine, btw. I just went with the crude SDL_Delay() approach to run at ~60 FPS. Maybe I will improve later.

3 hours ago, slicer4ever said:

I'm going to participate in this challenge as well, It's a good opportunity to flex the strengths of my framework and see how it holds up when assigned a random task.  thus far you can find my development progress here: https://github.com/slicer4ever/TriColor-Wars  I well be using a framework/engine i've built over the last couple years called Lightwave: https://github.com/slicer4ever/Lightwave

I wasn't so bold to use my own engine :p, I still need to make some cross-platform improvements on it. That's why I will stick with SDL2.

3 hours ago, slicer4ever said:

The goal is to support 1/2 player modes(possible over internet play well be included), i have an idea for 2 player mode of seperating keyboard/mouse controls to allow for local play.   I'm hoping to be mostly done within the next 48-72 hours, so let's see what happens.

I well likely try to push an update each night, and will include binarys after today's work as there should be something substancial to play by then.

That's hecking cool. I'm curious how the mouse controls will be.

I'm going to make updates every day, too. I'm uploading the progress here https://github.com/ferreiradaselva/very-small-games.

6 hours ago, ferreiradaselva said:

Your main loop is more "pro" than mine, btw. I just went with the crude SDL_Delay() approach to run at ~60 FPS. Maybe I will improve later.

Thanks  That's thanks to you guys which linked me the correct learning materials about game loop few weeks ago in my other topic about the breakout game,so... I can't stress enough the importance of adding good teaching materials related to the challenge requirements, I hope everyone will follow this format

10 hours ago, ferreiradaselva said:

I wasn't so bold to use my own engine :p, I still need to make some cross-platform improvements on it. That's why I will stick with SDL2.

Like i said, this is another good opportunity to see how versatile it is for what my original goals were, what's the point of writing such things if you never make use of them?

As for today i got most of the main components done (https://github.com/slicer4ever/TriColor-Wars) and am now working on the gameplay, I still have my color switching element to work in mechanically, then i'll expand the enemys, toss in some sounds and try to prettify the background a bit.  at that point i'll decide if i want to try implementing mp or not at that stage. Creating my own art, and adhering to a 16 color pallete has been a bit challenging though, at the moment the game is basically a 1/2 player asteroid clone, tomorrow i hope to get some interesting enemy and mechanics in place :).

a quick video of gameplay:

got a not so useful static piece of text on the screen:

Maybe I should do a button class next? Or I'll leave it for last and jump straight into the Play state.

Hey guys, I have a question,regarding this code:

void MenuState::Draw(float interpolation)
{
	SDL_Surface* TempText = TTF_RenderText_Blended(BubbleFont.GetFont(), "Play", SDL_Color{ 165,161,141,255 });
	SDL_Texture* TextTexture = SDL_CreateTextureFromSurface(WindowInfo.Renderer, TempText);
	
	//Draw
	SDL_SetRenderDrawColor(WindowInfo.Renderer, 40, 34, 50, 255);
	SDL_RenderClear(WindowInfo.Renderer);
	SDL_RenderCopy(WindowInfo.Renderer, TextTexture, NULL, &PlayPosition);
	SDL_RenderPresent(WindowInfo.Renderer);

	//cleanup
	SDL_FreeSurface(TempText);
	SDL_DestroyTexture(TextTexture);
}

Now I realize this text is static so I could set the texture once on the constructor,free the surfance once, and only destroy the texture once on the destructor, but for the sake of argument let's assume that my text change shade over time so now I need to do this FreeSurface() and DestroyTexture() on every Draw() iteration.   If that where the case, would this still be the right way of doing it? Or like drawing the surface directly would be preferred?

This question extends to pretty much all the game UI, since it will have score that need to be refreshed.

20 hours ago, slicer4ever said:

As for today i got most of the main components done (https://github.com/slicer4ever/TriColor-Wars) and am now working on the gameplay, I still have my color switching element to work in mechanically, then i'll expand the enemys, toss in some sounds and try to prettify the background a bit.  at that point i'll decide if i want to try implementing mp or not at that stage. Creating my own art, and adhering to a 16 color pallete has been a bit challenging though, at the moment the game is basically a 1/2 player asteroid clone, tomorrow i hope to get some interesting enemy and mechanics in place :).

That was fast.

I added that 16 color limit because a lot of art beginners use too much colors without any meaning. Limiting the color usage helps to develop the art skills and a sense of adding colors only when necessary.

11 hours ago, MarcusAseth said:

Now I realize this text is static so I could set the texture once on the constructor,free the surfance once, and only destroy the texture once on the destructor, but for the sake of argument let's assume that my text change shade over time so now I need to do this FreeSurface() and DestroyTexture() on every Draw() iteration.   If that where the case, would this still be the right way of doing it? Or like drawing the surface directly would be preferred?

Creating the texture a single time would be a better option. Then draw that text surface on the texture. But, we are talking about a small game here. It's likely that creating and destroying those every frame won't be a performance problem. For bigger projects? You probably want to allocate some content and keep them allocated as long as you can.

Current status of my project:

Content loading. I automated my build system to convert the PNG (texture atlas) to a c header containing the PNG in RGBA format. That way, I don't need to ship the executable with a *.dat or *.zip or even the PNG loose. I will do the same for sound effects.

Main loop. I fixed that main loop, and I have rendering working. I'm not using accelerated hardware (bwahahaha). Using SDL_Surface is easier to deal with. VERY limiting, but it's ok for this project.

The logic of the rendering is this:

1. Get the window surface
2. Create a "view" surface
3. Create a "texture" surface for the texture (atlas)
   1. Loop start
   2. Clear "view" surface
   3. Draw portion of the "texture" surface on the "view" surface
   4. Draw "view" surface scaled on the window surface
   5. Loop end

The reason I'm drawing on a "view" surface is to keep the rendering "pixel-perfect".

1 hour ago, ferreiradaselva said:

For bigger projects? You probably want to allocate some content and keep them allocated as long as you can.

So how would bigger projects handle the rendering of a text that change shade at every draw, in the specific?

Do you mean like allocating a sequence of pre-rendered images of all the shades for a given piece of text?