What do you think is the reason why many Pokitto games or other projects are not finished? I know making a game is hard. Making a prototype or a small demo is fun and relatively easy, but extending that to a full game is a big effort. Even for a small game like Space Invaders or Pacman.
Can that be related to Pokitto environment also? Pokitto is quite a capable device compared to e.g. Arduboy. The game project gets bigger because there are more memory, screen resolution and colors. Do you think that a larger percentage of Arduboy games get actually finished than in Pokitto?
Well I was able to work on games way more easily on the Arduboy, mainly because there is many great tutorials and setting up the IDE was a breeze. Basic Arduino IDE just works. And to be honest I started coding directly using @FManga emu projectABE. So seeing what I am doing directly was nice.
The better hardware raises the bar, so games are more work. Also, I get the impression that the Arduboy community likes to keep projects under wraps until theyāre ready, while here people share from early on. Thereās probably a lot of unfinished Arduboy games, you just donāt see them as much.
I canāt argue that Arduino IDE is easy to set up, but if people actually used the PokittoSim, they could develop games way easier than Arduino IDE. When you can do the whole thing on the PC its just so so much faster. You can debug your code live, execute step by step and watch variables etc.
I use the simulator all the time, because developing is so easy. There are only a couple of areas that work differently on HW, like some functions in the SD Card API.
My problem is 100% down to my poor attention span. Once a project gets to the āit works enough to testā I get bored with it . I once looked at my DS homebrew projects to see if any were worth revisiting, I had 92 unfinished, some barely even started.
When it comes to āfinishedā projects, the best you get out of me is ā abandoned near enough to the end that a lot of people wonāt noticeā.
From my small experience, coding needs a certain state of mind and when I am in it, I really have to do as much as I can at that expect moment, if I donāt I just canāt force myself to be productive. So since this is just a hobby that I have during my rare free time, stars really have to be aligned perfectly to get anything done lol
That reminds me an article I read about the team that worked on the game Venture. They had to stay at work all-night and order pizza to be sure to not lose momentum during development.
Itās early days and we still donāt have as many active users
Ultimately every programmer has more unfinished projects than finished projects.
(I have a massive pile buried in my hard drive.)
In my case thereās several things that makes finishing projects difficult:
Iām a perfectionist, so Iāll spend a lot of time turning over minute details because I want to write the best program I can - I refuse to settle for āit works, itās good enoughā
I need a lot of quiet to concentrate, and silence is rarer than golddust where I live
I need minimal distractions, and life these days is full of distractions
I like feeling challenged to some degree, and the more I learn the harder that becomes, so as a result Iām prone to dropping things Iām working on when I come up with a more interesting idea
For Pokitto-specific issuesā¦
At the moment my main issue is clearing my project backlog and lack of time and circumstances available for concentrating on programming.
But aside from that, one of the things that puts me off sometimes is the current state of the library:
Yes I know, but that may be why we had more done back when we were young. Now with more responsibilities, kids and other stuff, you can bet itās harder to get in the right mindset to do it.
Coding is diffcult. It takes a lot of practise. When the code complexity grows it comes exponentially tougher to understand and manage.
I would like to do many things but they will look crappy if I make graphics by myself. It is difficult to find right graphics, or find a graphics desiger for a hobby project. In addition, if I get bored of the project and I dump it, I feel bad if someone has put effort in making graphics to it.
I cannot make graphics for 256 color game. I could make somehing like Sinclair Spectrum level graphics, but that does not look so fancy on Pokitto (compared to other games)
I do not have much time for hobby coding. That has forced me heavily to prioritize features and I often stop when it is good enough, or if it gets too laborous. This can be good also!
As I do not have much time I (more or less) carefully choose what project I even start. Still projects usually take a long time to finish.
Iāve a high number of unfinished project right here on Pokitto. So I can speak by experience
Here the public ones:
PokSky
Overestimated Pokitto Memory capabilities (also found no way to measure the consumption) and test ground for c++ stuff.
Pokitto Lander
Found a bug on clipped drawLine, lost momentum on developing
Pokitto Say
Found a bug on Random generator, lost momentum, non more wish to go back on that project
Pokitto Say
Too complex management of credits/license for the images used.
Pokitto is a C/C++ learning platform for me, so facing problem with the language is part of the deal. Also available time is limited and fragmented.
The big stop come from problem with API and development tools.
Developing with simulator give fast feedback but often running on hardware reveal big issues with limited resources.
The API/Documentation is a big source of open question: what the best way to do this or that? Is this/that method full working and tested?
Ideally Iād like a VsCode solution with integrates emulator (Felipe one) with debug, and a coherent well documented Pokitto Library with example of use.
I also have a lot of unfinished projects mostly as a result of getting excited about a new idea, but eventually running out of momentum. I do try to keep coming back to old projects if I can renew my enthusiasm for them.
I think there are probably many unfinished Arduboy games, but that the community is bigger there and itās easier to get started on the Arduboy. Somehow getting started on Pokitto had more āfrictionā to me. I wasnāt comfortable with the online mbed compiler and didnāt want to install yet another IDE. I only recently got the arm-gcc compiler set up on Linux, which has made things easier for me.
I think the simulator is great, but it does allow someone new to the Pokitto to get a false sense of security about the scope of their game, and then when they test it on hardware it might not work or have a poor framerate.
I also agree that graphics are more intimidating on the Pokitto. I wish I could make higher-quality graphics for some of my projects, but I usually prefer creative control when it comes to my hobby projects, so I also donāt think its fair for me to ask someone for graphics help. I donāt want to be a bad teammate to work with, so Iām hesitant to join community projects either. I actually started making hobby games on devices with worse screens like the original Gamebuino because even programmer graphics looked ok on that screen, and I could focus on the technical part of the game. I hope that the Pokitto can keep attracting new artists.
Some people tend to think having fewer functions/objects makes it easier to understand code because they think it means thereās less to remember, but actually the opposite is true.
Many people tend to do the opposite and end up with lots of large, complicated functions.
Writing code that way tends to actually make the code more complex, for the same reason that writing in assembly produces more complex code - spelling everything out in tiny detail actually results in code thatās harder to follow.
I find that breaking things up into lots of small objects and functions that have a clearly defined role makes code a lot easier to understand because you can focus on the bigger picture and forget about the implementation details.
(Obviously you still have to implement things and then you have to worry about the details, but after youāve done that you can forget about those details and focus on the bigger picture.)
I always ask @Vampirics if I need some better graphics than what I can manage.
Thatās a fair point, thatās one of the reasons I tend to do my own graphics first, and then worry about improving the graphics after the actual logic is done.
Itās easy enough to slot in replacement graphics after a game is finished.
If youāre using dynamic memory allocation then measuring memory consumption is very difficult.
Otherwise the compiler reports the static RAM use when you compile, and you just have to factor in how deep the stack will go.
(Though measuring the stack size isnāt particularly easy either.)
Whatās the bug?
You put Pokitto Say twice, did you mean to say something else?
I think the online mbed compiler has been an issue for a lot of people.
Having to make an account just to compile code and not having C++11 are big issues.
Thatās why I think we should put more effort into improving the PlatformIO support or finding an IDE configuration that will work on every system (or at least making a package of tools that can be hooked up to most mainstream IDEs).
Here is my experience:
Iāve been working on a Pacman game for some time (I started last summer I think). I have made some progress but it is far from finished. Unfortunately, lately (since January) I lack the time to really work on itā¦ Weāre currently also building a new house and a lot of time goes into that and the past few months I have also been working (a little bit) during the weekend running numerical simulations for my daytime job to meet deadlines.
What is also slowing me down is the state of the pokittolib. In my opinion it is not mature enough yet (which perfectly understandable) to be beginner friendly or really user friendly:
my first game was a tetris clone that I ported from a visual studio project I did before. The porting of the gameplay itself was easily done. But then I wanted to add some music/sounds and a high score table. It was a real trouble the get the SD card loading and saving to work (still not always working as it should). There was no real documentation to rely on
for pacman I decided to use the hires mode with sprites. This feature seemed well documented on the forum but again I ran into trouble when I tried to disable a spriteā¦ I was thinking I must have been doing something wrong. It turned out that you could not do that. You have to move sprites off screen.
Of course there is a great expertise available on the forum and people are always trying to help where they can. I have already bothered @Pharap and @Hanski a lot with my questions but for some reasons I usually prefer a pm so this activity remains invisble on the forum.
What is missing I think is a āmore advancedā tutorial that creates a whole game. Those tutorials do exist for the arduboy and I think a lot of beginners try them and start from them to make a first game.
I like to do the same because as I reader/follower on the forum I find it disappointing when something promising is first posted but then doesnāt get updated anymore, like for example some of the stuff @drummyfish was doing with the 3d stuff.
However, a great counterexample is the development of PokittoGP. I find it great the @Hanski posts regular updates of the progress.
I like the combination of CodeBlocks +PokittoSim and Embitz + HW. I use the pokittosim all the time. It is true that the performance on hardware can be quite different. Up until now I enjoyed looking for optimizations in my code when performance on hardware was quite slow (probably because I always found a solution myself ). It gives me a better understanding
I would be disapointed if
I had to use the arduino IDE all the timeā¦
I agree with that and I think it is exactly where less experienced coders loose their focus and motivation. You have to think about the architecture of your code and do refactoring time to time (e.g. make new dedicated classes and functions).
I am too much visually oriented person and it bothers me to look at my rude graphics even if I know it will be eventually fixed.
I have done both measurements in the Pokitto code.
For the stack size: Call CheckStack(). Look at Examples/TestCrashScreen/main.cpp
For the free ram size:
// Allocate 100 bytes in a loop until no more ram left.
int32_t i = 0;
for( ; new int8_t[100] != NULL; i++ );
// Print the free memory size
int32_t freeSizeInBytes = (i-1) * 100;
mygame.display.print(freeSizeInBytes);
while ( ! mygame.update() ); // draw now
// Loop forever. Causes Pokitto to hang.
for( ; ; );
Note that I do not free the memory as it is ok in my case, after calculation, just freeze Pokitto and restart it.
I can vouch for this.
For me itās not a burden though, I enjoy answering programming questions (sometimes more than actually programming something).
And actually I think thatās actually one of the things weāre lacking here.
On the Arduboy forum lots of people publicly ask questions about how to do things, and much of the knowledge of the forum is in the answers to those question posts.
Over here not as many people are asking questions about C++ or design.
(I think thatās partly because our most regular members are more experinced.)
Personally Iām not a fan of the ones available for Arduboy because I think they teach people bad habits (like using macros for constants).
I think Filmoteās set is better, but I admit itās quite a leap from the simpler tutorials.
I agree, I think PGP has been one of the best games developed for the Pokitto.
Hrm, perhaps.
Generally I enjoy the problem solving aspect more than actually getting games working,
and that was the case even when I was first starting out (perhaps not at the very beginning, but certainly some time in the first or second year).
Iād love to write some tutorials/discussions about architecture, but itās finding the time and effort.
I find writing tutorials quite difficult because I have to come up with contrived objectives and Iām talking to a theoretical person.
I find it easier to answer specific questions from people because usually thereās a clearly defined goal and I know thereās an actual person reading my answer who will tell me whether or not they understand what Iām saying and either ask for clarification or express gratitude for the help.
Odd choice of adjective (ārudeā), but I get what you mean.
One of the reasons I always plan my code before writing is because I canāt stand āuglyā code, even if I know Iāll attempt to neaten it up later.
That and I donāt like having to rewrite code.
Iād rather spend a long time thinking everything through and write the code just once or twice than getting part way through and realising there was a better way to do it.
Ah yes, I forgot about that.
There ought to be a better way than that, but it would probably involve disecting malloc to understand what allocation technique is being used.
I donāt mean to be too critical, but I find for( ; new int8_t[100] != NULL; i++ ); very cryptic.
I had to do a double-take to realise what was going on.
Also itās worth mentioning that strictly speaking new is never meant to return NULL like malloc can.
If an allocation fails new is supposed to throw an exception and of course, exceptions are disabled on Pokitto as far as Iām aware so itās interesting to see how disabling exceptions causes new to behave differently.
If you want to do this more portably, you could call new(std::nothrow) char[100] instead, which is guaranteed to return NULL/nullptr.
(std::nothrow is in the <new> header.)
Also, are you sure that should be i-1?
Doing:
int32_t i = 0;
for( ; new int8_t[100] != NULL; i++ );
So i++ is only called if new int8_t[100] != NULL.
If new int8_t[100] returns NULL immediately then i will be 0,
so it stands to reason that i is accurate and doesnāt need the -1.
Personally Iād probably write it as:
using Pokitto::Display;
using Pokitto::Core;
std::size_t blockCount = 0;
while(true)
{
char * data = new(std::nothrow) char[128];
if(data != NULL)
++blockCount;
else
break;
}
const std::size_t freeSizeInBytes = i * 128;
Display::print(freeSizeInBytes);
while(!Core::update());
while(true);
(Requiring <new> and <cstddef>.)
Inconvenient but understandable.
Like I say, there should be a way to do it without crashing the Pokitto,
but it would require knowledge of malloc's allocation technique.
I guess you are right but my main point here is that you can follow a tutorial where you make a (basic) game from a to z. So maybe @filmote should start making a version of his tutorial for Pokitto!
. I once looked at my DS homebrew projects to see if any were worth revisiting, I had 92 unfinished, some barely even started.
). It gives me a better understanding