Jump to content
  • Advertisement

DavinCreed

GDNet+
  • Content Count

    12
  • Joined

  • Last visited

Community Reputation

15 Neutral

About DavinCreed

  • Rank
    Member

Personal Information

  • Website
  • Role
    Game Designer
    Pixel Artist
    Programmer
  • Interests
    Art
    Audio
    Business
    Design
    DevOps
    Education
    Production
    Programming

Social

  • Twitter
    @davincreed
  • Github
    DavinCreed
  • Twitch
    davincreed
  • Steam
    davincreed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. DavinCreed

    SlingBot Boarding first public playable WebGL build.

    I noticed it, but it didn't bother me because it was very far away.
  2. DavinCreed

    SlingBot Boarding first public playable WebGL build.

    I did try the courses. I completed one and then tried to load another and it looks like that broke it until I restarted the game. I did not unload the course when I did that. The first time everything worked well. When I loaded the second one, I got the 10 second countdown immediately after loading, before passing the start. Once it reached zero it would start over again. Unloading the course stopped the countdown, but left the number up on the screen. Loading a course started a new countdown immediately. Tried unloading and loading the courses a few times.
  3. DavinCreed

    SlingBot Boarding first public playable WebGL build.

    Odd, I just tried it out on Chrome: Pretty consistent around 60fps. Win 10 64 bit i7 4 core 1.9 Ghz processor 16GB RAM. Some Intel video card, not meant for gaming.
  4. DavinCreed

    SlingBot Boarding first public playable WebGL build.

    It's easy to get the hang of the controls. The terrain shapes was pretty cool to play around in. For a rocket powered snowboard, there seemed to be no handling while in the air, and maybe about half of the time playing it the character was in the air for me. The frame rate was about 60 fps on my non-gaming laptop.
  5. DavinCreed

    Totally new to this and having a hard time

    One thing that's always been true for me, no matter complexity of the project or my current mood, is that if a thing seems to big for me to point I don't even know where to start, that means I have to break it into smaller pieces. Design documents help with this, which is why it's commonly suggested. For more specific advice, I'd need more specific information. It sounds like you're going to be making a pretty big leap in complexity from interactive fiction to simulating a magic system while taking into account stats and personality traits. For something like this, a good way to keep motivation and to find better starting places, is to break the whole game up into a little portions like: a spell casting game, then add in a character with stats, then add in going to classes... etc. Taking on something like that as a whole is like staring up at a 2000' cliff and it's extremely daunting. But finding a way up by using 20' cliffs is manageable. Are you going to be using a third party engine or starting completely from scratch? I recommend third party engines, and the best suited one will depend on the project. I prefer UE4, but Unity3D is awesome as well. There are other good ones if you're doing a 2D game.
  6. It's all relevant if you're programming. These principles aren't some way to brow beat people into line or for gate keeping (though there are people that do do things like that with them), the OOP principles really do help you to efficiently write code that is easier to maintain and plays well with others. No one starts off with this stuff already, it takes time and experience to get things going well. As a hobbyist, read up on it, take it in a little at a time. Every once in a while (like every year or two), review the principles again. Each time you do you will learn a little more because you'll be a little higher up the mountain.
  7. Damn, good luck trying to take down OOP. There are plenty of bad examples of everything, but the tough thing to do is to take the principles as they are meant to be followed and address those directly. In this way you're attacking not just the best examples, you are addressing the ideal. Addressing only the bad examples or if we're being generous, what you find to be the common examples, is like playing your ideal team against the bench warmers and injured players of the other. Which is what it looks like you're doing here. If you follow SOLID, GRASP and the very common KISS principle, then none of the problems you listed as inherent to OOP (I think you are incorrect in doing so), are problems for OOP. I recommend following principles to about 90-95% because that's about the peak balance between development time and the benefits of the principle.
  8. DavinCreed

    Starting Zone

    Yeah, I plan on releasing it once I get it worked out better. Takes me a lot of work to find the right balance between explaining way too much and the shorthand I use for myself. I have a document detailing the whole process, but it's half a mess right now.
  9. DavinCreed

    Starting Zone

    TL;DR: Object interactions, implementing game mechanics, and creating clear naming conventions and folder structures to make development more efficient. Abstractly, I'm working on my ability to create and implement gameplay mechanics, elements, and features. The goal of the first section is to focus on that and ignore everything else. I spent a lot of time planning this whole thing out. The first part of the first section, is to create the first level of a game ignoring everything other than gameplay. But like I said earlier, I work better when things have some graphics even if those graphics aren't that great. I'm supposed to make five games before moving on to the next part which is to take just one mechanic from one game and place it into another game... I planned out my whole path with this thing, it's subject to change but it is currently "fully" planned. All of my previous projects until five years ago, I was developing my own game engines. And while there are some advantages on performance, install footprints, and some other things when making my own engine, I decided to look into game engines to cut out a lot of development time. After trying out several great game engines (some not so great), I feel like UE4 suits me best. I know it's not that great for 2D, but there is still a lot to learn about the engine when working in 2D that will carry over to when I'm doing 3D games. For the first one, Ninja Gaiden, it was mostly just a get it complete kind of thing. I had an idea about things like folder and file organization and naming conventions, I like to keep things organized and clean, but I learned that I needed something better if I were to tackle a larger game. There were a lot of things I did in a way that's not that great, that ended up being more work instead of being efficient. For instance, when I was making the special weapons, it was a mess of logic that had a bunch of unnecessary extra checks that wouldn't have been required if I did it a way I thought up after I was done. And that's kind of the point, to get me thinking about better and more efficient ways of developing, and while thinking and discussing things is great, for me, the learning doesn't really kick in until I'm making mistakes. For the second game, I was able to complete it in half the time, even though there was about the same amount of things to complete because I learned a more efficient way to create the objects and their interactions. I made a better warp that was easier to set up in a level than the one I made in the first one. Mostly though, I was able to do things faster and more efficiently than before. I still feel like there is a long way to go for me to make write up some design patterns that will be good, I also feel like I've been getting better at thinking through and implementing game mechanics. The logic is cleaner and more efficient, and the file naming convention and folder structures are better suited for efficient development. Still feel like there is a lot of room for improvement, but I'm also getting better. For all my old projects, I would occasionally have to go in and move some things around and rename things which took a lot of time from time to time but saved time overall. With these smaller projects, I feel like I am learning how to do that much faster, because the projects are smaller I can learn from my mistakes and carry that over to a completely new project instead of cleaning up the current one. It also gives me good opportunities to try out new things without worrying or caring about if it doesn't workout that great. And overall, there are a number of things I learned that are very difficult to quantify that help with my experience and makes thinking about how to implement game mechanics easier for me. For the first game, I would try a few different things for the more complicated mechanics, and the amount of different things to try out is getting less and less. Now I'm doing most things great on the first try in ways that play well with others.
  10. DavinCreed

    Starting Zone

    I've been making games since I was a kid, but I've only finished one game in the last twenty years. When I was young I kept it simple and was able to make a few MS-DOS games. Then I wanted to keep making it better. I've tried so many different strategies to get better at game development. I've tried working with people and getting ghosted by team members one after the other in many different projects. I don't blame them much, it's a big ask for most of their free time for a hobby they find out isn't what they want to do. I also don't want to hold anyone back if they want to move onto a better managed project where they can flourish. And that lead me to my last strategy, to start out simple again and do everything alone, but if people wanted to help I would be happy. And I was doing pretty well, I learned a lot in the project, making a game from start to finish as we know is a lot of work that requires a lot of different skills. I looked back at the five years I took to make my last game (well, there was a lot of procrastination), where my skills are as a game developer, and where I wanted to be and I was disappointed by what I saw my path was. If I made my next game, a little more complicated and developed a little faster, I was still looking at a project that would take a year or two and I'd learn a little more. I have a few games, like I'm sure we all do, that I really want to make but don't yet have the skills to do them well. So an idea about training myself up without going through the whole process slowly developed. Focus on one skill at a time, then add in one more once I've gotten good at it, and one more, until I'm pretty good at most things. So I over engineered what I call RIP (repetitive iterations for proficiency). I think the idea is good, I think it will help me get better much faster, and I'm going to try it out to see if it works. I'll blog my progress as I go, maybe other people will find something useful in it. I've already made the first two one level games, a Ninja Gaiden (NES) clone and a Super Mario Bros. (NES) clone, and am currently working on a Bionic Commando (NES) clone. The first several projects in the plan are to take a game I like to play that falls into the more simple game genres (platformer, action... etc.), and reproduce all the gameplay for the first level.
  11. DavinCreed

    Game Dev Skill Development Project

    Thanks, I'll give the blog a look. I saw that I just missed Frogger but I'll check out the next one. The half res came about because I figured it would save some time, I'm supposed to be focusing on only reproducing the gameplay but I find it harder to work on a game without at least some graphics.
  12. As I like to say with a deep sadness in my soul, I've been failing at game dev for about three decades. I've been having fun, but I'm ultimately disappointed with my progress. So I've once again changed my goals and strategy and over engineered it. Which brings me to my current project. My new goal is to get better through repetition, but using a strategy for that repetition to make my skill development more efficient. So far, I've completed some clones of the first levels of two games (Ninja Gaiden and Super Mario Bros. for the NES), and am starting out on making the first level of Bionic Commando (also for the NES). I'm redoing the graphics in half the res of the originals for now. So far, this strategy seems to have taught me more in the few months I've been doing it, than the five years it took me to complete my last game. The difference I suppose is that I'm not going to attempt to release most of these games. I might consider polishing and releasing the ones that aren't clones. This big learning project looks like it will take me a few years, in the meantime I'll probably start other projects while still working through it but this is going to be my primary project for a long while. And something that I think I should have done in the first place so many years ago. I'd like to share my progress from time to time and hopefully have some discussions.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!