Test coverage, 4:30AM and Spaghetti Breakfast

I woke up today at 4:30 AM and started to write code. I think I fixed the issues I mentioned in my last post regarding excessive abstraction. I also installed EclEmma and got that working. I already feel a little bit better, knowing that I don't have to waste time making sure I'm testing all my public methods. I just run EclEmma and it highlights tested code green, and untested code ends up being red. I can tell already that I'm going to like it. I think it will take me a few more days before I have a working color display using all the tested code that I've been writing, as long as using interfaces and such with easily-interchangeable renderers and such. (one renderer will handle the standard color-char displays, while another will deal with formatted text)

Question: On rec.roguelike.dev, I've seen some talk about using Dictionaries and the keyword/value pairs as a container for display or whatever. This intrigues me because I've been using this object quite a bit at work, and I'd like for the size of my display object to be able to dynamically size. (I wouldn't necessarily need to clear out unused key-value pairs, unless it was a memory issue). Basically, the display would have key value pairs for each character that had been added to the display, and it would also have a range of what to display, if a user were to zoom in, the range would shrink, the individual cells would enlarge, and fewer of the key-value pairs would need to be updated each refresh. If a user zoomed out, the cells would shrink and the range would expand, and more key-value pairs would need to be added/refreshed.

I suppose the same thing could be accomplished by just creating a 2d array with the maximum size that would be used if the level were zoomed all the way out, and still use the min/max range values to control what is getting updated and displayed; mostly I was just intrigued by key-value pairs.

Also, I ate spaghetti for breakfast.

The rabbit hole of abstraction

So, I've really been digging abstraction and interfaces lately. I'm like, "Hmm, I'll probably want more than one way to do this in the future, so I'll abstract that bit out so I can inject the dependency or whatever." Because I've been so focused on writing tests lately, I wasted a few hours today. I got to this point where I was confused as to which Interface/class I was injecting into another class, and I realized I'd abstracted the same thing about three levels deep. I kept being like, "I'll handle it with this next abstraction," but I never actually was like, "The buck stops here."

Anyway, just a bit of frustration, mostly because I felt so productive yesterday and most of my coding today seemed for naught. Though, I think I learned a valuable lesson about making sure I don't lose sight of the bigger picture.

I think I'll start using EclEmma pretty soon to help keep track of what I'm doing with my tests.

More TDD

I'm curious if anyone reading this has any experience with writing tests in Eclipse. I've been using Junit, and like it mostly. I find it helpful that I can create a new testing class and specify which already-existing class is to be tested; (and that it automatically populates the test class with all the public methods.) I try to make sure I have all my public methods under test, but I know that sometimes I create a public method and then forget to add it to the testing class. Is there a way to, say, update a testing class so that it will re-populate, adding any uncovered public methods? I suppose I could look into some sort of test coverage plugin.

My current focus is re-getting the display portion of my game up and running. I think I'm pretty close, though when it's there, I won't really have anything to show for it, other than a testing suite with all green checks. (Though, I should be able to create a window and display some dummy information)

Some things that are on my short list to implement: dynamic resizing of the window, zooming in and out using the scroll wheel, etc.

Gainful employment, graduation, and TDD

A lot has happened since the last time I posted:

1) I graduated from Eastern Michigan University cum laude

2) My grandpa died during exam week, and I was able to thank him for his generous contributions towards my college expenses, assure him I'd graduate, and that I had some job interviews lined up.

3) I amazingly got a job after only a few phone interviews and 2 in-person interviews. The people I work with are pretty amazing and I've been employed since January 11th. I'm only just now starting to feel like I'm getting the hang of it; though I'm still learning so much every day.

4) I grew frustrated with being so exhausted in the evenings. I stopped working out, I subscribed to too many shows on Hulu. I brewed a few batches of beer

5) I became interested in test-driven development, while at the same time realizing that my x-com codebase had again grown very unmanageable.

6) I created an account at git-hub and set up gitgui with my eclipse install

7) I started rehashing my game using TDD. The going is slow, but I think it's very worthwhile.

8) I somehow borked my git-hub security hash. (I still need to fix this)

9) I started working and running again.

This is it for now. I'm still around, I still read rec.roguelike.dev, I'm still working on my game. It's just taking me a while to adjust to having a career job.

2*2 sized units

So, I've spent some time working through my code and making it a bit more robust and less obfuscated. I have a long way to go, but out of this process emerged the possibility for larger-than-1 tile-sized units. (IE, tanks or whatever) As of right now, they are limited to a rectangular shape; there's no requirement for the dimensions to be square.

larger units are properly displayed, properly block light, properly move, and properly check for obstructions. (a 2by2 sized object won't fit through a 1by1 hole)

What you're seeing above is a 2by2 unit. it isn't necessary for a larger unit to be all the same character or color, but this one is like that for simplicity.

The only remaining issue related to this is that I need to figure out what algorithm to use in regards to placing units inside of a ship, or their initial starting positions.

Graduation

So much to do.

Theoretically, I just graduated from EMU. I say theoretically, because i only have 3/6ths of my grades. I'm not worried about two of the remaining grades, but my senior project class is scaring me a bit. Though our professor was a nice guy, he never handed any of our work back the entire semester, not even our midterm exams. My group project for that class didn't end as strongly as I would have liked, as I learned too late that both of my partners were content with mediocrity.

Anyway, that stuff aside, I've suddenly got some more free time and a LOT less stress. I plan to do some coding today, mostly related to 2*2 sized units (instead of the current 1*1 size), though eventually I'd like to support arbitrary size/shaped units, like say 2*3 or whatever. (this other shapes will make things more complicated, especially rotating, etc)

I also need to work with my equipment routine.

I also feel that soon I need to start designing my (G)UI

In general news, I've been reading and listening to some various programming books/podcasts and have some new and better ways to deal with problems that I've created for myself primarily because of my general ignorance of proper large-scale software design.

shadows

So, I've fiddled around with a few of my algorithms, and I've now got properly functioning light sources that cast shadows and are dynamically updated when things move through them. Here is an image of two agents on opposite sides of a bright light. You can see the shadows that they each cast.