DekuTree64

Gameboy Advance is what really got me into embedded stuff. Might be a good "stepping stone" between regular PC game development, and direct fiddling with microprocessors and sensors and such. After you get used to working with memory mapped hardware registers, managing RAM by hand, writing ARM assembly and putting it in RAM instead of ROM so it runs faster, etc. you'll know how it is for programs to interact with hardware directly.

 

And at least for me, starting to play with stuff like AVR microprocessors after that, it all makes perfect sense how you can connect things up to do whatever you want. Programs read/write to hardware registers, where each bit of the register corresponds to a pin on the physical chip to either read from some other component, or set the pin's value to control another component... value being either positive voltage or negative voltage, representing binary 1 or 0. Although some pins can read a variable voltage value as an 8 or 16 bit number using some special circuitry to convert it, and some have pulse-width-modulator circuitry to toggle on and off at high speed according to a register value, effectively creating variable output voltage. And then you have the fun interaction between programming and physical routing of processor pins to other hardware

 

ARM assembly would definitely be good to learn. It's pretty straightforward. Practically like writing in a high level language compared to 6502 AVR assembly would be good too, and is sort of half way between ARM and 6502 (lots of general purpose CPU registers, but few opcodes)

Here's some recent Monday-morning like code

 

 

if (ddl.SelectedValue == "Ticket")
   LoadPassengerList(currentTrainNumber.Text);
   PassengerPanel.Visible = false;
 

 

 

 

See what I did there......?

Classic. "Hey, I just need to add one more thing in this if case... *copy, paste, compile*, no error, I'm such a good programmer! *moves on*"

 

2 weeks later, someone else: "Why is this stupid thing vanishing all the time? "

There's tons of info and tools available for GBA and DS homebrew, which is a lot of fun and very educational, although the community seems to have fizzled out for the most part so it's not quite as much fun as it once was. But as far as I've seen, no one has cracked the 3DS yet. I'm not sure if it's just a lack of effort, or if Nintendo has finally perfected their anti-piracy techniques, but by now it's looking pretty hopeless. Shame, because I'd love to do some stereoscopic 3D stuff.

I've never actually implemented a quadtree, but as I understand it, the trick is that it's recursive... most objects will be several levels down, but objects that are sitting on boundaries have to be higher up. So yeah, in your picture, those objects would indeed go in the root node because the very first division has boundary lines there. But keep in mind that those objects are very large relative to the world size. Most could only fit in a first or second division cell at most anyway.

For collision detection, I usually use a fixed-size grid, where objects can belong to multiple cells, and use timestamps to avoid testing pairs twice. Could use that in quadtrees as well, I think. Subdivide until you're a minimum of maybe 3 levels deep, and if you're sitting on any boundaries, just link into to all the cells. Then at the start of the frame, increment a global timestamp value (just an int), and when you render each object, set its timestamp equal to the global, or reject it if it was already equal (i.e. had been drawn this frame from a different cell).

Of course, it's questionable which is better performance-wise... depends on the world size and number of objects, I guess. In most cases, it would probably be better to just let a few things go in the root and first division nodes, to reduce the amount of list management. You can still reject them early by testing their bounding sphere/box against the frustum.

Heck yeah I know how you feel
Best advice I can give is to start a new project, and make it small. Not Hello World small, but like, Tetris small. But probably not Tetris, because that's just so overdone as a beginner project that it would feel like a chore to make.

Would working on multiple projects at the same time be a good idea?
 

Yes, definitely. That's how I did my demo... didn't quit my RPG because that would be too depressing. Just add the demo as a quick side project that I can get done in a couple months for a morale boost (and hopefully some prize money in a compo on gbadev.org... which I did, but mainly due to a poor turnout in the demo division).

Also, Nypyren is right. Even if you don't actually finish your big project, and do rewrite the base of it multiple times, it's not wasted work because you're applying your improved skills every time (which means they have improved... and that's the goal, right?). Eventually you'll have that stuff so internalized that you'll be able to whip out the base of a game so fast, you won't have to worry about using libraries
 

The main problem I have is just getting all the niffy details in my code to be completed. e.g. font rendering, which is a pain in the ass to do (still haven't actually implemented it).

Are you using bitmap fonts, or trying to do scaleable truetype with outlines and anti-aliasing and the whole deal? Getting bitmap fonts rendering is really easy, at least if you can just blit a rectangle from the font image onto the screen anywhere you want. On a system like GBA, it's either really easy if you use the native 8x8 tile size as your character size, or really hard if you want variable width characters and/or height not equal to 8. But that actually makes it a lot of fun for me, devising techniques to use the hardware to its maximum potential. But bottom line... anything you dread doing, just get it working in the most basic usable form possible, and go back to it after the actual gameplay is done.

Another thing I should mention... I always have been and am to this day, highly resistant to using other peoples' code in my projects. IMO, libraries should be nothing more than a hardware interface. SDL is excellent for that. I don't even use its blitting functions for 2D stuff... just shove my own software rendered backbuffer to the screen at the end of the frame. But it also provides openGL functions, so it's great for 3D too. GBA and DS are even more fun, because the hardware is fixed so you can interact with it directly, no libraries at all.

I'm also big on game longevity. I want it to be as immortal as possible. Thus, cross-platform support is a big thing (again, SDL is great because it's so minimal), as well as open source. Consoles like GBA are even better, because you can write an emulator for it on any kind of computer you want.

Heck yeah I know how you feel

Best advice I can give is to start a new project, and make it small. Not Hello World small, but like, Tetris small. But probably not Tetris, because that's just so overdone as a beginner project that it would feel like a chore to make.

 

My first real completed project was a demo on GBA, in the old 80's demoscene style. Tons of fun, and great because it's more of a collection of micro-projects (each individual effect) strung together, so it's easier than a game, where all the code has to work together at the same time. I was 19 at the time, and I took my first programming class at a local community college when I was 16, I think, so that might tell you something about my own ability to choose appropriate sized projects before then

 

Due to a lucky confluence of events, I landed a job at a GBA/DS development studio a few months after that. Wonderful experience. Great people, and fast timelines. Pretty much a game a year, so I quickly learned how large projects get done... which is mostly a matter of not fizzling out in the mid-game. Just keep working 8 hours every weekday, week after week, and eventually it starts to look like something. Then for the final stage, spend every waking hour tracking bugs and devising brilliant solutions, stopping only to eat and sleep so you can get your mental strength back

 

But eventually I got tired of making other peoples' games, quit, and moved back home where simple survival is cheap, so I can focus on the artwork and not the money. Unfortunately, it turned out that despite my awesome code (and art) skills, I'm still not very good at game design, and my own project didn't get all that far. Plus I was still kind of frazzled from the physical strain of sitting in an office chair for 8 hours a day for 5 years, so I took up acoustic guitar building as something more physical to do, and have been enjoying that for the past few years.

 

But now my body and programming brain are fully recovered and hungry for action, so I've been writing up a story for a quick and dirty FF1-style RPG, which I'll be making this summer when guitar building season is over (that is, winter, when the humidity is low). Making an RPG has always been my dream, and even though this won't be the epic story I've been plotting on since the beginning, it should be a lot of fun as a learning project. And making simple maze-like RPG maps is something I have done before, so there shouldn't be too much risk of design fizzlage. With luck, I'll be able to make the necessary modifications to my map editor and whip up most of the game code in a couple months, and then spend the next year making all the art, maps, and music

 

So... that's my story so far. 13 years in, and I still haven't finished a large scale game project of my own design. But I'm very happy with my life, have no regrets, and the future remains bright.

 

But there are lots of things to do in life other than video games, if you're honestly bored of it. And if you want to have a wife and kids, you'll pretty much have to work at a medium/large studio on other peoples' games to make enough money, especially if you have a college loan to pay off. So it really depends on what your core personality desires out of life.

Lots of good points in the previous posts. I'll second the point of designing ahead of the code. Don't implement any features you don't really need, and know what you do need before you start implementing stuff A 100% detailed design upfront would be nice, but not usually possible. But you at least need an overall game design, and a decent amount of full detailed stuff plotted out before you get coding.

 

For example, you might have a few levels planned out for a side scroller, with various platform and enemy types in them. Once you code all that up, you have all those components to mix and match in new, not-pre-planned levels, and maybe think of ideas for some more things to add. But you need those first levels designed before you start coding, or you risk falling into the trap of "engine" coding, which often results in lots of those unnecessary features

 

Also, use a coding style appropriate to the complexity of the game. Full C++/OO/RAII/smart pointer style is great for most things, but maybe a little overboard for Pac Man. If your game is similar to something done on SNES or earlier, chances are it was written in assembly with little if any heap allocation (usually using statically allocated pools for things that are dynamic in nature, but have a maximum number that can be on screen at a given time), and probably wouldn't run into many difficulties coding it in C.

 

And when commenting code, don't go overboard. Usually it will do to give a quick plain-English overview of what a function is trying to accomplish, or a block of code in longer functions. Only comment line by line if you're doing something particularly confusing, such as highly optimized code.

 

Quality content creation is time consuming. Background graphics, animations, sound effects, music, level design. But don't involve other people in your project until you have the design worked out well enough that a) they'll have something moving around on screen soon, and b) you're relatively confident that the project is not going to fizzle out due to excessive complexity or simply not being as much fun to play as you thought it would.

 

Be aware that 50% of the production time is finishing the last 10% of the game. If it doesn't look "almost done", you've got a long way to go But sometimes the transition from looking like a bunch of separate components into being a cohesive whole game can happen pretty much overnight.

Hey, if it works, it works.

In my editor, I only have one type of brush, which is a rectangle, with separate functions for plotting to the map and flood filling to the map (which repeats the rectangular brush pattern throughout the filled area). You can right click on the map and drag to select a variable size rectangle of tiles, and then click around to plot copies of it on the map. You can also click and drag within the tileset window to select multi-tile objects right from the tileset. No need to have separate code for single-tile drawing, since the variable size rectangle can be 1x1 and work just the same

As for who implements the drawing... in my case, the brush class plotToMap and floodFillToMap functions take a MapLayer pointer as an argument, and call layer->setTile which finally does the actual editing of map data.

By comparison, I see people on these forums throwing together prototypes on a matter of days (I don't even understand how you can prototype a game, with all of the underlying framework that is required). People participate in the Ludum Dare competition, creating full games in under 48 hours. And full released games on Steam, like Terraria, which were developed in only 6 months.

I have a feeling that those people have a very, very long history as programmers and/or hobby game developers.

Probably a decade or so, before they had the necessary skills to produce decent games quickly.

I would fall into that group. It took me 5 years to develop a decent amount of skill, at which time I got snapped up by a mid size game studio. It wasn't until after completing a couple of games there that I was capable of competing in 48 hour competition type stuff. As Promit says, a lot of the work setting up a flexible architecture is bypassed, and only the exact parts necessary are written. The trick is, you have to have a pretty clear idea what the full version would look like in order to do that. Also, even when starting from scratch, I've witten and worked in the basic parts of a game enough that I know it by heart, so I'm limited more by my typing speed (which is fast) than my thinking speed for a lot of those 48 hours.

But even when writing at full quality and not on a time limit, it gets faster the more games you make. You'll develop instincts for how to approach new roblems, and a library of knowledge about what worked well and what turned into a mess... and a lot of the time, there is no way to get the game to behave the way you want it to without parts of the code turning into a mess. But you can at least try to minimize it.

In other words, experience is the best, and you're gaining experience right now, so just keep at it But doing a short game or two may be a good idea as well... even if you don't need a lot of the architecture of large projects, you'll still get to experience the end stage of tying it all together and fixing bugs. Starting a new project and whipping up the basics goes fast, the mid stage just drags on and on building and building every day, and the end stage is panic and chaos and fixing and finishing everything that was mostly-done and the light at the end of the tunnel just doesn't seem to be getting any closer. But eventually, the bugs run out, and you're just polishing up little things to make the game extra special, and you ship it whenever you decide it's good enough... because it will never be as good as it could be.