Why many projects are never finished?


#1

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?


#2

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.


#3

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.


#4

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.


#5

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.


#6

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 :pensive:. 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’.


#7

Hahaha! That is so true, and not just for you mate!


#8

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.


#9

We used to work like that as young cats working on mobile phones. It’s fun for a while but it’ll burn you in the end.


#10

I think it’s mainly:

  • People announce things earlier, like @FManga said
  • People have a poor attention span, like @spinal said
  • Being productive is hard, like @Vampirics said
  • 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:

  • There are 2 SD card APIs and I never know which is capable of what (and sometimes I can’t get them to work).
  • A lot of the types aren’t what they should be
    • int16_t is used in a lot of places where int8_t makes more sense
    • a lot of places use uint8_t when they should be using bool
  • Lack of const-correctness in some places (especially places expecting character strings)
  • A lot of functions in Core seem to be feature creep and would make more sense in a separate class or namespace
    • Things like askLoader, jumpToLoader should be in a Loader class
    • The collision functions should just be free functions and should be using actual Point and Rect objects
    • keyboard, popup, filemenu, menu, askLoader, drawvolbar etc should be in utility classes/namespaces
    • pickRandomSeed should be changed to generateRandomSeed so the user can choose what PRNG to feed it into (which is something I did for the Arduboy last year)

And of course the documentation could do with some updating.
One thing Arduboy2 does exceptionally well is to have very detailed documentation.

I did actually start working on a design for a replacement API a while back,
but that got put on hold when some new projects came along.


#11

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.


#12

My random thoughts:

  • 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.

#13

I’ve a high number of unfinished project right here on Pokitto. So I can speak by experience :wink:
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.


#14

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.


#15

It depends how you organise it.

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).


#16

I don’t remember if we’ve spoken of this already, but you can debug with the emulator using the VSCode’s Cortex plugin. Have you tried that?


#17

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 :slight_smile:). It gives me a better understanding
I would be disapointed if
I had to use the arduino IDE all the time…


#18

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.


#19

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++ );

Translates to:

int32_t i = 0;
{
	while(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.


#20

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!