SDL2 i Qt

Ja nie używam ani SDL, ani Qt - piszę w VisualStudio Microsoftu

1) Grałem w to kiedyś, w jakiej prehistorii, pewnie większość obecnie tu piszących była w fazie co najwyżej projektu

Statyczna wersja gry (czyli bez animacji) ale jako graficzna aplikacja Windows nie jest szczególnie trudna - trochę łatwiej było by ją napisać w VisualBasic lub C# niż w C++

Ale może lepiej było by to napisać na Androida - tam łatwiej włączyć animację

2) To prosty program - logika oczywista - jedyny problem to rozłożenie kontrolek i podpięcie jakiejś bazy danych.

To, że te programy nie są zbyt skomplikowane, to nie znaczy, że nie będą czasochłonne, na pewno oba nadają się jako projekty do nauczenia się czegoś.

A Sokobana tez pisałem własnego, poziomy skopiowałem z oryginalnego kodu, gra była w oknie windowsowym, oczywiście bez animacji, ale ze statystyką liczby kroków i przesunięć oraz możliwością cofania o dowolną liczbę kroków, zapisem najlepszych wyników oraz zapisem i odczytem stanu gry. Tyle, że jak już przeszedłem wszystkie poziomy to przestało to mnie bawić

Oczywiście, że jest wykonalny.

Czy ja wiem ... Uważam, że stworzenie gry jest raczej o wiele trudniejsze. Musisz zaprojektować, różne skrypty, ustawić odpowiednie miejsca, w których skrypt ten jest uruchamiany. Musisz także zaprojektować AI(Artifical Intelligence), kolizje wszystkich postaci i reagowanie na te kolizje ... Mógłbym się tu jeszcze długo rozpisywać, ale napisałem Ci taką listę, po to, by uświadomić Ci, że jednak stworzenie gry jest trudnym zadaniem.

Qt jest zaprojektowany w całości obiektowo, natomiast biblioteka SDL powstała pod C i oczywiście można jej używać także w C++. Obie biblioteki są przeznaczone do innych rozwiązań. Jeżeli chcesz napisać program wspomniany w punkcie 2), to uważam, że lepiej zrobić go w Qt, bo biblioteka ta jest właśnie przeznaczona do takich zastosowań. Natomiast do projektu w punkcie 1) polecam właśnie SDL2 lub OpenGL.

Ale skąd takie przypuszczenia?

Tworzenie w konsoli jest nieco problematyczne i wiem to ze swojego doświadczenia. Niby możesz użyć: system("cls"); Do imitacji czyszczenia mapy, a do renderowania: cout << ...;
ale nie jest to najlepsze rozwiązanie. Jeżeli umiesz choć trochę programowac obiektowo, wiesz co to dziedziczenie i polimorfizm, spokojnie możesz wziąć się za grafikę. Najważniejsze jest stworzenie takiej struktury projektowej, by mogła być ona rozszerzalna w przyszłości.

Co do SDL polecam ten tutorial:
http://lazyfoo.net/tutorials/SDL/13

To możesz jak najbardziej zrobić w konsoli, ale wyswietlanie tekstu jako grafiki nie jest wcale trudne.

Pozdrawiam. Jakbyś miał więcej pytań to pisz

Czy to nie za kiepska okazja? Jeżeli chcesz lepiej poznać świat obiektówki, to najlepszą nawet nie okazją a drogą jest codzienne jej stosowania na zmianę z dokształcaniem, czytaniem, pytaniem się. Nawet tu na spoju, najprostsze zadania można rozwiązywać w dowolny sposób, i nie trzeba stosować ani OOP ani zaawansowanego C/C++, aby dostać AC. Ale czy nie jest to wyśmienita okazja do nauki i poznawania, robiąc każde, nawet najprostsze zadanie obiektowo?

Pisanie programów, to teraz już praca zespołowa. Nie znaczy, że nie możesz samodzielnie.

Moim zdaniem większość gier nie ma sensu, nie są edukacyjne [chyba, że dla piszącego grę], a dodatkowo mogą powodować uzaleźnienia jak wszelkie inne używki. [poczytaj "komputerowy ćpun"].

Programów do nauki za pomocą quizu jest całe multum ale ich użyteczność do nauki jest średnia - zależy od motywacji uczącego, systematyczności i od sensownej [i dużej] bazy pytań i odpowiedzi.

==========
Był też Bouder Dash (np C64 ) <-- https://www.youtube.com/watch?v=FiEVfa1OK_o4
Kiedyś używałem SuperMemo - programu typu Pytacz Master - i pierwsze wersje działały w trybie konsoli - pod dosem.
==========
Czyszczenie i używanie konsoli to nie tylko sys("clear"), cin, cout, ale przede wszystkim pisanie w dowolnym punkcie ekranu, w dowolnym kolorze, w dowolnym okienku tekstowym, ramki, menu itd, i aby to ułatwić powstały biblioteki np ncurses.
==========
Do pisania gier można użyć też jednego z dostępnych silników gier, ale tu chyba bardziej liczy się dobry pomysł, a dopiero potem można ubrać go na początku w skromne szatki konsoli a dopiero potem w grafikę np 3D.
===========
Jeżeli gra z grafiką, to w zespole powinien "znaleźć się" dobry grafik. [lub samodzielna nauka programów typu gimp, blender itd]
===========
Efekty [efektywne] dźwiękowe - muzyk [lub samodzielna nauka podstaw muzyki i programów do tworzenia i przetważania hałasu ]
==========

Hm
Na razie tyle, aby Cię zbytnio nie zniechęcać.
============
I jeszcze jedno, twoje pomysły to raczej programy dłuższe od typowych,najłatwiejszych kodów wysyłanych na SPOja, więc czytelne pisanie i sensowne komentowanie będzie w twoich kodach dużo bardziej ważne.
Jeżeli twój guru [to odnośnie rozmowy na pw] mówi Ci, że piszesz trudno czytelny kod, powinieneś natychmiast spytać go, dlaczego tak uważa. Czy się zastosujesz do jego uwag, to już inna sprawa. Estetyka kodu, to indywidualna sprawa, i każdy ma swój styl, ale powinnien on być w granicach rozsądku i pewnych standartów - tu znowu kłaniają się książki, i czytanie kodów mistrzów. Jeżeli nie, to będzi Ci dużo trudniej uzyskać pomoc od innego kodera, który będzie musiał się przegryźć przez zawiłości twojego kodu.

http://ksiegarnia.pwn.pl/Komputerowy-cpun,142344390,p.html4

Sam twój pomysł nie jest zły, natomiast to że trochę go krytykuję, nie wynika z miłości do SPOJ'a. Może czepiam się słówek, ale wydaje mi się, że masz [jak wielu innych] złe podejście. Jeżeli chcesz "poznać lepiej świat obiektówki" to nie rób tego przy jakiejś okazji. To samo dotyczy zaawansowanego c/c++. Jeżeli tego chcesz, to rób to w każdym momencie i w każdej sytuacji, programując namet mikro mikroprogramiki - rozwiązania zadań na SPOJu - przy okazji poznając algorytmy

Pisanie programów to jedyny sposób i jedyna metoda nauki i doskonalenia umiejętności programowania [kodowania]. Pisać można po to aby np rozwiązywać kolejne zadania na spoju [czy innym konteście], ale można też dla kogoś lub dla siebie. Gdy piszemy dla kogoś [znajomego] lub dla siebie, to najlepiej by było, aby programy były użyteczne i używane i żyły dalszym własnym życiem.

Jeżeli nie masz pomysłu, na program, rozwiązujący jakiś problem, którego jeszcze nie ma, to realizuj w ostateczności twoje pomysły. Ale jeszcze raz. Czy program typu quizu nie jest za mało ambitny? Programów takiego typu jest całe multum, a problemem są bazy, a nie program. Poczytaj: https://pl.wikipedia.org/wiki/SuperMemo4
Są też dostępne otwarto źródłowe programy tego typu, np anki - gdzie można podpatrzeć jak robią to inni.

W twoim wypadku i na twoim miejscu, pomyślałbym o napisaniu jakiejś aplikacji, lub komputerowej graficznej vizualizacji procesów chemicznych. Porozmawiałbym [dowiedział się] czy istnieje możliwość napisania jakiegoś użytecznego i potrzebnego programu [aplikacji] tego typu z prowadzącymi, a jeszcze lepiej, czy istnieje możliwość napisania pracy końcowej, której podstawą lub elementem byłaby takiego typu aplikacja. Byłoby to połączenie twojej przyszłej profesji z zainteresowaniami i jeżeli by się to udało, sądzę, że dużo lepiej wyglądałoby w twoim przyszłym portfolio niż to że napisałeś samodzielnie renimiscencję starej gry komputerowej czy program typu quiz z GUI - oczywiście pod warunkiem, że nie zamierzasz związać swojej przyszłej kariery z branżą gier komputerowych lecz myślisz o procesach chemicznych np zamieniających wodę [z dodatkami] w wino.

PS
Pisać [kodować] można też za pieniądze i dla pieniędzy