Leapy Peeps (formerly Hoppy Pals) now available on the App Store!

2. I should have optimized earlier

There are programming practices you can adopt to help you get better code on your first draft, but some late-stage optimization is inevitable. Unless you know every problem you're going to encounter and how to solve it from the start, there will be code you'll have to revise later.

The one thing that's helped me more than anything else in my project is documentation. Assume you're going to have problems later on and leave yourself good enough notes so that when you revisit old code, you can recall what you were doing.

3. The simplest of ideas can be the hardest to execute

Been down that road Things that sound simple often aren't when you get into the details.

Feature creep is definitely a thing, but I think the latest two screenshots look really good. It's hard to know where to draw the line. Little things like the particles do catch my eye. Going back to your third point, once you get better at estimating how long it will take to code a new feature, it'll be easier to gauge if it's worth your time.

No featured developer or expert/master here, but a 30 year+ hobby programmer. So I chime in with my ideas.
1. If it is a hobby, why care? There are ways to get better at time management. And committing yourself to a plan: doesn't sound fun
2. Optimizing time. You need to have learned to do that and sometimes you learn along the way that there are other/better ways. It is hard to start over, but sometimes it is worth it!
3. True
4. Yeah! But look at your own work. You have managed to get a lot in and it made things better
5. It is better to make it for ' yourself ' first. Industry Breaking? Ehh.. it requires special skills like wizardry
6. When starting in Game Dev I would suggest to make a lot of games first. Don't put too much time in polish in the beginning
7. True. But look at 1 and 6   But it is nice to have at least a working thing from start to finish and not 100 games that have only a start
8. Don't compare yourself with others. You see only a small part of all the work/time it took them. Being critical is always good. Too much of anything isn't good.

Experience comes over time. Do what you like to do, no matter how much time it takes.
If you like what you are doing you are motivated and even on times where things don't go as fast as you want them to go it will help if you still enjoy the process.
Even if that means that you want to build an massive online multiplayer roleplaying game like WoW. But you have to be realistic about it.
Most Triple-A games have budgets for over millions of dollars and have at some point in time thousands of people working on them and then it takes them years to make it.
Calculate that to the number of hours (and given that most of them are experts in areas you aren't an expert in : triple the hours)
So to make something that big will require an entire life time. Well spend if you like everything about games and game design, but you should really get good at time management and committing to a plan (ha ha ha ha)

Fantastic learnings and comments guys!
One comment on:
 

"7. It's important to follow through and finish no matter what".

I think this i key for every project. It is one of the toughesdt parts but you have to do it.

Cheers!

The one thing that's helped me more than anything else in my project is documentation. Assume you're going to have problems later on and leave yourself good enough notes so that when you revisit old code, you can recall what you were doing.

@Merrak

I definitely feel like for a game and engine of your size, documentation is important and even though my game is much simpler, I think I could also benefit from this. Do you simply use comment blocks throughout your game or can you shed some light on your documentation process. I can't imagine how much stuff you have to keep track of but I bet going back to something is much less daunting cause of notes you may have left.

Also, do you still even use code from when you first started your isometric engine (like the stuff on page 1 lol)...Just curious..or has everything been overhauled? Thanks again for the input!

1. If it is a hobby, why care? There are ways to get better at time management. And committing yourself to a plan: doesn't sound fun
2. Optimizing time. You need to have learned to do that and sometimes you learn along the way that there are other/better ways. It is hard to start over, but sometimes it is worth it!
8. Don't compare yourself with others. You see only a small part of all the work/time it took them. Being critical is always good. Too much of anything isn't good.

Experience comes over time. Do what you like to do, no matter how much time it takes.

@mdotedot

You hit me really hard with this stuff and it reminded me why I got into this in the first place- as a hobby! I feel like making games was an excuse to get better at time management but in reality there are other (far better) ways of going about that and at the core of things I should just have fun and enjoy the process. It's also nice to hear from someone with your background whose actually been doing stuff like this for awhile. You're definitely a wizard in my book..especially with the things I see you concoct with Stencyl-your 3d engine is astounding! Hope you enjoy your vacation! Thanks again

Fantastic learnings and comments guys!
One comment on:
 

"7. It's important to follow through and finish no matter what".

I think this i key for every project. It is one of the toughesdt parts but you have to do it.

Cheers!

@Bombini

Nice to see the Space Pirate take a break from his space duties to chime in! Thanks for the insight..If anything, I feel like finishing is one of the most important aspects we face as game creators.

Absolutely love Space Pirate btw...can't wait to suit up and wreak havoc!

I definitely feel like for a game and engine of your size, documentation is important and even though my game is much simpler, I think I could also benefit from this. Do you simply use comment blocks throughout your game or can you shed some light on your documentation process. I can't imagine how much stuff you have to keep track of but I bet going back to something is much less daunting cause of notes you may have left.

Unfortunately I don't have a consistent method of documentation. Most of my documentation is kept in either physical notebooks or text files. Code comments are useful for little notes, but I can't easily browse through them if I'm looking for something. The journal thread is really useful... especially for broader ideas. Anytime I have to do some research (which is quite often), I bookmark the references. So I have built up an extensive bibliography. This is especially helpful if I have to learn new math that I didn't know before.

Also, do you still even use code from when you first started your isometric engine (like the stuff on page 1 lol)...Just curious..or has everything been overhauled? Thanks again for the input!

Kind of. The longest surviving code I have is the debug console. The first version was 2015, and I got a playable demo. That version was almost entirely written using code blocks. I did a major revamp of the code in Summer 2016... moving to typed code. I got the visuals I wanted, but the speed was terrible. For Stencyl Jam 16 I took the opportunity to start over. I wrote a new, far simpler, renderer (no lights)... got moving actors to work (well, sort of )  My goal was to get a simpler game working right then I could add in other features later.

The Stencyl Jam code wasn't bad for the conditions it was written in. Although I had the same 10 days as everyone else, I probably had twice, or even triple, the number of hours as most other people. During and after Hurricane Matthew there was absolutely nothing open in town for more than a week. Nothing was open and nobody could even leave town. I had a good 12 to 16 hours per day to work, either actively coding or planning. I did a lot of planning while waiting for batteries to charge... but as for code, probably not enough planning for the future after the contest.

The last major revamp was Summer 2017. The Stencyl Jam renderer fell completely apart when I tried to add lighting. I didn't write it in the journal thread, but I see the bigger picture why it didn't work: It was written to solve a different problem. It needed to be simple and it needed to work with minimal debugging. That approach to coding comes at the expense of efficiency. But I think that's the best programming lesson to learn. Clearly identify the problem your code is trying to solve. If the problem changes then you might need to rewrite the code. That ties back to your points #1 and #2. It's easier to identify the problems you need to solve if you have a clear plan, but there are also the unexpected problems.

@Bombini

Nice to see the Space Pirate take a break from his space duties to chime in! Thanks for the insight..If anything, I feel like finishing is one of the most important aspects we face as game creators.

Absolutely love Space Pirate btw...can't wait to suit up and wreak havoc!

Thanks a lot!
I would like to share some thoughts on the documentation topic as well
What helped me really well are comments in the blocks and code itself.
I tried many times txt files, powerpoitn or other text docs but i never liked how fats they are "out of synch" whenever i changed somewthing in th code.

I force myself since a while first to have all important functions "controlled" by one "main" behaviour and one list with all game parameters in it (no extra game atrributes). This helps to understand what does what. Second, i force myself to  put comments in behaviours to archive with what and how it works. I also make large comments for "adding new content" in the game. Almost like a checklist for example when i want to add a new enemy wwhich has dialogue and triggers whatever else.

This helps me so much.
Before i had code i did not understand a couple of weeks later so i had to rewrite it or spend a lot time to understand it again (the very complex ones).

In a nutshell: I try to comment as little, but as smart as i can. But i need to comment or else i am doomed.
Cheers!

you still making this one??!!

you still making this one??!!

haha hey Squeeb! Thanks for asking. As a matter of fact I am! Been busy tidying things up and I haven't put any time into posting as much. Gonna go ahead and submit the game to Apple within a couple weeks so stay Tuned!

Awesome!  Keep going.  Ill get it when its done!

make sure you tick all the boxes, fill in the promo form 6 weeks in advance, have preview videos and screenshots for all device sizes.

Hoppy Pals Beta has ended! This is the final post I'll be making in the journal before release

https://michaelmadrid.itch.io/hoppy-pals

Available now in the APPSTORE!  

Hop to a high score in this simple and endlessly addictive, yet challenging one-touch arcade experience! Collect coins, avoid the obstacles and stay afloat in Leapy Peeps!

I enjoyed playing this. It was good ol’ mindless time waster fun as it should be. But I do have a few issues: 1. The generation can be unfair at times (example: stuck falling platform and saw blade or other hazard where you need to land), 2. There are some pals that don’t fit the art style (example: the moai), 3. There needs to be a way to do shorter hops.