What are your worst habits when programming? Using 20/20 hindsight, what shouldn't you have done with your code?

I have a dumb tendency to rely on trial end error when I'm the least bit tired. So if I drink two glasses of sleepy juice (red wine) at dinner and then start coding, I tend to keep trying variations until something just works. So just the other day I worked on an incredibly simple geometry problem for about 40 minutes, until finally I took out a piece of paper and pencil, wrote out the (elementary) math and in less than 5 minutes the code worked perfectly. 

Don't do it!

[democratic]

It was the north vietnamese government who was the offender

Serious? For reals? Man, you gotta read some history. The Vietnamese people were being reamed by the French, Japanese, Soviets and even the Chinese. The Viet Minh were were offering a hope of independence from colonial rule, but because they were caught between powerful empires trying to play them as a pawn they inevitably became radicalized, and populated with foreign agents. The 'offenders' were the colonial superpowers who royally f*cked over generations of Vietnamese people for profit. The Viet Minh started out as a democratic grassroots movement for independence, but all the big ass powers in the world weren't going to let that happen.

The Americans weren't the 'aggressors' in that they didn't start the conflict, but they damn well sure were the 'escalators' that brought it to terrible heights of violence using powerful modern weapons against a peasant army, and refusing peace deals again and again while illegally bombing and even invading adjacent countries, and propping up an insanely corrupt south vietnamese government engaging in massive drug trafficking...

If I wasn't busy with my own project I'd be all over this. Keep the sprites around Theon, you're totally right about the one sided nature of war games, and I too think that it's wrong. In fact make some burning children, raped girls and impaled baby sprites so we can begin to portray the horror of war. I recall a movie that Gary Busy did in Turkey where he portrayed the typical evil american war monger killing Turks/Arabs/Persians. He got crazy flak for his almost cartoonish portrayal of an evil american and was practically black listen in Hollywood. Jon Steward picked this up and right after saying how terrible it was he showed a montage of hollywood action movies from the last 30 years which demonized arabs as mindlessly evil killers in the most absurdly dehumanizing way. The propaganda machine rolls on...

Show of hands, how many people don't make a 'choice' but rather have one particular vision in mind?

*raises hand* 

You forgot one. Pay to continue playing.

Spiderweb software lets you play the first quarter of the game free. If you've played that far then you probably want to continue playing. This works best in games where it's easy to define the size by playtime/play area/etc. I don't really know how you'd apply it to PGC.

Some of these are related to IDE's editors, programming as an activity.



- Compiler errors
- Linking
- Not enough type safety
- Too much type safety
- No autocomplete
- Broken autocomplete
- Autocomplete that cannot read my mind
- Undefined performance characteristics
- Binding 2 or more languages together
- Porting
- Libraries too limited
- Libraries too bloated
- Fanatical pinko commie catholic nazis portraying a language/library as the one true way(TM).
- Lack of abstraction
- Too much abstraction
- Undocumented features/bugs


- Meh... some stuff... I guess. It's all relative. I like one language feature because another one I'm used to doesn't have it. I'm a perfectionist and everything is kind of lacking in one way or another (most of all my efforts).
- I guess clean, minimal, complete toolsets that allow you to work in a way that doesn't require assumptions. So I prefer tested and honed things like C++, Lua, Perl over monolithic beasts with tons of hidden corners like C#, Cocoa, Java. Thats just me.

Works on iPhone. It would surprise the ships out of me if it didn't work on Android. The graphics support is getting a lot of attention and it seems to be reliable, but the other pieces are not all there, AFAIK sound support is not complete, blah, blah, blah...

RTS + Cooking game,

organize your ingredients invading the stove, oven and steamers to make the perfect meal.

I am currently learning Objective-C to hopefully be able to get something on the App Store. I am relatively new to ObjC so if anybody has any tips that would be great! 

Tip: do things the Apple way. Look over the docs and example code and use that as a basis. Start with a working example project and tweak it till you understand how to use the classes.

Tip: don't wear striped with checkered clothing unless you are dressing up as a headache for halloween.

Currently cleaning/streamlining AI code. Skeletons are practically blind. You can walk by them and they don't notice you unless you shine a torch in their face... It started out as a bug, but now I kind of like it.

Hey Cellulose, really want to try IB, but I have a problem.

Short story: are there any download mirrors? I've been trying to download it for a couple days now, and it's just not working. The transfer speed starts at 10k and slowly winds down to around 0.1k/s, then just fails. It's probably because I'm in China and the net is crippled here, but I'd really like to try your work. Please mirror!

PS. I haven't forgotten about the Update Manager Project.

This is my kind of game. Just wondering how you're going to implement combat with no randomness. I'm trying to find a balance in my game now, I'm curious as to your technical/philosophical outlook on the issue.

Good luck! The world needs more turn based tactical games!

he alternative to a "cluttered" UI is a labyrinth of submenus and sub-menus? Some games just can't have a simple interface, period.

Your trapping yourself in the old paradigm. There is more than one alternative to a cluttered interface, and many of them don't involve menu's at all.

With thought and ingenuity, things can usually be made simper. Or at least compartmentalized. The problem I see is not that game play is too complex to make a good interface, it's that people make interface an afterthought or just shoot out an interface from their asshole in one diarrhoea blast. Yes, complex things are complex, but it's possible to present them in a way that facilitates learning and developing automatic reflexes easier. The human capacity for learning and action is incredible, the future of interface design will be based on good technical engineering, as well as physiological and psychological understandings. Games will get more complex and easier to play.

[Edit:]

Today i made this, with no prior knowledge of javascript. Pleased with myself! Haha.

It is a random game idea generator, however it needs more things to choose from, so i am open to suggestions!

Edit:(Temporary url, as i needed somewhere to upload it to.)

I want moar! Competish generator anyone?

[don't be a code snob]

Thanks a lot, the encouragement really helps a lot, especially when you're tired...  

Considering that this is the devlog forum, I suppose I should explain the development, instead of just spouting milestones. So here is the bitter tale of a bitch of a game engine...

I started the engine, like so many things before it, without understanding what I was getting into. I just like doing things that are kind of obscure. I like learning how to do something from scratch. There wasn't much in the way of online resources on isometric engines with a z-coord, so I just made a regular engine and then added the Z coordinate. It was messy and ridiculous, and incredibly inefficient. At that point the engine was a conglomerate of Python, C and C++, Java and Javascript. I don't exactly know why I made such a beast, but keeping everything cooperating proved to be too much of a pain and I extricated the core isometric engine and started again, this time with C++ and Lua. Along the way I tried many, many ways to improve the engine and reduce unnecessary drawing. Some of the code was truly comical. Trial and error, and error, and error, and finally success. I'm so glad I picked Lua, as integrating it with my engine was so easy I felt liberated. After fiddling with various wrapping systems that required either special tools, large external dependencies, or meta languages, I just went in and learned the Lua C API. At first it was bizzare, but I finally wrapped my head around it and (being a stubborn maniac who likes making things hard on himself) proceeded to make a mini language with the C preprocessor to make wrapping C++ functions and classes in Lua easier. This could have gone horribly wrong and set me back, but remarkably it turned out all right the first time, with little fuss.

After getting the core tactics style isometric engine working, I came across my first evil nemesis. One day I decided that phones are where it's at and I'm gonna put this thing on every phone system I could. So screw you SDL. I mean, SDL 1.3 is commercial, it's bloody commercial! What happened to freedom, maaaaan! I'm not working for the system! I support freeeedom maaaan! This was another moment of folly that I barely survived. Here's a tip. If you want to make a game, really make a complete game, don't spend your time on making tools that you can get for a reasonable price. Man, I wish I just paid the license fee right then and there. Instead I did something dumb to the N'th degree. I wrote a software blitter. Why, you may wonder, didn't I learn OpenGL? Or perhaps I could wrap up system API's in a nice little package? My only answer is that I'm incredibly foolish sometimes, and I should have. Despite the absurdity of my decision, I got it working pretty fast, and pretty fast. It was almost as fast as SDL 1.2 software rendering with RLE acceleration. Considering I had to look up the bitshift operators online and had never done any real graphics programming before, it all worked out OK. Except I wasted a lot of time developing a system that I eventually will throw out.

The next bugbear on my odyssey was the dreaded GUI. Can you guess what I ended up doing? Long story short. I wrote the stupid f*xing thing in C++ and then decided that I don't like all the glue code between the GUI and Lua, so I scrapped it, wrote a basic graphics compositor in C++, linked it to Lua, and rewrote the GUI in Lua. All things considered, it was the lesser of two boneheaded evils. Now here's the rub. I was feeling pretty torn about abandoning my C++ GUI code, because it constituted such an important part of my editor. So again, predictably, I rewrote the editor. Twice. I'm serious.

After all of this total nonsense here is what I ended up with:

C++
------------
Area - Holds layers of...
Entity - A game object that exists at a coordinate in an Area
Animator - Responsible for telling Entities to change frame or position
Compositor - Puts lines, rects, text, images into compositions that can be drawn quickly.
TONS of other little details like pathfinding, line of sight, etc...

Lua
------------
Entity - A Lua subclass of the C++ Entity class, this adds all game specific data and methods.
Window - A Lua base class for labels, buttons, menus, grids, panels, etc...
Everything else required for a game including main game loop, input parsing, AI, saving, loading, etc...

I'v probably repressed forgotten a lot of horrible memories, but that's the gist of it. If I've learned one thing it is this. Decide what you want to do. Do you want to make a bunch of software components? Fine, DO IT. Do you want to make a game? Then don't be a code snob. Just get things that work, use your skill and discernment along with ample research and choose the right tools for the job. If I had to go back again I'd use good libraries instead of coding from scratch, particularly for graphics and GUI. Oddly enough (or not), I used to make audio software and have experience with how difficult it can be, so it never even entered my mind to make a custom audio engine, I always planned on using something precanned. I guess that's how it works. An overambitious idealist goes in thinking that they can conquer anything and comes out a grizzled veteran. Well, I'm tired, I've made mistakes, and I have the battle scars to show for it. Next time I'll do my best to avoid a fight.

I'm doing the project solo, and I'm losing my mind ever so slightly. I wish I started something smaller, but now I'm in way too deep to go back. If anyone wants to get in on part 2, that'd be great, but now at the last mile of this punishing development marathon, I've got to man up and finish what I started. I still believe in this game strongly, but it feels really nice to hear that someone other than me is looking forward to it.  

By the way. This game is going to be amazing (I hope).

Man, I can't wait to have some money to hire an artist like you...

Setup a repository on github your favorite code site. Then we need to sticky this thread and have the community made aware of it.  You threw this out there like it's no big deal, but this could be potentially HUGE. I know that I and many others have been looking for something like this. I can't commit large swaths of time because of other obligations, but If there was a repository + TODO list + wiki, I would contribute regularly. Multiply that by X for however many indie devs would die for this and we can have a robust, seriously solid framework in a pretty short time.

Maybe move this to TIGProjects or the TIGWiki or something. Lets get this ball rolling people! ROOOOOLLLLEEEEENG!

A warning about the python+qt concept is it seems like it will tend to produce very big binaries just for the updater. However it still sounds really useful as a way of getting a rapid prototype together.

One thing I never quite got. Do you really need a gui as complicated as qt? If you need lots of stuff like displaying webpages and patch notes then sure, but if all you do is throw up an "UPDATING..." progress bar at startup sometime then integrating qt might be more work than just making simple OS-specific gui window things.

Agreed. That's why I'm using the standard Tkinter distro. It's totally suitable for basic dialog boxes and such. The GUI code so far is about 25 lines or so and will work on X/OSX/Windows and just about every OS written in the past 20 years. I'm going for compatibility.

For a project like this, limiting scope is pretty easy. The requirements are well defined, and QT's GUI is overkill X10. That being said, if it was a QT based project then it'd also access QT's libraries for HTTP, filesystem, md5 hash, etc. Doing each of those portably isn't exactly difficult, but it's tedious and unnecessary.

Work in progress. Parses text file, downloads latest version to temporary file, checks hash, shows progress indicator while downloading. I'm literally learning python 3 as I write this, so this is definitely not done in the one true way(TM), but it's really clear and concise code, very small easily understandable file.

https://github.com/eclectocrat/AutoUpdate

Anyways, I feel really guilty about spending the morning reading python docs instead of working on my game so, I'm gonna get back to work, and return to this when I need a holiday from my f*xing gorramn sh*t bastard filter persistence code.

Aaargh.

RPMs are the standard way of distributing applications on OS X, correct?  In any case, the downloading and running of the launcher should be as simple as possible.

You're thinking of DMG's, but whatever.

Looking at the requirements it seems to me that the only platform code is:
Networking/HTTP requests. < Lots of cross platform stuff available.
Filesystem management. < Easy as pie.
Splash screen/Progress indicator < Tiny bit of platform specific GUI mucking.

I still think that Python is a good way to go because it's batteries included, ie: the standard python distro has everything needed built in (you can say the same thing about QT, but I'm paranoid of Nokia's legal dept.). Also, one source trunk is easier to maintain than 3. Double plus I am a hundred and thirty percent sure that you can package a no external requirements executable.

So I'm still going ahead with my prototype, which I have written between bouts of frustration over mysterious castle, and consists of less than 20 lines of code that downloads a file over HTTP and saves it in a temp directory. Haven't used Python in over a year, and trying to update my skills to 3.x version, but it'll be a couple of days (depends on how pissed of I get with my game!) before I post it on GITHUB.

Either way, I can contribute the OSX native code version if that is the consensus. I've already looked into it and it's really simple.

This project screams python btw.

DUDE! Seconded. I'm just going to go ahead and get something working in python and I'll get back to y'all in a few days.

I'll do OS X.