2d "platform" game suggestions wanted

[TBMan]

I'm thinking about doing an old style platform type game where the character has to jump up and get items for points, goes up levels on the screen, etc. Any game suggestions to clone?  I'm also going to make a cell animation utility to create the character animation sequences. I did one way back when so I'll see what I can bring forward from that code.

[Lulu]

Hi TBMan,
For performance, my advice will be to use OpenGL (or similar) to write the game.

I'm writting a 2D game (https://forum.lazarus.freepascal.org/index.php/topic,68021.0.html) with OpenGL. I've started to write a framework to simplify things since some years now. The framework is called OGLCScene (because it use LCL TOpenGLContext), it is sufficiently mature to easily create texture, sprites, collision check, camera effects, animations, etc...
You can find the framework here: https://github.com/Lulu04/OGLCScene there is a lot of examples.

There is also BGRABitmap that offer an OpenGL support, search in this forum, there is a lot of topic about.

There is also ZenGL https://forum.lazarus.freepascal.org/index.php/topic,52581.0.html I started to learn OpenGL with ZenGL.

For sound there is ALSound, its based on OpenAL-Soft, it work for Windows, Linux and MacOS (intel only). The library is here: https://github.com/Lulu04/ALSound

For playing sounds, there is also UOS, it is crossplatform. https://github.com/fredvs/uos/

That's a lot of things, cheer up!


EDIT:

Any game suggestions to clone?

I'm sorry, I think I first misunderstood your question...

[TRon]

I'm thinking about doing an old style platform type game where the character has to jump up and get items for points, goes up levels on the screen, etc. Any game suggestions to clone?

You mean literally go up levels as in f.e. kid icarus or can it be something like turrican and/or gods as well ?

[TBMan]

I'm thinking about doing an old style platform type game where the character has to jump up and get items for points, goes up levels on the screen, etc. Any game suggestions to clone?

You mean literally go up levels as in f.e. kid icarus or can it be something like turrican and/or gods as well ?

I don't know. I'll look at those. I was thinking along the lines of Donkey Kong. Maybe I'll try to duplicate this a bit and see what I learn from it.

https://www.youtube.com/watch?v=KJkcNP4VkiM

[TRon]

Ah ok, got it. In that case the aforementioned games are probably too new/modern.

Then perhaps more in the style of The goonies or Rupert and the ice castle where each level (or part of a level) has its own screen that is being switched in view instead of continues scrolling. My level of brain rot is pretty high in not being able to recall any titles (probably suppressed memories to not get completely insane  )

[Lulu]

My level of brain rot is pretty high in not being able to recall any titles (probably suppressed memories to not get completely insane  )

less than me who didn't understand the question! 

[TRon]

less than me who didn't understand the question! 

I don't seem to understand about 80% of the questions asked so we seem to have the same issue.

For some reason or another I simply can't recall any of those games played when I was younger. The only title that comes to mind right now is something like lode runner or burger time (the latter which visually behaves more like pac-man).

[TBMan]

I have to kick around how to do the data for this.

Donkey Kong (after kong climbs and barrels start to go down):

Flat ramp, ramps that go down left or right. A barrel going across a flat ramp has no change in y, but a down ramp effects y as y := y+4, for example, then animate until to end of current ramp, then down to the next down ramp or level or drop down to next level ramp.   I think creating the animation sprites will be the time consuming part and not so much the code.

[TRon]

Flat ramp, ramps that go down left or right. A barrel going across a flat ramp has no change in y, but a down ramp effects y as y := y+4, for example, then animate until to end of current ramp, then down to the next down ramp or level or drop down to next level ramp.

At least the ramps themselves are static which means you can use a linear equation that matches the slope. Can be pre-calculated on a per level base if that makes things easier.

I think creating the animation sprites will be the time consuming part and not so much the code.

For sure that will take up a lot of time unless you are able to borrow an existing set of animations. One the other hand for verifying the game mechanics it isn't really necessary (simple bounding boxes will do to be able to test the actual game-mechanics). That is unless you wish to make it pixel perfect (right from the start).

[TBMan]

Flat ramp, ramps that go down left or right. A barrel going across a flat ramp has no change in y, but a down ramp effects y as y := y+4, for example, then animate until to end of current ramp, then down to the next down ramp or level or drop down to next level ramp.

At least the ramps themselves are static which means you can use a linear equation that matches the slope. Can be pre-calculated on a per level base if that makes things easier.

I think creating the animation sprites will be the time consuming part and not so much the code.

For sure that will take up a lot of time unless you are able to borrow an existing set of animations. One the other hand for verifying the game mechanics it isn't really necessary (simple bounding boxes will do to be able to test the actual game-mechanics). That is unless you wish to make it pixel perfect (right from the start).

Yes, usually I get the raw mechanics down using simple graphics and then add complexity as I go.   

[Seenkao]

Проблема в создании игры, не в самой игре. Механики достаточно просто добавляются и игра сама по себе не сложно делается.
Проблемы появляются, когда надо создавать дополнительные средства программы, это: меню, диалоги, карты и взаимодействие игры с этим всем.

Если вы меня поймёте, то одну из проблем можно решить достаточно несложно. Надо понять, что любая программа, это - меню. Какой бы момент игры не проигрывался, меню всегда работает. Программа может не работать, а меню будет. Меню - это как оболочка надо программой. Надо запустить игру, выбираете пункт меню и открывается подменю, где работает игра.

"Выше" меню могут быть только диалоги, которые нужны для информирования человека-игрока (это не значит, что меню не будет работать, это означает, что меню в это время может быть на паузе).

Нужно это вам или нет, не знаю.
А по графике, я бы не заморачивался. Сначала делается игра, а уже на игру навешивается графика. Сделайте так, чтоб, допустим, столкновения спрайтов можно было менять для объекта достаточно просто (и подобные вещи), тогда графику будет не сложно добавить. Делайте кружки, треугольники, квадраты разных цветов, а когда будет готова основа, меняйте их на спрайты.

---------------------------------------------------------------
Google translate:
The problem in creating a game is not in the game itself. Mechanics are quite easy to add and the game itself is not difficult to make.
Problems arise when you need to create additional program tools, these are: menus, dialogs, maps and the game's interaction with all of this.

If you understand me, then one of the problems can be solved quite easily. You need to understand that any program is a menu. No matter what moment of the game is played, the menu always works. The program may not work, but the menu will. The menu is like a shell over the program. You need to start the game, select a menu item and a submenu opens where the game works.

"Above" the menu there can only be dialogs that are needed to inform the human player (this does not mean that the menu will not work, it means that the menu may be paused at this time).

Whether you need this or not, I do not know.
As for graphics, I would not bother. First, the game is made, and then graphics are hung on the game. Make it so that, for example, sprite collisions can be changed for an object quite easily (and similar things), then it will not be difficult to add graphics. Make circles, triangles, squares of different colors, and when the base is ready, change them to sprites.

[TBMan]

Проблема в создании игры, не в самой игре. Механики достаточно просто добавляются и игра сама по себе не сложно делается.
Проблемы появляются, когда надо создавать дополнительные средства программы, это: меню, диалоги, карты и взаимодействие игры с этим всем.

Если вы меня поймёте, то одну из проблем можно решить достаточно несложно. Надо понять, что любая программа, это - меню. Какой бы момент игры не проигрывался, меню всегда работает. Программа может не работать, а меню будет. Меню - это как оболочка надо программой. Надо запустить игру, выбираете пункт меню и открывается подменю, где работает игра.

"Выше" меню могут быть только диалоги, которые нужны для информирования человека-игрока (это не значит, что меню не будет работать, это означает, что меню в это время может быть на паузе).

Нужно это вам или нет, не знаю.
А по графике, я бы не заморачивался. Сначала делается игра, а уже на игру навешивается графика. Сделайте так, чтоб, допустим, столкновения спрайтов можно было менять для объекта достаточно просто (и подобные вещи), тогда графику будет не сложно добавить. Делайте кружки, треугольники, квадраты разных цветов, а когда будет готова основа, меняйте их на спрайты.

---------------------------------------------------------------
Google translate:
The problem in creating a game is not in the game itself. Mechanics are quite easy to add and the game itself is not difficult to make.
Problems arise when you need to create additional program tools, these are: menus, dialogs, maps and the game's interaction with all of this.

If you understand me, then one of the problems can be solved quite easily. You need to understand that any program is a menu. No matter what moment of the game is played, the menu always works. The program may not work, but the menu will. The menu is like a shell over the program. You need to start the game, select a menu item and a submenu opens where the game works.

"Above" the menu there can only be dialogs that are needed to inform the human player (this does not mean that the menu will not work, it means that the menu may be paused at this time).

Whether you need this or not, I do not know.
As for graphics, I would not bother. First, the game is made, and then graphics are hung on the game. Make it so that, for example, sprite collisions can be changed for an object quite easily (and similar things), then it will not be difficult to add graphics. Make circles, triangles, squares of different colors, and when the base is ready, change them to sprites.

I have a gui OOP interface that I created. That's always fun. File open dialogs are an interesting animal.

[sfeinst]

I'm thinking about doing an old style platform type game where the character has to jump up and get items for points, goes up levels on the screen, etc. Any game suggestions to clone?  I'm also going to make a cell animation utility to create the character animation sequences. I did one way back when so I'll see what I can bring forward from that code.

I was always a big Lode Runner fan.
I remember playing Commander Keen on DOS as well (I think it was supposed to be similar to Mario Brothers but not sure since I never played Mario Brothers).

[Bart]

Lemmings 2?

Bart

[flowCRANE]

Ice Climber, but procedurally generated (infinite, like Icy Tower).