What takes the most time in our ColecoVision homebrew projects?

[newcoleco]

What do we struggle with the most when creating a new ColecoVision homebrew project?

 

Of course, the answers depend on the person experience, the game idea, the tools and materials available, and so on.

 

I would like this poll to show a full view of a game project from start to finish. Since a conversion doesn't worry about the game idea and most of its code and data, try to think about a ColecoVision project made from scratch and what is most troublesome in a full project.

 

Let's exchange on this topic, give tips and tricks, perhaps find ways to reduce the bottleneck time parts. Maybe this can show where we should focus our effort on, even find or make some missing tools in our toolbox.

 

Vote and reply why you voted that way!

 

Let's begin our talk!

Edited February 16, 2017 by newcoleco

[PkK]

Testing definitely takes a lot of time. Especially since my games often to have simultaneous multi-player, which means that two people are needed for testing.

 

Philipp

[newcoleco]

Testing definitely takes a lot of time. Especially since my games often to have simultaneous multi-player, which means that two people are needed for testing.

 

Philipp

Ok, I added Testing in the list, kinda assumed it in the Alpha and Beta phases.

[SiLic0ne t0aD]

I'm not necessarily a homebrew programmer (yet) but I selected the tasks that I assume would take the most time.

[Pixelboy]

I only worked on one game so far, and I haven't even finished it yet, so I'm not in a position to give any meaningful answer to the poll.

 

But from the standpoint of a publisher, I can say that the greater amount of time either goes to development or testing/debugging. Each game has its own backstage story.

[newcoleco]

As for me, it really depends on the project, but most of the time I do have an alpha version done quickly with most if not all the graphics that I need, then it's lots of back and forth by adding elements and see if it integrates nicely or not. If there is a lack of space, I try to optimize the size of the code (coding in ASM instead of C helps) and the data (reusing data, converting with a different compression method) or simply get rid of what is not necessary.

 

For example, Jeepers Creepers started very quickly with the idea, most of the graphics and a first version of the controls and logic. After years on the back burner, the project was finally completed in a one-week full-time schedule: improved title screen, improved controls, tweaked difficulty levels, tweaked game logics, added a new screen level, optimized overall size and speed. There is a magic potion in the graphics data (check the ROM file) but I decided during the last day that this game element was unnecessary instead of sacrificing bits of code and data here and there to a game already enjoyable and good.

 

Another example, Reversi was done very quickly with the graphics and most of the sounds in place. The longest part was optimizing the AI speed; the min-max (or alpha-beta) algorithm was taking so long that the first versions of the game took 2 to 3 hours to play a single game at the highest difficulty level. I had to recode part of the AI, optimize with ASM codes, I probably goofed a bunch of times, and finished with a reasonable speed under an hour per game which is still long but way better. Exhausted, I ended the project and published as-is. A second version of the game simply added a bonus game to the ROM named Diamond Dash.

 

There are games that I planned to do and all I have is notes on paper or a folder name to remind me that I wanted to try something about this game mechanic, or this game theme, or this game genre, ... For these games, I guess the longest part was the idea and calculating if it was feasible in the memory space and graphics capability of the ColecoVision game system.

[alekmaul]

Testing is what take the most of the time on my projects. I can develop something but I'm really bad on finding the bugs in my projects.

Also, because I'm not a musician, making music and sound are also the parts I did at the end of the projects and that take a lot of time too.

[PkK]

Compiler improvements also tend to take quite some time. Since I am also an SDCC developer, after looking at the asm generated for my game, I start improving SDCC to generate better code.

Sometimes it's just a few rules for the peephole optimizer, implemented and tested within less than an hour. Sometimes it's a more complicated but still simple optimization that might take hours or days. And sometimes it takes years.

 

Philipp

[Kiwi]

I'm going to say polishing takes the longest. If I'm working on 32KB game, then size optimizing is the 2nd longest and probably the most funnest part. It's like a puzzle for me and having someone looking over the code for me taught me more ways to optimize for size. I can apply that knowledge to my current project.

 

Testing is good for the most part. I do have someone I know in real life that would play my game and give good feedback. Also found bugs in the game that I neglected during programming. I converted Rockcutter to 128KB format, but probably will recede and possibly release the 32KB version which is complete game, but few things I just need to add to it, since I think I have 100 bytes left. I feel I NEED to fill that 128KB. When my mood is align with the sun and the moon, I could work on it and finish it off. Then I have to make the manual layout myself, and possibly the box art. I really want the manual to be extremely well done.

 

I get really nervous when the game is completed and in the hands of the publisher. I didn't want any terrible bugs to crop up. Does the game have enough content for the gamer to enjoy? Will they get angry with me for some reason that out of my controls... I wanted them to burn a eprom and test the game see if it work correctly since the Colecovision's RAM is dirty upon start up I believe. A few bugs slipped by unfortuanately in PONG and Computer Space . Kinda mad at myself for not getting up and testing them on the real Colecovision. Spunky's Supercar! was tested properly. Flappe Byrd, I did a lot of testing myself and remembered the bug. I fixed them right when coleco_master said, Ok it's time to give us the final ROM. I was like, hold on let me check something real quick. Fixed it and then hand it to him within an hour. Flappy bird and Sparrow Flaps uses the same variable and some functions.

[newcoleco]

More votes coming in, the poll tend to indicate a need for Quality Assurance, a team of testers available to try our projects at diverse stages, especially before publishing to avoid embarrassing bugs. Since Atarimax Multicart allows to try a ROM file on real hardware, distributing binary files to QA volunteers, agreeing to terms and conditions, should be a good way to keep our hobby going and gain professional quality level.

 

I've worked for a video game company for about 7 months and they used different tools to record and keep track of bugs found by testers with all kind of details including common tags for the kind of bug and where it was, a short description on the manipulations to reproduce the bug, screenshots and short video clips, the hardware used to test, build version tested with the bug in it, build version with the bug fixed, and so on. It is not easy to test a video game in a QA team; have to check if the bug is already reported, try to reproduce the bug and figure out by elimination what really is going on, the timing and the manipulation to make it happen. A second tester can add to a bug description already listed, helping to pinpoint the issue, helping the developers to understand the bug better and fix it.

 

Is there a retro-gaming QA team who can (or will) test our ColecoVision homebrew projects? Or is this too much professional thinking and better just keep things as it is now between trusted friends? My opinion is to open up the possibility, say to ColecoVision fans "Do you have a multicart? Wanna test our games?" and see the reaction, and perhaps set up a bank of potential testers and get things started this year.

Edited February 17, 2017 by newcoleco

[digress]

Um bug fixing and music/sound for me.

 

Music & sound is a pain and takes forever for me.

 

Graphics & animations too but mainly converting into a usable form takes so many steps. I got a system figured out with some batch files that help but even then it's labourious

[+Tarzilla]

More votes coming in, the poll tend to indicate a need for Quality Assurance, a team of testers available to try our projects at diverse stages, especially before publishing to avoid embarrassing bugs. Since Atarimax Multicart allows to try a ROM file on real hardware, distributing binary files to QA volunteers, agreeing to terms and conditions, should be a good way to keep our hobby going and gain professional quality level.

 

I've worked for a video game company for about 7 months and they used different tools to record and keep track of bugs found by testers with all kind of details including common tags for the kind of bug and where it was, a short description on the manipulations to reproduce the bug, screenshots and short video clips, the hardware used to test, build version tested with the bug in it, build version with the bug fixed, and so on. It is not easy to test a video game in a QA team; have to check if the bug is already reported, try to reproduce the bug and figure out by elimination what really is going on, the timing and the manipulation to make it happen. A second tester can add to a bug description already listed, helping to pinpoint the issue, helping the developers to understand the bug better and fix it.

 

Is there a retro-gaming QA team who can (or will) test our ColecoVision homebrew projects? Or is this too much professional thinking and better just keep things as it is now between trusted friends? My opinion is to open up the possibility, say to ColecoVision fans "Do you have a multicart? Wanna test our games?" and see the reaction, and perhaps set up a bank of potential testers and get things started this year.

Intelligent Revolution on the Intellivision side has a solid core of about 6 or 8 people that heavily test all IR's releases. We have an Atari Age PM thread for each game, WIP roms are posted there as is feedback, bug reports, box art, manuals and video captures of the bugs. Different people have different strengths. Several of us test on hardware, not just an emulator, and at least one tester has every flavour of Intellivision, including PAL. We haven't had the need to use a formal bug tracker. I know the LTO Flash! team used Trello to manage things, but I've found a PM thread to be good enough.

 

On the Coleco side, I've been involved in similar, but smaller testing threads as the games are mostly complete (unlike the Intellivision ones which generally start from the beginning)

Once I start programming my own Coleco games, I'll use the same PM thread mechanism as I do on the Intellivision, probably with the same team.

 

Experience has shown me that you need several different people testing and that the programmer should concentrate less on testing themselves and more on adding hidden debug codes like level select, add an extra life on the fly, invicibility etc to make the testers lives easier, especially if games have multiple levels, in order for the testers to better use their time. No one wants to play 30 levels of a puzzle game over and over just to test levels 31-40.

 

There are enough people with AtariMax carts and would put in the effort to test properly that a core group group could be established of people that would actually test (as opposed to people that volunteer just to get free roms)

[+Tarzilla]

On the development side, music and sound take the most time for me since I have no understanding or talent for it

[youki]

For me what take the most time is to find the motivation to Start the project.

 

I have the idea, i know where i want go... but there is always a part in the development where you are building the fundation, the base of your game, routines etc... but you don't have the game yet. The Graphism are rude , no sound etc... and all that phase, i have to admit i have to force me to continue , until the point where the game start looking how i want and then it become a pleasure to code and complete.

 

And finally i spend lot of time in tweeking and polishing and optimizing (as i target 32k games) . But in that phase, i often rework the graphism , the sound etc....

 

But what i would need is a good graphist that can read in my mind. Having good graphism ready is very motivating to start a project.

Edited February 17, 2017 by youki

[PkK]

'Just came back home from a testing sessesion. We found 4 bugs specific to two-player mode, and a few other issues (one of them specific to the plain controller - hadn't noticed it before, since most of my recent testing was done using roller controller and emulators).

 

I don't have a talent for music or sound either. So I leave the music to others (usually to composers that have been dead long enough for their copyrights to expire).

 

Philipp

[ten-four]

Also a few words from me.

 

I'm not a programmer, but...

 

I can see how programmers work with their games, and what I can see where things can hang is: Graphics, Music and Sounds.

Programmers need to understand how things looks and how things can move on a screen.

 

I can only speak for my self, but I want games that looks "professional" and look like a game that has a drive a la arcade games.

For me is an "look a like Arcade game" always a game I am interested in.
​I chose few of them sometimes to my collection. (if my wallet allows me,)

 

I understand that it is Bug fixing and Music/Sound that lagging behind.

​A solution could be that a programmer send his alpha or beta game to another programmer and they both agree what to do with the game.
​I know newcoleco is fantastic around Music and Sound, so maybe he could help in many ways.
​Also nanochess is a very talented programmer, so maybe he also is willing to help where other programmers get struck.