Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Dec 1999
Offline Last Active Yesterday, 06:57 PM

Posts I've Made

In Topic: Where to begin?

01 February 2016 - 10:58 PM

You can check the Classifieds -> Hobbyist Projects here at GameDev. You might find a team that wants a junior programmer.

You're probably better off on your own though. Lots of times there's the "idea guy" who says he needs programmers and artists. He has the next Big Idea TM that's going to make tons of money after you and the artist do all the work for free of course. Point is, there's not much to learn from in an environment like that.

If you decide to go your own route, start with small projects and work your way up. Here's a great article telling you which games you should build first and why:


Since you're learning C++, you might try the Unreal Engine. Or if you want to start learning C#, you could stick with Unity.


- Eck

In Topic: Sprite Sheet Need Help

27 January 2016 - 11:03 PM

We've pointed you in the right direction. It's time for you to try and solve your problem again. Read through our posts and take another crack at it.

In Topic: Sprite Sheet Need Help

24 January 2016 - 11:46 AM

Can you show us a code sample and/or a gif or video of what's going on?

I suspect you're flipping your sprite sheet instead of just flipping the rendered sprite.
// Pretend this is a sprite sheet with the following numbers drawn. (Original)

// If you flip the entire sprite sheet it will look like (Flipped)
So now when you tell it to draw the sprite at index 0, it prints out a reversed C. Instead, leave your sprite sheet alone, and tell the Original to draw sprite 0, but draw it flipped.

I don't use AGK, but a quick search didn't reveal a mechanism for drawing a flipped sprite, so you might need to map your own own frames to the Flipped texture.

- Eck

In Topic: Best way to document gamedev progress

23 January 2016 - 08:41 AM

In the early stages of my project, I don't have enough specifics of my game to document a full GDD. I know I want to build a turn-based tactical dungeon crawler but that's about it This is the 50,000 foot view. I code some of the big pieces that I know I'll need and make sure they fit together and see what works. At this stage, I have a Notes.txt file that I check into source control where I jot down decisions, ideas, and bugs. Sometimes there are check lists, other times there's a need to do and a done section. And I journal about my progress every one to two weeks here at game dev. If the game looks like it could be fun, I keep going. If it's missing that spark, I switch ideas or revise my original. 
My rough workflow for individual features is:

  • figure out what needs to be done
  • Make it work (sometimes hacky)
  • Make it right (clean up the code, comment it, factor things out into funcitons and classes)
  • Make it fast (if performance is a problem)

I'll usually spend a couple of hours to an entire day per week cleaning up my code and making sure I'm not coding myself into tons of technical debt.
In my current project A Voxel Adventure, I'm moving into the middle stage. Here I start getting a clearer picture on what I'm building. I take some time to document my decisions in Google document(s) and decide on the scope of the project. I write down all the features I think I'll need and assign a complexity value to each task.

  • 1 = < a day
  • 2 a few days
  • 3 about a week
  • 4 a few weeks
  • 5 Ugh, I need to break this down into smaller tasks

This gives me a rough idea of the amount of work remaining and shows me the types of assets I'm going to need (art, sound, etc.). At this stage, it's good to start looking at the tools you might need for yourself and content creators to make their lives easier (see my journal posts on Unity's Content Pipeline and Editor Extensions). Once it starts looking cool, it's also time to start marketing. Don't make the mistake that you can predict your release date at this point. As you continue working you'll say to yourself, "Oh wow. Wouldn't it be cool if it could do X" or "Holy cow, this feature isn't going to be fun at all, so I'll scrap X, Y, and Z".  In this stage the scope of my game will fluctuate (usually by growing). If the game isn't fun, time to go back to phase 1.
I chip away at this growing list until I finally start knocking out more features than I'm adding. In the later stages any kind of awesome new ideas get recorded for version 2 or another game. The release date stops wiggling around so much and you can start to really polish your game. In an ideal world, everything gets documented and you have a nice little audience of people waiting to buy your game ready to pay for it when you finally do release it.
Then I sell it and continue living the rock-star lifestyle of the indie-game developer with all the fast cars, loud music, and screaming fangirls. This is my current plan at least. smile.png
- Eck

In Topic: Making bots with python

07 January 2016 - 08:46 AM

Alright. Can you automate stuff with a script?