Been struggling with my text based adventure game engine of the last month. I have re-written the code base like 4 times now and it’s like ARGH! I’m not doing this so much to make a game, but to try put good design practices in place. So that I end up with reusable, open close etc code, but I always seem to struggle with the design phase.
Constantly I am going back and forth to paper and writing my ideas, planning, etc down and then coding up something and hit a wall.
A lot of what I am trying can get a bit overwhelming for a novice and I am trying to make it all interfaces instead of implemented, but god damn can it get confusing thinking about all of it at such an abstract level.
My old way was to start throwing code down 'till I hit a problem and then stop and think, but for this I want to do it differently (tried that approach and I quickly hit a dead end) I am also reading some stuff on OOAD, but it’s a bit boring. I will keep at it though,
My question is, what is some of your design philosophies if you have any?
Apart from stating the obvious loosely coupled and highly cohesive I have always struggled with the same thing as you’ve stated about writing something and then realising that you can do it all so much better.
The mentality I have applied to my AttemptX project(that I’m still working on btw) is that it’s not about initially creating an elaborate impressive engine, but instead, just getting the damn thing working.
This means just implementing the bare bones. Yes it’s tempting to go back and create high end tools or bells and whistles of all sorts, but no… that’s not your goal here, instead your focus should be on getting all the modules talking and completing the pipe line.
Also about trying to create abstract frameworks. I often find it’s A LOT easier to start specific(i.e. no interfaces) and then as the design progresses, you can start to abstract various modules as you realise the benefit of having certain modules being able to be swapped out noting that some times it might not always be the best move to implement the overhead to create an abstract framework if you’re only ever going to use the one implementation. Note that this same approach applies for trying to make your code reusable. For example it’s a lot easier to wait until you realise the same bit of functionality is required somewhere else then refactor the appropriate code into a utility class than it is to try and predict the future then run into the problem of your code driving the design instead of your design driving the code.
I do the fail faster method. I will do all the wrong things as fast as i can as hard as i can. Then i am eventually left with one glorious semi decent thing.
On Oil Factory, and even more when I’ve worked on my editor, I tried to dissect every component my game needed and building them progressively. Starting by what I will notice when testing. (display and image first, then movements etc… I would not develop movements before displaying an image because that’s code I couldn’t test for the moment).
On older projects, I wasn’t as good at dissecting but the philosophy of starting with what I can test when running the code was already there.
Here’s a text based adventure I’ve programmed using python and pygame. The first complete thing I’ve ever made. https://pastebin.com/2XMe0D0w
I like this image:
[ATTACH=JSON]{“data-align”:“none”,“data-attachmentid”:“187139”,“data-size”:“medium”}[/ATTACH]
I personally wonder how you could have gone so often rewriting the whole thing so I do not have a philosophy or experience that could help.
Maybe if I kept programming my editor I would also have hit a wall like you did.
I wouldn’t really call it a wall. As I could easily have continued with all the ones I wrote, but it wouldn’t be good code. And the reason I was doing it was to produce good code similar to how tricxta put it loosely coupled and such. With each iteration I have been learning new things and have been able to reuse certain things (or can reuse them)
I mainly hit a point where in the design I see flaws when moving a head with it and think to myself I can continue or just re-write it and I don’t actually mind rewriting the code over and over lol.
Thanks for all the input, ideas etc. I think I will try things a bit less abstract and simpler as suggested by tricxta and 2ndwolf. Technically I already have done it, but as I was refactoring my classes I decided to update and my eclipse shat itself as it couldn’t find the JRE easy fix, but had to go work out before I could test the damn thing.
Another stupid thing I did was when I was editing the entity class I was actually editing the wrong one (had one open from when I was messing with the decorator pattern for practice. Decided I would use it to extend a basic text based entities description, for the test) I was wondering why the imports were messing up and nothing was working correctly XD looked to the left “Oh, wrong project folder…”
I think it’s simply boils down to a matter of self discipline i.e. keeping the reigns on yourself and making sure you don’t go overboard. For some people this might prove difficult but maybe that’s a sign of immaturity?
Not a sign of immaturity. Codr is certainly more mature than I am at programming and I have no difficulty leaving suboptimal code that works as is.
As I said, I make things work and build upon it, no biggie.
I will provide some screenshots, animated gifs when there’s actually something to show XD I do have the old code, but it’s all test. And that’s just me taking hardcoded commands and outputting through console, rather then an interface. Those are the easy parts to do, the hard part is the middle and how all the objects, rooms, etc work together that I am struggling with.
As I said this is more of a exercise rather than making a game. As I want to keep building on my core fundamentals. So, it could be some time before there is anything worthwhile to show.
I cannot say I strive for perfection but am very demanding towards myself in everyday life.
An immature programmer can certainly push himself to rewrite code a lot but I do not believe it’s linked.
I’m just answering the question.
I see no link.
Cannot come up with a good example, sorry about that.
Still working on this thing. Working out a lot of kinks and going over old code and such, but it’s coming along. A lot of figuring things out and such still going on with it, but I am getting some fairly decent results. Right now the commands are just being hardcoded e.g level.inspect rather then using the player and console input as a controller. Easy enough to do, actually already done in my other version, but not imporant atm.
Progress none the less. Slow going, but that’s because I have been busy and such.
Updated it a fair amount today. Nothing super noticeable really, but I setup look inside actions etc. Still working on it so you can look at hte contents of the object you are looking at. Thinking about storing a parent object when the player looks at an object and when you see the contents e.g Liquor you can now use look at liquor because it’s in focus. The parent will be cleared when you inspect any other objects.
Also still deciding if I will keep exits inside of the main Entity list, with the other objects in the rooms.
Made a bit of progress on this. Added in Entity Containers that are not the current level (e.g boxes, player) however as it stands right now it’s a bit clunky because of the way I have done it - I can’t have containers that hold containers, well functional containers. I’ll go back at some point and fix this, but for now, I’m moving on.
I also quickly implemented pickup/take. Not quite finished, but a decent start.
I plan to work on adding in functionality for using objects within the rooms, that can interact in some form or another. Similar to how I’ve done exits, you use an exit and it calls the Receiver/players change level method.
All commands are still hard coded at the moment. No sense me moving on to input yet, especially when I am changing a lot of things.
Side note: I have no idea why I put a pantry in the Dining area, but whatever XD It’s efficient, at the 'least, I suppose.
easy fix, but had to go work out before I could test the damn thing.
