Be the first to post for 'Rising Complexity, Refactoring'!

If you’re reading this, there probably aren’t very many posts yet. But don’t worry, you can be the first! Either create a new post or just reply to this one to say ‘hi’.

I’ll just leave this here:

(it seems the embedding code doesn’t work in these forums!)

Near term plan:

  1. Make arrows shot by archers more visible; already done orientation towards the target.
  2. Additional palm trees and other vegetation.
  3. Skulls near the beach to presage hostile territory.
  4. Ensure projectiles cleanly collide with target and are reaped regardless of whether they hit.
  5. Code the opening of the doors in the stone wall.


  1. Visual indication of active healing shrine (not in cool-off).
1 Like

Thanks for sharing your plans.

As a software developer I normally make a design model using UML diagrams. When designing you manage the things descussed in this video. You think about a design to implement features, but you also look at the features that will come later. You want a design that scales with that.

I’m actually wondering how people are modeling the software for unity projects. Are you guys also using UML for this? I can imagine you make object diagrams where you show how game objects are build of which components.

Here’s my plan for the next couple of weeks

  1. Actually sit down and design my level flow.
    I’ll be honest, as good as Rick’s videos are, level design / world building isn’t my strong suit and I’d rather be learning some new coding techniques. However, it’s now at the point where I really need to get out of my different sandboxes and start building a proper level. I have all the tools I need but I’m a bit like a painter staring at a blank canvas when it comes to level building.

  2. Level design done - now to actually tune my enemies for the scenario.
    I’m a big nerd for spreadsheets, so I’ve got a pretty hefty one going on will all my potential enemy stats. I just need to make sure they actually feel good within the context of the game.

  3. Fix projectiles
    So that they look half decent, don’t allow for friendly fire, and remove themselves from the scene when they hit the player or go off screen. They’re really making a mess of the hierarchy at runtime and, if left unchecked, will cause the game to lag.

  4. More level design…
    Did I mention how bad at I am at level design? This will be the part where I tweak what I have, based on how the stuff above pans out.

@Willem_den_Hollander, I learned UML when I studied software development and have pretty much never used it since. I think you’re one of the first people I’ve seen in the real world who actually uses it. Everywhere I’ve worked have always used Agile instead, so there is a lot less documentation and a lot more rapid prototyping. Personally I use rough diagrams to see who things fit together, but I don’t go to the extent of drawing up formal UML diagrams.
Due to the way the course is progressing I’m assuming Ben is probably following a more Agile approach as well, although I could be wrong.

I’m suprised that I’m the first person you have seen so far to use UML :stuck_out_tongue: Where I worked so far, I’ve seen everyone using UML. In the company that I work, quality is must, which also includes documenting and reviewing your design. In this company we work on software with 800 people on a single machine. So designing and documenting this is required to make sure that software stays robust, maintainable and to prevent a lot of refactoring when you want to keep adding features. Otherwise you will end up refactering way to much later, to implement 1 feature.

Of course there are situations where fast prototyping is a better choice :slight_smile: Documenting everything takes extra effort and should only be done if it saves you a lot of effort on refactoring later. Which is very common when working on big software with a lot of people. On smaller projects it can be that documenting/modeling your software will take more effort then the actual refactoring you might end up with later. In these cases it’s wiser to take the hit on refactoring rather then documenting everything.

The fact that you use agile doesn’t mean you can’t use UML to model/document your code. We use Agile as well. But one common problem with agile is that documentation is poor. But of course depending on your environment that can be okay :smiley:

@Willem_den_Hollander, it sounds like you’re building bigger software with a bigger single team, so decent documentation would definitely be required. The company I worked for previously had a lot of smaller teams working on different games (video slots and table games), so there was more rapid prototyping and less pre-planning documentation. What you started out building wouldn’t necessarily be exactly what you ended up with, since the games would change based on playtesting during development. Keeping meaningful documentation on everything was fairly pointless, although we did have a pretty good informal wiki.
It could just be a difference in mentality between industries / countries as well. I’m not saying that UML is good or bad, just that I’ve never really used it. :slight_smile:

The “Lost Son” Plan

Week 10/2 – 10/8
• Fix Companion Bugs
• Fix AI Controller
• Give enemies swords and attack animation
• Create an epic battle scene
• Develop a flow to the story and game

Week 10/9 – 10/15
• Tidy up my levels
• Create a “Demo Level”
• Ensure everything is running smooth and efficient
• Add details
• Release Demo

I am working on ensuring everything runs stable and smooth to showcase a fun prototype level. I’m messing around with my assets and level design. I’m really looking for grand battles with epic fights and reward for defeating a bunch of guys. Also I’m allowing lots of mini-bosses to add depth and engagement within the big battles. Nothing to complex just hack and slash. :smiley:

What are you guys experimenting with?

Rbots plan :

Adding functionalities :

  • dialogues
  • npcs
  • quests
  • world interactions

Improving design :

  • adding effects
  • improve lights

Improving code :

  • Find better ways to write/share pieces of code
  • improving ranges and detection

Lots of things left to do, at least for a demo :smiley:

edit : I forgot, finish the starting level design (requires adding functionalities)

FYI @ben : the linked book by Seth Godin is apparently “currently unavailable for purchase”. Anyone know where else this might be available off hand?

I’m doing at least two lectures a day. I’ve done as much as five in one day. I’m unemployed and have oodles of free time. All my models are built in MagicaVoxel. I’m not just a coder, but I’m an OK artist too. I even went to art school.

  1. Make arrow and have it line up with the direction of the shot. Have it ignore enemy that shoots it.
  2. Make sure projectiles are destroyed on a hit and if they miss.
  3. Create the broken house that the first quest giver will be at. Make the NPC model too.
  4. Nail down how I want to implement combat mechanics. I have an idea of something of a mix between Skyrim, Diablo (The first one) and D&D/Pathfinder. There is no magic in my game so I don’t need to worry about that.
  5. Work on character, armor and weapon stats including guns and crossbows.
  6. Create more models for the above and NPCs.
  7. Make a visual for when follower heals the player. Even though they are not using magic, but tech player should still see something. Follower needs to get close to the player to heal them, then they back away when healed.
  8. Add ability for the follower to join the fight using a bow if Player is unhurt.
  9. Add option to use Bow/Gun for the player.
  10. Implement Gamepad controls. Plan on something like Torchlight Frontiers. (Yes we got to play it at PAX.)

Privacy & Terms