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.
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.
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 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 != NULL; i++ );
// Print the free memory size
int32_t freeSizeInBytes = (i-1) * 100;
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.
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 != 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 instead, which is guaranteed to return NULL/nullptr.
(std::nothrow is in the <new> header.)
Also, are you sure that should be i-1?
int32_t i = 0;
for( ; new int8_t != NULL; i++ );