I am making an ambitious game but, it feels good.

flyinian

Member
I think I have found the project that I will be able to finish and not scrap. I settled for the "don't worry about to much path" in game development. It's going to be text based with minimal art assets, and animations so, that takes a enormous chunk out of the development.

The game will consists of(at least planned for):

  • Lots of text
  • Real world valued Numbers(not some unrealistic cash value)
  • functioning Companies, countries, militaries, and more. With changing finances, populations, etc.
  • Various player features
  • In depth Karma System
  • Lots of items
  • Much Much More. A lot of it is a secret. :)
The player will have the final decision when playing the game. They can eliminate whole populations to donating their billions? trillions? ??? to charity and live in a tent on a deserted island.




The hardest parts of it(That I know of):
  • The coding in general.
  • Creating the A.I. (I have a simple solution to simulate complex A.I., I hope)
  • Balancing the many...many...many...many variables.
  • and much much much more.


Overall, I am pretty excited for it and I think I have it where it's manageable for me. I went from a tower defense game to a plat former to a plat former/tower defense then to a RTS game. I know...and I abandoned all of them. Now I am on a text based game with minimal art and animation assets.

I guess we'll see if I abandon this project too. :)

Quick Question for those who started and completed projects before:

What are your tips for staying consistent with developing your game and keeping your interest?
 

pixeltroid

Member
If you say coding is the hardest part then I strongly suggest you start small and add new features slowly over time. Like, start with ONE company; then when that's done, add ONE military; then ONE nation and so on. Then when you have them all nailed down start replicating things. So "grow" your game from one small seed instead of trying to sculpt a game out of a gigantic block of stone.

I dont mean to discourage you or anything, but starting off with too many things at once may leave you fatigued if you end up with too many coding issues to fix. When that happens you'll grow tired of your project and abandon it....and all those hours you initially spent on the game will be wasted! Believe me, I have heard of other game developers announce their grand concept on forums and then go silent because they quietly abandoned their project for the reasons I mentioned earlier. Don't end up like them!

Start small and add new features later, IF and WHEN you need to.
I'd say adding new features is like finishing whats on your plate, with the rest of your food in a refrigerator -- you only get to go back to the refrigerator only after you finish what you first took out. That way, your next meal will be fresh, and the whole process of eating will be fun.

In contrast, starting off very ambitious would be like taking out all the food in the refrigerator and arranging it like a banquet on the table and then trying to eat it all at once. In a few hours, you'll find yourself full and fatigued, and all the delicious food will start to lose its freshness. You will then have to either force yourself to finish everything or throw away all the food because you've gotten sick of it. Either way, its not a very pleasant experience.

So, I'd advice you to dump all your game ideas into a refrigerator, and take out exactly what you need for each meal. So for the first "meal" of your game, you could take out what you need to make ONE military and finish that 100%. That first meal represents the entire game until you finish it. And only when its finished, go back to the refrigerator and take out what you need for your second meal...and repeat the process until you're done.

I'd say thats the trick to keep your game idea fresh and stay interested in its development. And you can do that by slowly new features.

Good luck!
 
Last edited:

flyinian

Member
If you say coding is the hardest part then I strongly suggest you start small and add new features slowly over time. Like, start with ONE company; then when that's done, add ONE military; then ONE nation and so on. Then when you have them all nailed down start replicating things. So "grow" your game from one small seed instead of trying to sculpt a game out of a gigantic block of stone.

I dont mean to discourage you or anything, but starting off with too many things at once may leave you fatigued if you end up with too many coding issues to fix. When that happens you'll grow tired of your project and abandon it....and all those hours you initially spent on the game will be wasted! Believe me, I have heard of other game developers who announce their grand concept on forums and then go silent because they abandoned their project over time for the reasons I mentioned earlier. Don't end up like them!

Start small and add new features later, IF and WHEN you need to.
I'd say adding new features is like finishing whats on your plate, with the rest of your food in a refrigerator -- you only get to go back to the refrigerator only after you finish what you first took out. That way, your next meal will be fresh, and the whole process of eating will be fun.

In contrast, starting off very ambitious would be like taking out all the food in the refrigerator and arranging it like a banquet on the table and then trying to eat it all at once. In a few hours, you'll find yourself full and fatigued, and all the delicious food will start to lose its freshness. You will then have to either force yourself to finish everything or throw away all the food because you've gotten sick of it. Either way, its not a very pleasant experience.

So, I'd advice you to dump all your game ideas into a refrigerator, and take out exactly what you need for each meal. So for the first "meal" of your game, you could take out what you need to make ONE military and finish that 100%. That first meal represents the entire game until you finish it. And only when its finished, go back to the refrigerator and take out what you need for your second meal...and repeat the process until you're done.

I'd say the trick to keep your game idea fresh and stay interested in its development. And you can do that by slowly new features.

Good luck!
Well, said. I like the analogy.

This time around, I started a GDD and that's getting pretty extensive and organized. So far, I'm focusing on the ui and ui interactions then i'll creep into the essentials for the prototype(with a single company, military, etc). After that, bit by bit. Probably do it room by room. Basically, lay the foundation for the features then fill them in down the road. What I have in my head seems simple enough and that I shouldn't have to much of a hard time with the coding aspect of It if i avoid the more complex coding(i.e. data structures).

Once again, that is one well said reply.
 

pixeltroid

Member
Well, said. I like the analogy.

This time around, I started a GDD and that's getting pretty extensive and organized.
ah, then your GDD will be your "refrigerator" of ideas!

Also, once you start making the actual game, it might be helpful to maintain an excel sheet that indexes every object and all its related sprites, timelines and scripts. It will serve as an inventory list and save you the time and hassle of opening up objects to see what sprites or scripts it uses -- that is, in case you need to fix or change something.
 

YanBG

Member
Feels good until you actually started the damn thing. Not even you will be interested to play it. If you are into design, just make board games?

start with ONE company
I had to start over my project because it wasn't modular enough, any small change later on would be too much reworking.

What I have in my head seems simple enough and that I shouldn't have to much of a hard time with the coding aspect of It if i avoid the more complex coding(i.e. data structures).
For me ds_ makes it easier, i can't imagine making a game with countries and provinces without it. I mean you could go with just arrays, but it's harder to keep track of them.

It will serve as an inventory list and save you the time and hassle of opening up objects to see what sprites or scripts it uses -- that is, in case you need to fix or change something.
Or not use objects?
 
Last edited:
T

Taddio

Guest
What I have in my head seems simple enough and that I shouldn't have to much of a hard time with the coding aspect of It if i avoid the more complex coding(i.e. data structures).
Ouch...getting a game which is in a big part data-based like the one I'm imagining you want to do would seem to me MUUUUUUCH more complicated, if not realistically undoable in a clean, expandable, and presentable manner without data structures. I would take a day to learn and study them thoroughly before starting on your big project.
And how is more complicated? They really are not, they simplify things A LOT, and most of the time it's just a couple lines of code to get to what you want to do.
 

flyinian

Member
ah, then your GDD will be your "refrigerator" of ideas!

Also, once you start making the actual game, it might be helpful to maintain an excel sheet that indexes every object and all its related sprites, timelines and scripts. It will serve as an inventory list and save you the time and hassle of opening up objects to see what sprites or scripts it uses -- that is, in case you need to fix or change something.
----
I didn't think of keeping track of what's inside individual objects. I'll definitely need to do that. Thanks for the idea.
----

Feels good until you actually started the damn thing. Not even you will be interested to play it. If you are into design, just make board games?

I had to start over my project because it wasn't modular enough, any small change later on would be too much reworking.

For me ds_ makes it easier, i can't imagine making a game with countries and provinces without it. I mean you could go with just arrays, but it's harder to keep track of them.
Or not use objects?
----
I'll be looking into data structures and make few attempts at implementing them to the game. Data structures, are just more complex to me than using objects for each individual entity. I haven't had that "aha" moment yet with data structures. I get lost when it comes to implementing them into the actual game after I have created them.
----

I like the story of the game.

Yes big projects are hard to finish. You can do it!
---
Thanks for the words of encouragement :).
---

Ouch...getting a game which is in a big part data-based like the one I'm imagining you want to do would seem to me MUUUUUUCH more complicated, if not realistically undoable in a clean, expandable, and presentable manner without data structures. I would take a day to learn and study them thoroughly before starting on your big project.
And how is more complicated? They really are not, they simplify things A LOT, and most of the time it's just a couple lines of code to get to what you want to do.
---
I look at this as practice. The more coding I look at, decipher, problem solve and so, forth the easier it will be to code. I'll have a GDD which means a sequel will be easier to create and therefore should have better code and be a better game. As for data structure goes, refer to the comment I did above(within this reply). Besides, finding a good tutorial that holds your hand through data structure don't exactly exist. At least none that I have found. There's video tutorials on data structures but, they only do parts of their entirety and then it leaves me with questions, concerns and such. My problem as mentioned above, is after the data structure is created, what do I do? How do I use the DS with this list of item, objects, and so forth(code wise). That's why I plan on using objects for militaries, companies, people and such. It's not an efficient way or ideal in general but, this should allow me to gain progress on the project without running into unbreakable code problems.
---

Thanks for all the replies and whats included in them. It helps and I appreciate it. :)
 
T

Taddio

Guest
-That's why I plan on using objects for militaries, companies, people and such. It's not an efficient way or ideal in general but, this should allow me to gain progress on the project without running into unbreakable code problems.
Well, for quick prototyping that might be the quickest way to go, but if you want an expandable system, it's definately not.
Hard-coding everything will be painfully long, and you have way more chances of coding yourself in a corner.

For me, the "Eureka" with ds_* came to me when I realized that they were exactly like arrays, and I did used arrays a lot and found them quite easy to work with at that point. Lists are basically like array[X] and grids are basically array[X,Y]. Wasn't too sure about the advantages at first, but soon I found out all the useful functions, like shuffling, sorting, getting areas like circle and rectangle (eg. for fog of war, assigning tiles values in a specific spot, etc.).
Make a projects and mess around with it while looking at what happens to the values in the debugger. I'm telling you, you'll get the hang of it in less than a day or two, if you work good.
 
Top